Alert Source Discuss
🚧 Stagnant Standards Track: Core

EIP-7441: Upgrade block proposer election to Whisk

Allow elected block proposers to remain private until block publishing, to prevent DoS attacks

Authors George Kadianakis (@asn-d6), Justin Drake (@JustinDrake), dapplion (@dapplion)
Created 2023-09-01
Discussion Link https://ethereum-magicians.org/t/eip-7441-upgrade-block-proposer-election-to-whisk-ssle/15316

Table of Contents

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 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 and related rights waived via CC0.

Citation

Please cite this document as:

George Kadianakis (@asn-d6), Justin Drake (@JustinDrake), dapplion (@dapplion), "EIP-7441: Upgrade block proposer election to Whisk [DRAFT]," Ethereum Improvement Proposals, no. 7441, September 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7441.