1
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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. However for a better update on the ongoing conversations, please let me share the latest progress in this discussion.

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 in the discussion forum 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.)

I had relentless participated in the Starkware Veedo Streak hackathon and used the VDF based Randomness through Beacon contracts deployed in TestNet and MainNet. It looks like the VDF approach is gaining traction in the Ethereum Research community.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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