Secure Random Number Generation Technology for Blockchain Applications
TechFlow Selected TechFlow Selected
Secure Random Number Generation Technology for Blockchain Applications
There are various methods for generating random numbers on blockchains. This article explains and analyzes some of these methods along with their advantages and disadvantages.
Navigating Web3 tides with focused insights
Many blockchain applications require the use of random numbers generated from secure data sources.
For example, an NFT PFP collection airdrop may need to randomly assign trait combinations to each NFT image; a blockchain game might require randomly selecting items when opening a treasure chest. In both cases, a secure random number generator ensures fairness for users in front of the application. These are just a few possible use cases for randomness—generally speaking, randomness is a useful tool for solving many types of algorithmic problems.
Unfortunately, the inherent properties of blockchains make generating random numbers non-trivial. Blockchain state evolves according to a set of deterministic rules, where each transaction produces a specific output state given its inputs. These rules must be deterministic because blockchains require every validator to verify the processing of each transaction. If the rules were not deterministic, validators could end up in disagreement over the state.
There are various methods for generating random numbers on blockchains. This article explains and analyzes some of these methods along with their advantages and disadvantages.
Participants
Random number generation protocols typically involve multiple distinct participants. Each participant is either involved in the protocol or has an interest in the outcome. Depending on the method, different subsets of participants are involved. Possible participants include:
Application developers — Developers write the software that requests and uses random numbers. Although developers usually do not participate directly in generating the random numbers, they often desire truly random outcomes. For instance, a developer of an NFT collection would want to ensure no one can cheat in the minting process to obtain NFTs with all rare traits.
Users — Users initiate random number generation requests by interacting with the protocol. For example, a user could be someone minting an NFT.
Validators — Many random number generation protocols use input data from the blockchain. Validators (or miners/sequencers, depending on context) may have some control over this input data.
Service providers — Many protocols designate an off-chain service provider responsible for certain parts of the random number generation process. This service provider should ideally be a neutral third party, but more complex methods are required to minimize the trust placed in this participant.
Note that one individual may play multiple roles. For example, a user might themselves run a validator node on the blockchain network. Many attack vectors against these protocols arise from secret collusion among multiple participants.
Properties
Before discussing random number generation methods, we should establish a shared understanding of the desired properties of a random number generator.
Every random number generator operates in two phases. First, in the request phase, a user requests a random number from the generator. Then, in the reveal phase, the generator produces the random number and publishes it onto the blockchain. Each phase requires at least one blockchain transaction—it is impossible to securely generate on-chain random numbers within a single transaction. However, the exact computations performed in each phase vary across different protocols.
We focus on three main security properties:
Unpredictability — No participant can predict the random number before it is requested. This property formalizes what we mean by "random."
Determinism — After a random number is requested, it has only one possible value. This ensures that participants cannot influence the result after the request is made.
Liveness — After a random number is requested, the protocol completes immediately. That is, the completion of the request phase and the reveal phase occur simultaneously.
The key question regarding random number generation protocols is: under what conditions do these properties hold? For example, a protocol might require the service provider to remain honest. These conditions represent the protocol's trust assumptions. The fewer the trust assumptions, the more secure the protocol.
Random Number Generation Methods
Trusted Third Party
The simplest random number protocol involves having a service provider generate the random number. When a user requests a random number, the service provider simply generates one off-chain and posts it back to the blockchain.
This approach is very simple but requires strong trust assumptions: participants must trust the honesty of the service provider. The service provider is free to choose the random number and has the ability to abort the protocol. These assumptions can be somewhat improved by requiring the service provider to perform computation within a secure enclave (e.g., Intel SGX), although such enclaves have repeatedly been shown to be imperfect (SgxPectre attack).
Block Hash
A simple strategy for random number generation is to use the hash of a future block. The transaction requesting the random number records the current (or future) block number. Then, network validators compute the block hash for that block. Once the block hash becomes available, the generator publishes the reveal transaction.
This method is simple and easy to implement on any blockchain. However, it requires strong trust assumptions: participants must trust the honesty of the validators. Validators can reorder or omit transactions to manipulate the block hash. Therefore, users who run validators or collude with them pose a potential attack risk, enabling them to select favorable random numbers.
Verifiable Random Function (VRF)
The main problem with previously discussed methods stems from a single participant being able to influence the random number generation (making it predictable). Verifiable Random Functions (VRFs) eliminate this attack vector by requiring multiple participants to collaboratively affect the outcome.
A VRF is a function f_s(x) = (y, p), which produces an output y that appears random but is deterministically computed from an input x and a secret key s. Additionally, the function returns a proof p, which anyone can use to verify that y is indeed the correct output (this is a very brief explanation; for a more detailed overview, see the IETF RFC).
On blockchains, VRFs typically work as follows: first, the input x consists partly of user-provided data and partly of block hash data. An off-chain service provider monitors the blockchain for requests and, using secret key s, submits the corresponding on-chain values (y, p). The reveal transaction verifies the proof p to confirm y is correct, then publishes the result.
The benefit of VRFs is that they improve upon previous approaches by reducing trust assumptions: the user, validator, and service provider must all collude to predict the random number. The primary concern with VRFs is liveness: participants must trust that the service provider will not censor the transaction. The service provider sees the generated random number and can choose whether to submit it to the blockchain. For example, a possible attack could involve a user submitting a coin flip request and colluding with the VRF provider to complete the request only if the result is heads. However, application developers can mitigate such attacks—specifically, users have no incentive to carry out this attack if they cannot benefit from failed reveals.
Another drawback of VRFs is that the cryptography is relatively complex and computationally intensive. Most blockchains lack built-in support for all necessary cryptographic primitives, so publishing random numbers may consume significant gas or require multiple transactions.
Commit-Reveal
VRFs are not the only way to improve trust assumptions in random number generation. Another method is the commit-reveal protocol, used to generate random numbers between mutually untrusting parties. It works as follows:
-
In the request phase, both the user and the service provider generate a secret random number. They each submit the hash of their number to the blockchain. This hash is called the commitment.
-
In the reveal phase, both parties publish their original random numbers. Each checks that the other’s revealed number matches their commitment. Once verified, the final random number is the hash of both numbers. For blockchain deployments, the block hash from the request transaction can also be included in the final hashing step.
Compared to earlier methods, the commit-reveal protocol similarly improves trust assumptions: the user, validator, and service provider must all collude to predict the random number. Moreover, this protocol uses only simple cryptography—a hash function—making it easy to implement. However, it suffers from a liveness issue similar to VRFs: either the user or the service provider can abort the protocol by failing to reveal their number. As with VRFs, application developers can apply the same mitigation techniques described above.
Note that the basic implementation of this protocol requires more than two transactions, as both the user and service provider must send transactions in each phase. This limitation can be addressed through more sophisticated deployments allowing the service provider to pre-commit multiple random numbers. Pyth Entropy is an advanced implementation of the commit-reveal protocol.
Both VRFs and commit-reveal protocols allow application developers to trade liveness for unpredictability. If developers are concerned about relying on a single service provider, they can simply request random numbers from N providers and combine the results. This increases unpredictability—the N providers must all collude to influence the outcome—but reduces liveness—any one of the N providers can prevent the publication of the random number. However, note that no individual among the N providers knows the final random number, so they cannot use that knowledge to decide when to abort the protocol.
Other Methods
There are other, more advanced methods for generating secure random numbers. These aim to improve the unpredictability/liveness trade-off such that more than one provider is required to abort the protocol. One such method is threshold VRF, where the VRF secret key s is sharded among multiple participants. Another is a random beacon. While these methods do offer better security trade-offs than those discussed above, they may be overkill for most applications, since liveness issues can often be mitigated through careful application design.
Conclusion
This article introduced several methods for generating random numbers on blockchains and analyzed their pros and cons. If you are developing an application that requires a secure random number generator, consider checking out Pyth Entropy and reaching out to Pyth contributors via Discord, Telegram, or other social channels to learn how to use this innovative product.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@PythNetwork
