EIP-8321: Hash-chain RANDAO

EIPs EIPs core
1

Discussion topic for EIP-8321

Hash-Chain RANDAO removes direct dependency on BLS signatures for beacon chain randomness

1 Like
2

Hi guys,

Is SSLE in scope for this?

Verification indexes state.randao_commitments[proposer_index], and a reveal opens a public per-validator commitment, so the contribution identifies the proposer. Under a hidden-proposer design that seems to need a set-membership proof, which costs the thing the hash chain is buying.

So: deliberately out of scope, expected from a separate mechanism, or something you’d want the RANDAO contribution to support later? Or am I missing something?

I posted a VRF-based alternative to the same problem months ago here; much worse on proof size, but the output is evaluable per input. Curious whether that direction was considered.

If it is not, and SSLE is on the table, I would be happy to help with it.

3

Hey :slight_smile:

Thanks for the question; I’d say SSLE is out of scope for this proposal

1 Like
4

Fo this proposal, or for Ethereum’s future in general?
If it is not out of scope for the Ethereum in general, do you agree that we should consider it for RANDAO’s future?

5

I can’t speak for Ethereum’s future in general, so I’d say it’s only for this proposal.

My personal opinion is that if we choose to do SSLE and land on a feasible design, we can change the CL then to accomodate for it

1 Like