Add EIP: On-chain upgrade signaling

EIPS/eip-7848.md

@@ -0,0 +1,122 @@
+---
+eip: 7848
+title: On-chain upgrade signaling
+description: Allows participants to indicate readiness for a client upgrade when producing blocks
+author: William Entriken (@fulldecent)
+discussions-to: https://ethereum-magicians.org/t/eip-7848-on-chain-upgrade-signaling/22306
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-12-22
+---
+
+## Abstract
+
+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.
+
+## Motivation
+
+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.
+
+## Specification
+
+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.
+
+### The Reference Implementation Hash
+
+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.
+
+### Verification
+
+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 referennce implementation.
+
+### Upgrade
+
+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 a 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.
+
+## Rationale
+
+### Forking is no Longer Possible
+
+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.
+
+### Community Direction
+
+1. The Ethereum project and community do not have an official mission statement or vision. However, this proposal asserts that the Ethereum community would prefer Ethereum Mainnet to be a community-directed project.
+2. On-chain signaling of upgrades enables community direction in a way that is not possible today.
+
+### Decentralization
+
+1. Currently, upgrade notices are published on blog.ethereum.org.
+2. The ethereum.org website has opaque ownership; for example, domain ownership (via whois) is redacted for privacy, and the website footer does not list a legal publisher.
+3. An opaque organization unilaterally announcing upgrades to client software is antithetical to the concept of a community-directed project.
+
+Under this new upgrade process, it would appropriate for Ethereum Foundation to change the way it blogs about upgrades as follows:
+
+```diff
+- The Ethereum network will be undergoing a scheduled network upgrade.
++ Ethereum Foundation proposes that clients upgrade and asks you to act now.
+```
+
+### Window
+
+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.
+
+## Backwards Compatibility
+
+### Trademark
+
+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 posess unique risks related to securities rules.
+
+### EIP-2124
+
+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.
+
+## Test Cases
+
+To do
+
+## Reference Implementation
+
+To do
+
+## Security Considerations
+
+Any upgrade that achieves less than 100% participation will harm validators who do not participate.
+
+- Overlapping or competitive upgrades must be managed carefully; such scenarios could result in multiple networks achieving the minimum approval threshold.
+- An upgrade with an excessively long time period could hinder the proposal of subsequent upgrades.
+- Since the four voting parameters are embedded in the reference implementation, network participants must exercise due diligence to ensure that they understand the actual software behaviors.
+
+## Copyright
+
+Copyright and related rights have been waived via [CC0](../LICENSE.md).