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
6

Quantova Inc has completed the EIP-8321 test rework suggested in the original specs pull request, now open as ethereum/consensus-specs#5739. It fixes a lifecycle test that could never pass on the mainnet preset and adds 19 tests that turn the security arguments of the beacon chain document into executable checks.

The construction under test

A validator draws a secret s, builds c_0 = s and c_{i+1} = BLAKE3(DST || c_i) up to c_L, and registers c_L. A proposal reveals r = c_{k-1}, the chain verifies BLAKE3(DST || r) = c_k, and the mix advances as m' = BLAKE3(m || r). Unpredictability of the next reveal rests on preimage resistance, about 2^256 classically and about 2^128 under Grover search, so the scheme stays sound against a quantum adversary where the BLS uniqueness argument does not.

What the tests establish

  • Accumulator. Under an xor accumulator a copied commitment cancels its victim, since m ⊕ h(r) ⊕ h(r) = m. Under the hash accumulator the copier’s re-injection yields BLAKE3(BLAKE3(m || r) || r), which equals neither m nor the victim’s mix except with probability about 2^-256. The test drives exactly that sequence and checks both inequalities.
  • Chain step. A replayed reveal is the stored commitment itself and fails the step. A reveal hashed without the domain separation tag, or under SHA 256 instead of BLAKE3, is rejected. The tagged commitment input is 49 bytes and the mix input is 64 bytes, so the two hash contexts cannot be confused.
  • Exhaustion. Once c_0 is revealed no preimage exists, and the proposer cannot fall back to the BLS reveal. At the recommended L >= 2^16, a validator of average weight in a set of one million proposes roughly once every 10^6 slots, or 139 days, so a chain lasts on the order of 25,000 years.
  • Activation timing. A registration included in epoch e activates at e + 3. The seed for that epoch derives from the mix at the end of e + 1, which is unknown at inclusion, so the registrant cannot see its duties in the activation epoch. The tests assert COMMITMENT_REGISTRATION_DELAY >= MIN_SEED_LOOKAHEAD + 2 on every preset.
  • Throughput. The cap holds at exactly 128 registrations per block, and 129 are rejected. At 7,200 slots a day that admits 921,600 registrations daily, enough to migrate a validator set of one million in about 1.1 days. A duplicate registration within one block is rejected.
  • Signatures. Registrations are bound to the fork agnostic domain and survive a fork version change. Signatures over the fork versioned domain, another chain’s genesis root or another validator index are rejected.
  • Mix composition. Over a full epoch of interleaved hash chain and BLS proposals, the mix equals the exact ordered fold of every reveal, and only the current epoch’s slot of the mix vector changes.

The mainnet fix

The lifecycle test registered the full default validator set in one block, 256 registrations against a cap of 128, so it failed on mainnet by construction. Registrations now span as many blocks as the cap requires, inside one epoch so they share an activation epoch.

All tests pass on the minimal and mainnet presets, reference tests generate, and lint is clean.

Quantova Inc runs a post quantum layer one and has built and tested hash based verifiable random functions for committee selection. Review is welcome on the pull request.

7

(post deleted by author)