forked from ethereum/EIPs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add EIP: Retroactively Included EIPs
Merged by EIP-Bot.
- Loading branch information
Showing
1 changed file
with
52 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
--- | ||
eip: 7675 | ||
title: Retroactively Included EIPs | ||
description: Core EIPs activated independently of an Ethereum hard fork. | ||
author: Tim Beiko (@timbeiko) | ||
discussions-to: https://ethereum-magicians.org/t/eip-7675-retroactively-included-eips/19541 | ||
status: Draft | ||
type: Meta | ||
created: 2024-04-04 | ||
requires: 2681, 3607, 7523, 7610 | ||
--- | ||
|
||
## Abstract | ||
|
||
This Meta EIP lists Core EIPs introducing changes to Ethereum's consensus which were activated independently of an Ethereum hard fork due to their backward compatible nature. These EIPs generally introduce constraints to underspecified protocol rules or clarify how certain edge cases should be handled. | ||
|
||
## Motivation | ||
|
||
To maintain consensus across all nodes, backward incompatible changes to Ethereum must be activated synchronously. Given the coordination required for this, changes are usually bundled together in network upgrades. A Meta EIP is typically used to list the changes included in a network upgrade, as well as its activation time. | ||
|
||
However, backward compatible consensus changes do not require a network upgrade to be activated. For example, if a consensus rule is underspecified, an EIP can propose a constraint to bound it. If the constraint was never broken in Ethereum's history and is unlikely to be broken in the future, the EIP can be considered backward compatible. It could then be "retroactively activated", as both nodes which support the change and those which do not would agree on the current network state and history. | ||
|
||
This Meta EIP lists all such EIPs which core developers have retroactively included as part of the Ethereum protocol specification. | ||
|
||
## Specification | ||
|
||
### Retroactively Activated EIPs | ||
|
||
* [EIP-2681](./eip-2681.md): Limit account nonce to 2^64-1 | ||
* [EIP-3607](./eip-3607.md): Reject transactions from senders with deployed code | ||
* [EIP-7523](./eip-7523.md): Empty accounts deprecation | ||
* [EIP-7610](./eip-7610.md): Revert creation in case of non-empty storage | ||
|
||
### Activation | ||
|
||
All EIPs listed above are considered activated as of Ethereum's genesis block. Note that EIP-7523 distinguishes pre- and post-merge behavior on the Ethereum mainnet. | ||
|
||
## Rationale | ||
|
||
This Meta EIP provides a global view of all changes included in the Ethereum protocol without an explicit network upgrade, as well as links to full specification. | ||
|
||
## Backwards Compatibility | ||
|
||
No backward compatibility issues found. | ||
|
||
## Security Considerations | ||
|
||
None. | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](../LICENSE.md). |