Chainlink VRF: On-Chain Verifiable Randomness

We’re thrilled to announce Chainlink VRF, which utilizes verifiable random functions to generate randomness that is verifiable on-chain. We see many great smart contracts benefiting from Chainlink VRF, specifically those that would like to provide proof that they are indeed using a tamper-proof source of randomness beyond their control.

We’d like to thank our academic collaborators, the larger developer community that’s given us feedback on Chainlink VRF, and the many team members who have put their efforts into making this initial implementation a working reality, thank you.

Chainlink VRF helps enable and accelerate the development of smart contracts focused on blockchain gaming, security, layer-two protocols, and various other use cases. Developers can easily integrate Chainlink VRF to utilize verifiable randomness in their smart contracts through our recently released developer documentation.

The Need for Verifiable Randomness

A security-sensitive mindset is required to create and successfully defend a smart contract against adversaries seeking to steal the funds held by that contract. Smart contract developers using randomness as a key input should also see the manipulation of that randomness as a critical risk. Well-made systems relying on randomness would ideally want it to be both provably fair/equally uncertain to all contract participants, while also successfully reducing the risk that an adversary could exploit their contract by predicting its outcomes.

Chainlink VRF seeks to meet both of these requirements by delivering its randomness along with cryptographic proofs that can be verified on-chain, showing that the randomness is indeed unpredictable. Due to the on-chain verifiable nature of Chainlink VRF’s randomness, participating nodes can only withhold a request, for which they would be financially penalized using Chainlink’s upcoming staking capabilities, and possibly removed from future queries that would have paid fees for their randomness.

Using Chainlink VRF, you can build reliable smart contracts for any applications that require unpredictable outcomes to:

  • Make games more trustworthy by using a source of randomness that is verifiable on-chain, allowing developers to provide additional proof to security-sensitive users.
  • Make games more fun by generating challenging and unpredictable scenarios and environments, and assigning unpredictable player rewards like loot drops.
  • Generate provably random assignments of duties and resources, e.g. randomly assigning judges to cases or auditors to firms under scrutiny.
  • Choose a representative sample of observers eligible to vote on a proposal the contract needs to establish consensus for (surveys are an efficient way to provide extra sybil resistance).

Security Limitations of Existing Methods

Existing solutions for providing randomness to smart contracts have limitations that are overcome by Chainlink VRF’s verifiable randomness. Both the use of existing on-chain data like a block hash, and/or various off-chain randomness that then needs to be placed on-chain presents their own set of unique challenges.

One example of an exploit that smart contract developers looking to rely on a blockchain for randomness should seek to avoid is overreliance on block hash-based randomness guarantees. For example, suppose a contract makes decisions based on the parity of the last bit in the hash of the block at a certain height. This looks like a 50/50 outcome, but consider that a miner (or coalition of miners) who produces one third of the blocks on average may decide to throw out winning blocks for which the last bit of the block hash is one, forgoing the block reward of approximately 2-3 ETH. In this case, the miner could bias the zero outcome from a reliable 50% likelihood to a 2/3rds likelihood, leading to the loss of user funds from any smart contract relying on this method of randomness generation. If the contract’s zero-bit behavior would benefit the miner by more than 12-18 ETH, this behavior would be economically rational, creating an upper limit for the value that a contract using this method should be securing.

In an effort to avoid issues like these, smart contract developers already turn to off-chain solutions, where a random number is generated off-chain and brought on-chain. However, without cryptographic verification that the off-chain value is unbiased, there’s an opportunity for the result to be manipulated by the off-chain provider and/or by the data transport layer putting that random value on-chain. Likewise, the application’s users are forced to assume that the randomness is produced fairly and has been brought on-chain without being changed en route to the application.

Additional key trade-offs and security risks that we believe smart contract developers considering a source of randomness for the smart contract should seek to avoid include the following:

  • Inaccessibility by or incompatibility with smart contracts
  • Manipulation by the random number generator’s centralized operator
  • Exploitation by a blockchain’s miners as one of the application’s users
  • Unreasonably high trust requirements from end-users of the application

To help deal with these and other undesirable security risks, Chainlink VRF offers transparency and cryptographic proof that each result is fairly generated.

How Chainlink VRF Works

How Chainlink VRF works

Chainlink VRF works by combining block data that is still unknown when the request is made with the oracle node’s pre-committed private key to generate both a random number and a cryptographic proof. Each oracle uses its own secret key when generating randomness. When the result is published on-chain along with a proof, it is verified on-chain before being sent to a user’s contract. Relying on the widely accepted signature and proof verification capabilities of a blockchain enables contracts to consume only randomness that has also been verified by the same on-chain environment running the contract itself.

The fundamental benefit of using Chainlink VRF is its verifiable randomness. Even if a node is compromised, it cannot manipulate and/or supply biased answers — the on-chain cryptographic proof would fail. The worst-case scenario is that the compromised node does not return a response to a request, which will immediately and forever be visible on the blockchain. Users would no longer rely on nodes that stop responding and/or don’t provide randomness with a valid proof. Even in the unlikely scenario that a node is compromised, its resulting randomness cannot be manipulated. Compromised nodes can only withhold a request, giving no response, for which they would be financially penalized using Chainlink’s upcoming staking capabilities and removed from future queries that would have paid fees for their randomness, creating a substantial immediate and long-term economic loss for low quality and/or misbehaving node operators. In short, Chainlink VRF cannot manipulate an application that uses it properly; it can only go offline or withhold a single result before being removed as a source of any future randomness. This creates superior security for smart contract developers and their users.

An additional benefit of Chainlink VRF is that, as more users utilize it, user fees paid to node operators increase, creating an incentive for node operators to provide as many security guarantees as possible. Cryptoeconomic security through staking will likely be something users ask to increase over time and justify with their increasingly large fees, which pay for additional security. This leads to a shared global resource that is backed by user fees, and allows additional users who would have spent funds on making their own RNG solution to deploy those same funds towards increasing the collective security of a shared resource for the entire blockchain ecosystem. Chainlink’s ability to support various chains, such as Polkadot, Tezos and many others, means that the universe of users paying for this community resource will continue to grow in a network effect between usership and progressively increasing cryptoeconomic security guarantees.

Example Integration: PoolTogether

PoolTogether, the no-loss savings game on Ethereum, is something we find truly exciting and we’re thrilled that after extensive technical research by their team, they will be using Chainlink VRF to provide assurances to their users about the provably fair randomness of their application.

How PoolTogther uses Chainlink Verifiable Random Function

PoolTogether is a no-loss savings game that pools users’ deposits and distributes the earned interest on the pool to a randomly-selected winner in daily and weekly drawings.

By implementing Chainlink VRF’s verifiable randomness, PoolTogether users will be able to verify that each winner is selected with an unbiased source of randomness. In addition to being more sure of their own security, PoolTogether will also be able to prove to their users that a key part of their architecture is operating in a provably secure and verifiably random manner, providing users greater reason to believe that PoolTogether will actually provide a payout to them if they do become a participant in their smart contract.

Technical Walkthrough

Chainlink VRF is an implementation of Goldberg’s Verifiable Random Function (VRF) as described in this paper. The “random” in “verifiable random function” means “entirely unpredictable (uniformly distributed) to anyone who doesn’t know the seed or secret key.”

The VRF secret key is a number the oracle chooses from the uniform distribution on {0, …, #secp256k1-1}, in a cryptographically secure way. (secp256k1 is the elliptic curve used by ethereum’s cryptography.) Associated with this secret key is a public key, which is used to identify the oracle. The oracle registers the public key with the on-chain machinery, along with the chainlink job-ID it will respond to.

When a consuming contract makes a request for randomness, it broadcasts an Ethereum log requesting the corresponding VRF output from the oracle specified in the consumer request. On seeing this log, the oracle constructs the output as follows:

First, it “hashes the input to the curve,” obtaining a cryptographically secure random sample from secp256k1, using the unpredictable block data and the oracle’s public key as inputs. It does this by recursively hashing the inputs using keccak256 until the output is less than the order of secp256k1’s base field (“p” in that secp256k1 description), and is the x ordinate of some point (x,y) on secp256k1 (i.e., y2=x3+7 in the base field). (x,y) is then the hash of the input to the curve.

Then it multiplies (x,y), as a secp256k1 curve point by its secret key to obtain a point Ɣ. The keccak256 hash of Ɣ, as a uint256, is the VRF output. It generates a proof that Ɣ is the same multiple of (x,y) as the oracle’s public key is of the secp256k1 generator. This proof is very similar to a Schnorr signature: First, it securely samples a nonce n from {0, …, #secp256k1-1}, much as it did for its secret key, then it computes u=n×g, where g is the secp256k1 generator, and takes the Ethereum address of u. Then it computes v=(x,y). Next, it hashes together (x,y), its VRF public key, Ɣ, the address of u, and v, takes the remainder of that hash modulo #secp256k1, and calls that c. Finally, it computes s=n-c×k modulo #secp256k1, where k is its secret VRF key. The proof is then its public key, Ɣ, c, s, and its input seed. It sends this back to the on-chain VRF machinery, which verifies the proof, and sends the output back to the consuming contract, assuming the proof verifies.

To check the proof, the contract would ideally

For an intuition of why this is cryptographically secure, see the “arrow” analogy in the “Signing and Verification” section in chapter 3 of Jimmy Song’s book Programming Bitcoin. In our case, the special “target” we’re trying to hit is c. For a full proof of the security of this scheme, see Appendix B of “Making NSEC5 Practical for DNSSEC.”

Unfortunately, scalar multiplications on secp256k1 like Ɣ are extremely expensive to compute directly on the EVM, so for efficiency, we use Vitalik’s trick to verify that a witness passed into the proof as c×Ɣ, actually matches the product c×Ɣ. In this way, we push the burden of actually computing Ɣ off-chain, and only have to verify that the value we’ve been passed as Ɣ actually is Ɣ, which is much cheaper.

Thus, in addition to the the above inputs/steps, the on-chain verification of a proof involves witnesses for  c×Ɣ and s×(x,y), and verification includes checking that these witnesses are valid secp256k1 curve points, and match the products they purport to be, using Vitalik’s trick. In addition, we use the Ethereum address for u, and check that it matches the point c×pk+s×g using Vitalik’s trick.

The Planned Evolution of Chainlink VRF

Chainlink’s upcoming approach to highly scalable and cost-effective decentralization of oracle networks using threshold signatures will also provide extreme decentralization and availability for Chainlink VRF. By combining these two approaches, we gain all of the benefits of Chainlink VRF’s unique ability to provide on-chain verifiable randomness, combined with the ability to cost-efficiently have thousands of nodes providing Chainlink VRF’s uptime/availability.

A diagram showing the planned evolution of Chainlink VRF.

By allowing the wider ecosystem of Chainlink nodes to participate in Chainlink VRF random number generation, we arrive at a globally distributed network of node operators that are economically incentivized to both generate and broadcast verifiable random data on-chain. The use of Chainlink Threshold Signatures in combination with a highly decentralized network of node operators will help prevent adversaries from stealing user funds. Not only will responses from Chainlink VRF be verifiable on-chain; they’ll also have extreme uptime/availability, which in combination with cryptoeconomic guarantees and Chainlink’s availability on the various blockchains where verifiable randomness would be useful, is likely to make Chainlink VRF a standard for how smart contracts consume randomness.

In addition to the benefits mentioned above, we are currently improving Chainlink VRF and continuing both cutting-edge research on producing decentralized randomness and collaboration with other RNG systems. From our initial research, we believe that Chainlink VRF could be combined with VDF and other methods of generating randomness, both on-chain and off-chain. We’re excited to collaborate with both the larger blockchain industry and the larger academic community on how to make the best possible provably fair source of randomness for smart contracts.

Try Chainlink VRF and Give Feedback

If you are a smart contract developer and would like to know how you can use our initial implementation of Chainlink VRF, visit the developer documentation to integrate with it on testnet, and join the technical discussion on Discord.

We are in the final stages of security review for Chainlink VRF and want to engage with our users in both the developer community and the academic community. 

If making and supporting secure and reliable smart contracts which solve real-world problems sounds interesting in general, we are adding additional core team members at the moment! Learn more on our Careers page.

If you’d like to learn more about Chainlink generally, visit the Chainlink website or follow us on Twitter or Reddit.

Need Integration Support?
Talk to an expert
Faucets
Get testnet tokens
Read the Docs
Technical documentation