Add EIP: Upgrade block proposer election to Whisk

EIPS/eip-7441.md

@@ -0,0 +1,101 @@
+---
+eip: 7441
+title: Upgrade block proposer election to Whisk
+description: Allow elected block proposers to remain private until block publishing, to prevent DoS attacks
+author: George Kadianakis (@asn-d6), Justin Drake (@JustinDrake), dapplion (@dapplion)
+discussions-to: https://ethereum-magicians.org/t/eip-7441-upgrade-block-proposer-election-to-whisk-ssle/15316
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-09-01
+---
+
+## 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`](https://github.com/ethereum/consensus-specs/blob/a39abe388bc2d1abd5b4fd62fd18aed497956b30/specs/_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 with `get_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](../LICENSE.md).
+