EIP-XXXX On-chain upgrade signaling – EIPs

This proposal adds a mechanism for clients to signal their readiness for a protocol upgrade by embedding a “vote” indicator in newly mined blocks of extraData. A future fork activation block will only occur if enough blocks within a specified window are signaled “for” the upgrade.

Network participants that support a given software upgrade will indicate this support by including specific bytes in the extraData field for each block they create.

If an upgrade is proposed, the person notifying the upgrade must specify the magic string upgrade. This is the SHA-256 hash of a feature-complete client software that implements the new version.

Network participants should study this new software version and decide if they will support an upgrade.

If network participants want to show support for the new version, they will include part of the upgrade the magic string in their extraHash blocks.

Specifically the high-order 128 bits in their extraHash set to high-order 128 bits of upgrade the magic string.

Future upgrade proposals (often called “hard fork EIPs”) must specify an upgrade window and criteria:

• VOTING_WINDOW_BEGIN the first block (inclusive) of counting votes
• VOTING_WINDOW_END the last block (inclusive) of the counting of votes
• MAGIC_STRING the complete 256-bit magic string, ie the hash of the reference execution software
• REQUIRED_APPROVALS the minimum number of approvals required for the upgrade

The difference (VOTING_WINDOW_END – VOTING_WINDOW_BEGIN ) must be strictly greater than 14400 (about 2 days) and must be chosen to support enough time to announce upgrades to the community.

The required approvals must be greater than 50% of the number of blocks in the voting window. But it should be much higher like 90% or more.

completion VOTING_WINDOW_END done, the upgrade is said to be successful if enough approvals have been made; otherwise the upgrade fails.

Block VOTING_WINDOW_END + 1 and later use the new software if and when the upgrade is 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. However, this specification applies: block (VOTING_WINDOW_END + 1) will be made according to the rules of the software chosen based on the voting window.

Note: just because VOTING_WINDOW_END + 1 generates blocks according to the new software specification, it does not mean that this specific block must be different from the old software. For example, new software may specify that changes to the block’s creation do not begin until some other time. Or maybe there is another change that does not result in a change in the blocks but another change is introduced.

Since The Merge, it is no longer possible to “fork” the Ethereum Mainnet. Since validators have to stake valuable assets to join the network any validator acting rationally should choose any software change decision based on what they think everyone else will do. If they expect 95% or more participants to make an upgrade, they should upgrade. If they expect 5% or less of participants to make an upgrade they shouldn’t upgrade. For numbers in between, there are some criteria where a validator has a better expected result from turning off their computer than risking participating in an insecure upgrade. Note: turning off the validator has a small penalty, but running the wrong version of the software will reduce 100% of your staked Ether (currently 16 ETH per share).

Currently all software change decisions are directed from the Ethereum Foundation. The Ethereum project and community do not have an official mission statement or vision, but this proposal states that the Ethereum community hopes that the Ethereum Mainnet will be a community-managed project. Current management of software change decisions is antithetical to that preference.

This EIP drives decisions and signals changes to community participants.

Please note that the role of the Ethereum Foundation has not changed much in this regard. It can also be involved in client development, and notification of changes. The difference is that the Ethereum Foundation blog will use a new language:

- The Ethereum network will be undergoing a scheduled network upgrade
+ Ethereum Foundation proposes clients to upgrade and asks you to act now

Currently, with the 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 the securities rules of various jurisdictions.

During the upgrade to proof of stake, Ether may begin to be used to generate staking fees. In our community (this proposal says) we understand that this generated fee is a direct payment for providing a real and valuable staking service. Regulators see this fungible commodity asset that creates more of its own type of fixed ratio proportional to time, and they may fail to understand the unique service provided by each validator. They may think it is a security. In fact, after The Merge, the United States Securities and Exchange Commission sent letters requesting details of the authors of the EIP for staking rewards (see: Coinbase Wells Notice and lawsuit).

There are so many details that this margin is too narrow to fit. But what drives this concern is that blockchains are treated primarily with specific interpretations of the rule 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.

(TO DISCUSS)

An alternative approach is to add a different one software field into blocks. This is a full SHA-256 hash of the reference implementation of the consensus software.

Advantage: it’s easier to be alerted when an unexpected upgrade happens

Bad thing: it’s a bigger change

Counting votes within a sliding window provides real-time on-chain feedback about readiness.

The fork will only trigger after the successful completion of the window.

The Ethereum Foundation (Stiftung Ethereum), Zug, Switzerland is the owner of the “Ethereum” trademark. This means that the Ethereum Foundation is empowered to stop other people from using this name commercially.

This means that if you propose a fork to the Ethereum Mainnet, and it is successful, but the Ethereum Foundation does not agree to that change, then the Ethereum Foundation can sue you and prevent you from mentioning that thing “Ethereum”. See also “unique risk related to securities regulations” above.

dO

dO

Any upgrade achieved with less than 100% participation will harm non-participating validators.

(TO DISCUSS) Usage extraData does not provide notification to non-participating validators when an unexpected upgrade occurs.

(IN THINKING) Careful and deliberate selection of overlapping competitive upgrades can result in many networks achieving 50% and successful upgrades.

(IN CONSIDERATION) An upgrade with a very long time period may prevent other upgrades from being suggested.

(TO THINK THROUGH) Because the four voting parameters are contained within the new software reference implementation itself, network participants who have not done enough due diligence may be confused or misled into thinking that the -upgrade occurred when in fact it did not exist (although they were 99% votes. necessary, 98% came, but in fact the software sasys 95% necessary).
Needs discussion.