This proposal adds a mechanism for clients to signal their willingness for a network upgrade by including a “reference implementation hash” field in each block. A network upgrade activates only if enough blocks specify that they are using the new software.
Currently, upgrades to Ethereum Mainnet are announced on the ethereum.org blog. This proposal changes that process by activating upgrades based on the consent of network participants.
Ethereum consensus clients shall identify with a reference implementation having its equivalent behaviors.
Ethereum consensus clients shall include a referenceImplementationHash (specified below) field immediately following the extraData field in the block header.
Proposed new Ethereum consensus clients shall initially behave as the then-current network does. If, and only if, a successful upgrade (defined below) is activated will the new behavior take effect.
When a network participant is willing to support a network upgrade, they shall immediately begin using the new software. The blocks they create including the new referenceImplementationHash will contribute to the network upgrade activation.
When proposing a network upgrade, the proposer shall point to a published, feature-complete reference implementation including the new software behaviors.
The reference implementation hash is the SHA-256 hash of the tarred source code of this reference implementation.
Network participants shall study the reference implementation and decide whether they support an upgrade.
Network participants shall study any specific software they will run and ensure it faithfully implements the behaviors consistent with that reference implementation.
Upgrade proposals (often referred to as hard fork EIPs) must specify an upgrade window and threshold. These parameters are implemented in the consensus client:
VOTING_WINDOW_BEGIN: the first block (inclusive) to count votes.VOTING_WINDOW_END: the last block (inclusive) to count votes.REFERENCE_IMPLEMENTATION_HASH: this is defined above.REQUIRED_APPROVALS: the minimum number of approvals necessary for the upgrade.The difference (VOTING_WINDOW_END - VOTING_WINDOW_BEGIN) must be strictly greater than 14400 (about two days) and should be chosen to provide sufficient time to advertise the upgrade to network participants.
The required approvals must be strictly greater than 50% of the blocks in the voting window. A higher threshold (such as 95% or more) is recommended.
When the block numbered VOTING_WINDOW_END is created, the upgrade is considered "activated" if REQUIRED_APPROVALS or more blocks during the voting window had set referenceImplementationHash to the value REFERENCE_IMPLEMENTATION_HASH; otherwise, the upgrade fails.
Blocks created from VOTING_WINDOW_END + 1 onward will use the new software behaviors if and only if the upgrade was successful.
For proof-of-work networks and other scenarios, it is possible that one fork activates the upgrade while another does not. In any case, blocks strictly greater than VOTING_WINDOW_END shall be created according to the behaviors of the software considering the outcome of the votes in the voting window which are the ancestors of that block.
Note: Just because an upgrade was activated, this does not necessarily mean that the new software behaviors must generate block VOTING_WINDOW_END + 1 differently than the old software behaviors. Perhaps the new software behaviors will stipulate that only blocks at some later time will generate differently. Perhaps the new software behaviors include some other consensus change which does not change how blocks are created.
Since the merge, forking Ethereum Mainnet has become practically impossible. Validators stake valuable assets to participate in the network, so any rational validator will choose to upgrade only if they expect widespread adoption. If a validator expects 95% or more participants to upgrade, they should upgrade; if they expect only 5% or less, they should not. For intermediate cases, there is a threshold where a validator would rationally shut down (incurring a small penalty) rather than risk participating in the wrong network—which could result in slashing 100% of their staked ether (currently 16 Ether per share).
Therefore, proper management of consensual upgrades is crucial.
Using a voting window to count votes provides real-time on-chain feedback about upgrade readiness. The upgrade is activated only after the successful completion of the voting window.
The Ethereum Foundation (Stiftung Ethereum), Zug, Switzerland, owns the trademark “Ethereum.” As a result, if anybody publishes a proposed Ethereum Mainnet consensus client, the foundation may have the right to restrict marketing of that software as an “Ethereum” client. That also poses unique risks related to securities rules.
EIP-2124 introduces a mechanism to communicate software versions between nodes. However, it does not allow for signaling readiness before an upgrade, nor does it specify what software is being upgraded to.
Any upgrade that achieves less than 100% participation will harm validators who do not participate.
Copyright and related rights have been waived via CC0.