# Deprecating empty accounts ## Summary Rather that continuing to define and test new empty account edgecases, I propose that prestates containing empty accounts on merged networks are declared to be invalid and clients are not required to support them. ## Are empty accounts really gone? Yes, no production network has remaining empty accounts. Almost everything has Spurious Dragon activated from genesis. The exceptions are: * Ethereum Mainnet was cleared in block 14049881. * Ethereum Classic has also been cleared. * Ethereum Classic has testnets that may have empty accounts, but they are unimportant. ## Checking network validity On Mainnet, manual checking is required to confirm that the TTD block does not contain empty accounts. The most straightforward way is to sync geth to a premerge block and use the `geth dump` command. For everything else, the following checks suffice: * Spurious Dragon was activated from genesis (`"eip158Block": 0` in geth style config) * No empty accounts were seeded at genesis ## Testing implications All tests that have a post merge fork with empty accounts should be rectified. Tests about empty accounts can be limited to pre-merge forks or removed. Some tests about other things that have empty accounts by happenstance should have the empty accounts removed. Ideally testing tools should check for empty accounts in post merge empty accounts in tests and complain that the test is invalid if they are found. ## Draft EIP --- eip: * title: Prohibit empty accounts after the merge description: * author: Peter Davies (@petertdavies) discussions-to: * status: Draft type: Standards Track category: Core created: * requires: 161 --- ### Abstract We prohibit the state of any post-merge network from containing empty accounts. As in EIP-161, empty account means an account with zero nonce, zero balance, zero code. Since it is no longer possible to create empty accounts, the only requirement imposed on clients is to check that the state of the merge block does not contain empty accounts. ### Motivation The possibility of empty accounts is a historical artifact of the early history of Ethereum. The only networks that have ever been capable of containing them are Ethereum Mainnet, the deprecated testnet Ropsten, Etheruem Classic Mainnet and various Ethereum Classic testnets. All remaining empty accounts on Mainnet were cleared in block `14049881` (transaction `0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d`) and a similar transaction was sent on Ethereum Classic. None of the myriad EVM-compatible networks are old enough to have empty accounts and there is no realistic prospect that anyone will encounter an empty account in a production context. Despite empty accounts no longer existing, they still impose a legacy of technical debt. EIP-161 imposes complicated rules that require a client to delete an empty account when it is "touched". As the Ethereum specification continues to evolve new edgecases of the "touch" rules arise which must be debated, implemented, tested and documented. If a future client wishes to only support post-merge blocks it must implement unnecessary empty account support solely to pass the test suite. By prohibiting empty accounts on post-merge networks, this EIP frees designers and implementors of Ethereum and related blockchains from the burden of having to consider empty accounts. ### Specification The definition of an empty account is the same as in EIP-161. On networks that undergo the merge transition, the TTD block may not contain any empty accounts. For networks that have had proof of stake since genesis, none of the genesis accounts may be empty accounts. Rather than performing a scan of the state, clients MAY the following chains have no post merge empty accounts: 1. The Mainnet chain who merge block has hash `0x56a9bb0302da44b8c0b3df540781424684c3af04d0b7a38d72842b762076a664`. 2. Any chain on a network which: - has no empty accounts in the genesis. - had a post Spurious Dragon fork at genesis. The Ethereum specification is declared to be undefined in the presence of an empty account in a post-merge context. Any testcase involving post-merge empty accounts is invalid. ### Rationale This EIP was drafted to be the simpliest possible way of eliminating the long term technical debt imposed by empty accounts. The Merge was chosen as a natural easily identifiable cutoff point. Alternative approaches include: * Using an earlier cutoff point, such as block `14049881`. * Identifying a wider range of edge case behaviour that never happened (e.g EIP-4747). These approaches were rejected as being unnecessarily complicated, ### Backwards Compatibility As EIP does not change any behaviour that can occur outside the testsuite, it has no backwards compatibility consequences. ### Security Considerations The validity of this EIP is dependent on the assertion that all empty accounts on Ethereum Mainnet were cleared prior to the merge. This should be subject to appropriate verification.