Add EIP: Empty accounts deprecation

EIPS/eip-7523.md

@@ -0,0 +1,62 @@
+---
+eip: 7523
+title: Empty accounts deprecation
+description: Prohibit empty accounts on post-merge networks
+author: Peter Davies (@petertdavies)
+discussions-to: https://ethereum-magicians.org/t/eip-7523-empty-accounts-deprecation/15870
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-09-19
+requires: 161
+---
+
+## Abstract
+
+This EIP prohibits the state of any post-merge network from containing empty accounts. Since no empty accounts exist outside the testsuite and no new ones can be created this requirement is already achieved in practice. An explicit ban reduces technical debt going forward.
+
+## 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 other 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](./eip-161.md) 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 them going forward.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+An empty account is an account with has **no code** and **zero nonce** and **zero balance**. This is the same as the definition in [EIP-161](./eip-161.md).
+
+On networks that undergo the merge transition, the pre state of the merge block may not contain any empty accounts. For networks that are merged at genesis, none of the genesis accounts may be empty accounts.
+
+Rather than performing a scan of the state, clients MAY assume the following chains have no post-merge empty accounts:
+1. The Mainnet chain whose merge block has hash `0x56a9bb0302da44b8c0b3df540781424684c3af04d0b7a38d72842b762076a664`.
+2. Any chain 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.
+
+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.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).