So Ethereum goes for RANDAO. The disadvantage with RANDAO is that the last validator in the commit-reveal scheme is able to hold his contributed value back and thereby influence the random outcome. Ethereum is trying to overcome this by using verifiable delay functions.

  1. Why all that hassle?
  2. Why not just go for threshold signatures like Dfinity?
  3. What's the drawback?

Some link to a statement from Vitalik Buterin on this would be highly appreciated. Otherwise, if you can explain it it's also fine.


1 Answer 1


This post is a little old considering the current conversations going on about the various approaches to generate secure, safe, live and unbiased randomness in Ethereum 2.0.

Algorithmic Randomness ( Cryptographic Randomness ) in a decentralised data distribution and data monetisation protocol like ethereum is a very complex construct. The time stamping process in the ethereum network is a dynamic derivative of competitive and consensual time locks originating from various nodes in the hierarchy of the distributed data structure. Hence randomness functions as a function of time transitive and time truncated locks.

Ethereum 2.0 is proposing a combination of RANDAO ( biased entropy) + VDF (unbiased entropy) now as a choice for the source of randomness in the beacon chain. Justin Drake has written the following construction in the Ethereum Research forum.

Assume a global clock and split time into contiguous 8-second blocks and 128-slot epochs. Each epoch produces 32 bytes of (biasable) entropy to which correspond 32 bytes of (unbiasable) randomness In a recursive fashion, the beacon chain proposers of epoch (one per slot) are sampled using past randomness for some suitable constant.

A few researchers have opined that it will have the following advantages over the threshold signature scheme of DFNITY.

The threshold relay scheme from DFNITY stands out as not being biasable. Unfortunately, the beacon can stall if even a minority (e.g. 15% 1) of honest players go offline.

As indicated by @denett this does not work because the sampling process will weaken your honesty assumption. (Dfinity’s sampling weakens the global 2/3 honesty to 1/2 local honesty.) Sampling is required because the Distributed Key Generation (DKG) scales quadratically with the number of participants, and in practice you can’t get much more than 1,000 participants.

Another thing to consider is that there are two ways in which the Dfinity beacon can fail. Citing the whitepaper: “We treat the two failures (predicting and aborting) equally”. By improving liveness you make the readomness beacon easier to predict.

Finally, the RANDAO + VDF approach allows for arbitrarily low liveness assumptions. (For example, we could have a 1% liveness assumption by making the RANDAO epoch longer.)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.