Alberto (@71104) and I are proposing an EIP to hard-fork randao_reveal into a per-slot VRF. Instead of signing just the epoch number, the proposer now signs an SSZ container containing (a) the previous epoch’s RANDAO mix and (b) the current slot. Because the previous mix is unknown until the epoch closes, even the proposer can’t pre-compute future reveals, giving us unbiased randomness every slot.
Thank you for your proposal. I have some clarifying questions that I think would help figure out how much it would improve Ethereum.
Can you present an attack scenario that is thwarted by this change? The paper you reference uses last revealer attacks, and it does not seem like this change blocks those. The last n proposers in each epoch still have all the information they need when their slots come. Are there attacks where computing the randao mix multiple epochs in advance is useful?
Also a smaller thing: randao_reveal is already a VRF output, so I don’t think we can say we are turning it into a VRF.
A set of validators controlled by different actors may collude by publishing each other’s precomputed reveal sequences for future epochs, making the RANDAO bias vulnerability much worse.
That aside, the intended main goals of this proposal are:
to support EIP-7956, and
to pave the way for secret election of proposers, and that would completely block the RANDAO bias attack vector once and for all.
I’m open to a different phrasing, but the current one looks sound to me because in the current implementation the entire reveal sequence of a participant can be precomputed for the foreseeable future, so you can’t really call it a Verifiable Random Function or at least you can’t use it as one.