Add EIP: On-chain upgrade signaling

EIPS/eip-7848.md

@@ -0,0 +1,136 @@
+---
+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-xxxx-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 protocol upgrade by embedding a "vote" indicator in newly mined blocks in `extraData`. A future fork activation block occurs only if enough blocks within a specified window are signaled as "for" the upgrade.
+
+## Motivation
+
+Currently, upgrades to Ethereum Mainnet happen as prescribed on the Ethereum.org blog. This proposal changes that to instead upgrade based on consent from network participants.
+
+## Specification
+
+Network participants that support a given software upgrade will indicate this support by including specific bytes in the `extraData` field of every block they create.
+
+### The magic string
+
+When an upgrade is proposed, the person who announces the upgrade must specify the _upgrade magic string_. This shall be the SHA-256 hash of a feature-complete client software implementing the new version.
+
+### Verification
+
+Network participants shall study this new version of the software and decide if they would support an upgrade.
+
+### Acceptance
+
+If network participants would like to indicate support for the new version, they will include part of the _upgrade magic string_ in their `extraHash` blocks.
+
+Specifically, the high-order 128 bits of their `extraHash` shall be set to the high-order 128 bits of the _upgrade magic string_.
+
+### Upgrade
+
+Future upgrade proposals (what are often called "hard fork EIPs") shall specify an upgrade window and threshold:
+
+- `VOTING_WINDOW_BEGIN` the first block (inclusive) to count votes
+- `VOTING_WINDOW_END` the last block (inclusive) to count votes
+- `MAGIC_STRING` the complete 256-bit magic string, i.e. the hash of the software of the reference implementation
+- `REQUIRED_APPROVALS` the minimum number of approvals necessary for upgrade
+
+The difference (`VOTING_WINDOW_END` - `VOTING_WINDOW_BEGIN` ) must be strictly greater than 14400 (about 2 days) and should be chosen to support sufficient time to advertise upgrades to network participants.
+
+The required approvals must be strictly greater than 50% of the number of blocks in the voting window. But it should be much higher such as 95% or more.
+
+When the block with number `VOTING_WINDOW_END` is created, it is said the upgrade was successful if sufficient approvals were made; otherwise the upgrade failed.
+
+Block `VOTING_WINDOW_END` + 1 and later use the new software if and only if the upgrade was successful.
+
+For proof of work networks and other scenarios, please note that it is possible that one fork will approve the upgrade and the other will not. Still, this specification applies: block (`VOTING_WINDOW_END` + 1) shall be created according the rules of the software that is chosen as of the parent block `VOTING_WINDOW_END`.
+
+Note: just because `VOTING_WINDOW_END` + 1 is producing blocks according to the new software specification, this does not mean that this specific block must be created differently than the old software. For example, the new software may specify that changes in block creation do not start until some other time. Or perhaps there was some other change that did not result in a change to the block creation but just some other change was introduced.
+
+## Rationale
+
+### Community direction
+
+Since The Merge, it is practically no longer possible to "fork" Ethereum Mainnet. Because validators must stake valuable assets to participate in the network, any validator who is acting rationally must choose any software change decision based on what they think everybody else will do. If they expect 95% or more participants to make an upgrade, they should upgrade. If they expect 5% or less participants to make an upgrade they should not make the upgrade. For numbers in between, there is some threshold where a validator will have a better expected outcome from turning off their computer rather than risk participating in an uncertain upgrade. Note: turning off a validator incurs a small penalty, but running the wrong software version can slash 100% of your staked Ether (currently 16 ETH per share).
+
+Currently all software change decisions are decided from Ethereum Foundation. The Ethereum project and community does not have an official mission statement or vision, but this proposal asserts that the Ethereum community would wish Ethereum Mainnet to be a community-directed project. The current management of software change decisions are antithetical to that wish.
+
+This EIP moves decisions and signaling of changes to the community participants.
+
+Please note that the role of Ethereum Foundation does not change much in this respect. It can still involve in client development, and announcing changes. The difference is that Ethereum Foundation blog would use new language:
+
+```diff
+- The Ethereum network will be undergoing a scheduled network upgrade.
++ Ethereum Foundation proposes clients to upgrade and asks you to act now.
+```
+
+### Decentralization
+
+Currently, with Ethereum Foundation responsible for building (directly), deploying (indirectly) and marketing (directly) the Ethereum Mainnet software, there is a strong sense of centralization.
+
+This creates a unique risk related to securities rules in various jurisdictions.
+
+There are many details which this margin is too narrow to contain. But the thrust of this concern is that blockchains have been treated specially by specific rule interpretations on the basis that they are "decentralized networks" with no specific entity controlling them. Bitcoin is often cited as a clear example of meeting this criteria. Let's not leave any confusion about Ethereum Mainnet.
+
+### `blockHash`
+
+[TO DISCUSS]
+
+An alternative approach would be to add a separate `software` field to blocks. This would be a full SHA-256 hash of the reference implementation of consensus software.
+
+Benefit: it will be easier to alert if an unexpected upgrade is happening
+
+Bad thing: it is a bigger change
+
+### Window
+
+Counting votes within a sliding window provides real-time on-chain feedback about readiness.
+
+The fork only triggers after after successful completion of the window.
+
+## Backwards Compatibility
+
+### Trademark
+
+Ethereum Foundation (Stiftung Ethereum), Zug, Switzerland is the owner of the trademark "Ethereum".  This means that if you will publish a proposed upgrade to the Ethereum Mainnet consensus client, it is possible that the Foundation may be within its rights to stop you from marketing that software as an "Ethereum" client. See also "unique risk related to securities rules" above.
+
+The Foundation has not disclamed this power, it has not participated in an issue specifically asking (ethereum/ethereum-org-website#11752) about trademark enforcement of forks and it did not respond to comments the author of this EIP asked to its official press contact.
+
+### [EIP-2124](./eip-2124.md)
+
+EIP-2124 creates a mechanism to communicate software versions between nodes. However this does not allow to signal willingness before an upgrade. And it does not allow specify actually 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 that did not participate.
+
+[TO DISCUSS] Using `extraData` does not provide notification to validators that are not participating if an unexpected upgrade is happening.
+
+[TO THINK THROUGH] Careful and intentional choice of overlapping competitive upgrades could result in multiple networks achieving 50% and successful upgrades.
+
+[TO THINK THROUGH] An upgrade with a very long time period could prevent other upgrades from being proposed.
+
+[TO THINK THROUGH] Since the four voting parameters are germane inside the new software reference implementation itself, network participants not doing sufficient due diligence could be confused or tricked into to thinking the upgrade has happened when actully it did not (they though 99% votes were required, 98% came, but actually the software sasys 95% are required).
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).