Simplify the definition of EIP-161, removing the requirement for implementors to support edge cases that are impossible on Ethereum Mainnet.
EIP-161 is overly complex and has a number of edge cases that are poorly documented and tested. This EIP takes advantage of the complete removal of all remaining empty accounts in block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d) to clarify it, and allows implementors to not implement various edge cases that never occurred and are not possible in the future.
In particular, this EIP permits implementors who do not wish to support historical blocks to not implement state clearing at all.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Retroactively replace EIP-161, starting from its introduction in block 2675000, with the following rules:
a. When creating an account, set it's nonce to 1 prior to executing initcode.
b. When performing EVM execution treat all empty accounts as if they do not exist. Any operation that would create an empty account instead leaves it non-existent.
c. If one of the following events happens to an empty account X, it is deleted:
X receives a zero value CALL.X is the recipient of a zero value transaction.X is the beneficiary of a SELFDESTRUCT with zero value.If the transaction, CALL or SELFDESTRUCT is reverted, then the state clearing is also reverted. As a special case on Ethereum Mainnet, in block 2675119 (tx 0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba), an empty call is made to an empty account at RIPEMD160 (precompile 0x3), the call fails out of gas, but the empty account is removed anyway.
The deletion MAY happen immediately or be processed at the end of the transaction. A client may assume that STATICCALLs to empty accounts never occur and that CALLs to empty accounts in STATICCALL contexts never occur.
On Ethereum Mainnet, the only state clearing events after the start of Byzantium are the two listed below. Clients MAY implement post Byzantium state clearing by hardcoding those events.
In block 4457731 (tx 0x63791f962e13e6b01ec13d38a8ab66c87c2f5a1768276f866300d900cca808fe), 0xd29DFe5aE95B5C067a91F472Dac0d9be6700A4A9 receives a zero value SELFDESTRUCT and is cleared.
In block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d), the following accounts receive zero value calls and are cleared.
EIP-161 provides that empty accounts (accounts that have zero nonce, zero balance and no code, but that might have storage) can no longer be created and provides mechanism to remove old empty accounts. The last empty accounts were removed in block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d).
The complete removal of all empty accounts ensures that certain edgecases of EIP-161 can never occur on Ethereum Mainnet. Continuing to define and test those cases as part of the Ethereum Specification burdens future client implementors with unnecessary technical debt. This EIP declares those cases undefined and leaves clients free to assume they will not occur.
This EIP is identical to EIP-161 except for the following differences, none of which affect Ethereum Mainnet. The differences are:
EIP-161 specifies 11 "potentially state-changing operations" that trigger state clearing. All but the 3 listed in this EIP are irrelevant, for the following reasons:
CREATE.CALL.SELFDESTRUCTCREATE.STATICCALLThe interaction between STATICCALL and account clearing has never been specified in an EIP. The Ethereum currently testsuite requires that STATICCALL triggers state clearing.
This EIP formally undefines all interactions between STATICCALL and state clearing as it has never happened on Ethereum Mainnet and cannot happen in future.
This only makes a difference if an account is deleted and later recreated in the same transaction. This never happens on Ethereum Mainnet.
All test cases involving empty accounts in the Ethereum execution layer test suite shall be removed unless they relate to the Spurious Dragon Hardfork. If a Spurious Dragon test relates involved deprecated edgecase the test must be removed or reworked.
Ropsten had empty accounts seeded at genesis. They appear to have been cleared early in Ropsten's history before the Byzantium hardfork. Ropsten has never been checked for edgecases occurring. All other Ethereum testnets have had EIP-161 from genesis.
As a security precaution all empty accounts on Ethereum Classic have been cleared, but no checks for edgecases occurring have been done. Due to EIP-161's age the vast majority of EVM compatible networks have supported it from genesis.
This EIP is only equivalent to EIP-161 on Ethereum Mainnet if the following facts are true:
Copyright and related rights waived via CC0.