EIP-7441: Upgrade block proposer election to Whisk
Allow elected block proposers to remain private until block publishing, to prevent DoS attacks
Abstract
Upgrades the block proposer election mechanism to Whisk, a single secret leader election (SSLE) protocol. Currently, block proposers are publicly known in advance, sufficiently to allow sequential DoS attacks that could disable Ethereum. This upgrade allows the next block proposer to remain secret until its block is published.
Motivation
The beacon chain currently elects the next 32 block proposers at the beginning of each epoch. The results of this election are public and everyone gets to learn the identity of those future block proposers.
This information leak enables attackers to launch DoS attacks against each proposer sequentially in an attempt to disable Ethereum.
Specification
Execution layer
This requires no changes to the Execution Layer.
Consensus layer
The protocol can be summarized in the following concurrent steps:
- Validators register a tracker and unique commitment on their first proposal after the fork
- At the start of a shuffling phase a list of candidate trackers is selected using public randomness from RANDAO
- During each shuffling phase each proposer shuffles a subset of the candidate trackers using private randomness
- After each shuffling phase an ordered list of proposer trackers is selected from the candidate set using RANDAO
The full specification of the proposed change can be found in /_features/whisk/beacon-chain.md
. In summary:
- Update
BeaconState
with fields needed to track validator trackers, commitments, and the two rounds of candidate election. - Add
select_whisk_candidate_trackers
to compute the next vector of candidates from the validator set. - Add
select_whisk_proposer_trackers
to compute the next vector of proposers from current candidates. - Add
process_whisk_updates
to epoch processing logic. - Add
process_whisk_opening_proof
to validate block proposer has knowledge of this slot's elected tracker. - Modify
process_block_header
to not assert proposer election withget_beacon_proposer_index
, instead assert valid opening proof. - Update
BeaconBlockBody
with fields to submit opening proof, shuffled trackers with proof, and tracker registration with proof. - Add
get_shuffle_indices
to compute pre-shuffle candidate selection - Add
process_shuffled_trackers
to submit shuffled candidate trackers. - Add
process_whisk
to block processing logic. - Modify
apply_deposit
to register an initial unique tracker and commitment without entropy.
Rationale
Fields per validator
Whisk requires having one tracker (rG,krG)
and one unique commitment kG
per validator. Both are updated only once on a validator's first proposal after the fork.
Trackers are registered with a randomized base (rG,krG)
to make it harder for adversaries to track them through shuffling gates. It can become an issue if the set of honest shufflers is small.
Identity binding
Each tracker must be bound to a validator's identity to prevent multiple parties to claim the same proposer slot. Otherwise, it would allow proposers to sell their proposer slot, and cause fork-choice issues if two competing blocks appear.
Whisk does identity binding by storing a commitment to the tracker's secret kG
in the validator record. Storing the commitment also ensures the uniqueness of k
.
Alternatively, identity binding can be achieved by forcing the hash prefix of hash(kG)
to match its validator index. However, validators would have to brute force k
making bootstrap of the system harder for participants with fewer computational resources.
Identity binding can also be achieved by setting k = hash(nonce + pubkey)
. However, proposers will need to reveal k
and be de-anonymized for repeated proposals on adjacent shuffling phases.
Alternative: non-single secret election
Secret non-single leader election could be based on protocol engineering rather than cryptography, thus much simpler and cheaper than Whisk. However, it complicates the fork-choice and opens it up to potential MEV time-buying attacks, making it an unsuitable option at the time of writing.
Alternative: network anonymity
Privacy-preserving networking protocols like Dandelion or Dandelion++ increase the privacy of network participants but not sufficiently for Ethereum's use case.
SASSAFRAS is a simpler alternative SSLE protocol consensus-wise, but it relies on a network anonymity layer. Its specific trade-offs do not fit Ethereum's overall threat model better than Whisk.
Backwards Compatibility
This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.
PBS participants (e.g. builders) will not know the next proposer validator index to use a specific pre-registered fee recipient; unless the proposer chooses to reveal itself ahead of time. Block explorers and tooling will not be able to attribute missing slots to a specific validator index.
Security Considerations
The shuffling strategy is analyzed in a companion paper and considered sufficiently safe for Whisk's use case. The data and computational complexity of this EIP are significant but constant, thus does not open new DoS vectors.
Anonymity set
The anonymity set in Whisk is the set of 8,192 candidates that did not get selected as proposers. That count of validators corresponds to a smaller number of p2p nodes. Assuming a Pareto principle where "20% of the nodes run 80% of the validators" the anonymity corresponds to 2,108 nodes on average. A bigger candidate pool could make the shuffling strategy unsafe while shuffling more trackers per round would increase the cost of the ZK proofs.
RANDAO biasing
Whisk uses RANDAO in the candidate selection and proposer selection events, and is susceptible to potential RANDAO biasing attacks by malicious proposers. Whisk security could be made identical to the status quo by spreading the selection events over an entire shuffling period. However, status quo security is not ideal either and it would complicate the protocol further.
Copyright
Copyright and related rights waived via CC0.