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.
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.
This requires no changes to the Execution Layer.
The protocol can be summarized in the following concurrent steps:
The full specification of the proposed change can be found in /_features/whisk/beacon-chain.md. In summary:
BeaconState with fields needed to track validator trackers, commitments, and the two rounds of candidate election.select_whisk_candidate_trackers to compute the next vector of candidates from the validator set.select_whisk_proposer_trackers to compute the next vector of proposers from current candidates.process_whisk_updates to epoch processing logic.process_whisk_opening_proof to validate block proposer has knowledge of this slot's elected tracker.process_block_header to not assert proposer election with get_beacon_proposer_index, instead assert valid opening proof.BeaconBlockBody with fields to submit opening proof, shuffled trackers with proof, and tracker registration with proof.get_shuffle_indices to compute pre-shuffle candidate selectionprocess_shuffled_trackers to submit shuffled candidate trackers.process_whisk to block processing logic.apply_deposit to register an initial unique tracker and commitment without entropy.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.
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.
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.
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.
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.
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.
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.
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 and related rights waived via CC0.