Randomness FAQs
Last updated
Was this helpful?
Last updated
Was this helpful?
Yes! it is activated on the Gnosis Chain. The RandomAura contract provides on-chain random numbers.
RandomAuRaCode
June 2021
RandomAuRaProxy
June 2021
Currently, randomness is created through a -like process, where validators commit the hash of a random number to the chain, then reveal that number later on. The revealed number is XORd with a previous random seed, creating a new random seed. For more details, see
In the future, per-block randomness will be available following the Gnosis Chain - Gnosis Beacon Chain merge.
No! Random values are only created during the reveals phase, which occurs every 38 blocks and continues for a period of 38 blocks (note this value is configurable).
A complete collection phase is currently set to 76 blocks. The first half (the first 38 blocks) is called the commit phase, where random number hashes are committed by validators. The second half (the second 38 blocks) is the reveal phase, where numbers are revealed and added to the currentSeed getter.
Entropy increases throughout the reveal phase, and the final number revealed is the most secure. Applications requiring secure randomness should retrieve the currentSeed from the final block of a reveal phase or during a commit phase.
Business logic actions that require randomness should not be allowed during the reveal phase. In addition, randomness can never be guaranteed for block N + 1, only for some block between N + commitRoundLength and N + 2*commitRoundLength.
It is possible to create an on-chain PRNG where the currentSeed value is used to seed a generator. However, as soon as the seed is known, the whole sequence is known! To add additional entropy, the seed may be salted with the block hash, however this method is still not considered secure.
While secure, there are considerations to keep in mind. It is possible that malicious validators may choose to manipulate the outcome by not revealing their number. Validators cannot change the number they have committed, but they can choose to not commit or not reveal a number.
This means that during the reveal phase, a validator can effectively choose between 2 numbers, either the current number or the new one that will be created when they reveal their number. If an application uses the final number of the reveals phase, only the final validator can make this choice, limiting the scope of this issue.
To discourage skipping, validators who skip too often (or skip at the end of an epoch) will be reported as malicious. In POSDAO, malicious validators are banned from the protocol for 90 days and their STAKE frozen.
Yes, with the consensus-layer Gnosis Beacon Chain.
We've done preliminary research into HoneyBadger BFT, however this is on hold as the consensus process will shift to Gnosis Beacon Chain following the merge.
A little on HoneyBadger BFT
With HoneyBadger BFT, reliable random numbers will be produced per block via threshold signatures.
Using this approach, validators will signal their approval of a block by providing a portion of a signature (a signature share) rather than the entire signature. Once a predetermined number of shares are received by the algorithm (the threshold), they are combined to create a single signature which cannot be known beforehand. Because this number is secret until it is revealed, it can be used as a random number. A special property of this algorithm is that any combination of validators can collaborate to create the same final signature.
The value is contained in the currentSeed getter. It is important to check the phase (commit or reveal) and determine when the value is created. Details are available on the page.
A simple way to turn a single seed into multiple numbers is to use hash(currentseed+0) , hash(currentseed+1), hash(currentseed+2), etc., or something similar (e.g. hash(currentseed+previousHash)). Limitations of this method (regarding security and speed) are discussed here:
For more on HoneyBadger BFT, see