What’s in Atlantis? EIP-161 (State-trie clearing ) — A simplified explanation.
Ethereum Classic is Going to Atlantis: Ethereum Classic (ETC) ECIP-1054 Hard Fork. The Atlantis ECIP contains a subset of upgrades including EIP-161 which has particular attention in the Ethereum Classic community because it proposes an irregular state change. Some don’t know what it is, some are unclear of its purpose, and I hope to simplify the implications of EIP-161 in this article.
The Ethereum Platform has a DoS attack vulnerability where someone can create empty accounts that increase the size of the blockchain.
EIP-161 makes it possible to remove empty accounts at a low cost. Removing the empty accounts reduces the size of the blockchain state which will increase the performance of the network. For example, a reduction in the blockchain state will decrease sync times for clients.
EIP-161 removes system empties and will not infringe on a user’s value or code. The context and result of EIP-161 are different than that of the radical and irregular Dao ICO bailout fork. The Dao ICO bailout fork changed the actual checks and balances of users to bail out special interests, and EIP-161 does not. EIP-161 is just storage sense.
In late September of 2016, ETH experienced DoS attacks that hindered the performance of the network. As a result, the attackers created significant state bloat of account empties; lacking code, balance, storage, and nonce == 0. EIP-161 was designed to clean these account empties and was implemented on November 22, 2016, block 2675000. However, the following days, a consensus bug was discovered due to two implementations having different behavior in the case of state reverts and was amended to clarify that empty account deletions are reverted when the state is reverted.
Update from May 30th core dev Atlantis call: All participating core dev stakeholders have consensus on the inclusion of EIP-161 for Atlantis.
Specification
a. Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialization code, increment the nonce over and above its normal starting value by one (for normal networks, this will be simply 1, however test-nets with non-zero default starting nonces will be different).
b. Whereas CALL and SUICIDE would charge 25,000 gas when the destination is non-existent, now the charge SHALL only be levied if the operation transfers more than zero value and the destination account is dead.
c. No account may change state from non-existent to existent-but-_empty_. If an operation would do this, the account SHALL instead remains non-existent.
d. At the end of the transaction, any account touched by the execution of that transaction which is now empty SHALL instead become non-existent (i.e. deleted).
Where:
An account is considered to be touched when it is involved in any potentially state-changing operation. This includes, but is not limited to, being the recipient of a transfer of zero value.
An account is considered empty when it has no code and zero nonce and zero balance.
An account is considered dead when either it is non-existent or it is empty.
At the end of the transaction is immediately following the execution of the suicide list, prior to the determination of the state trie root for the receipt population.
An account changes state when:
- it is the target or refund of a
SUICIDEoperation for zero or more value; - it is the source or destination of a
CALLoperation or message-call transaction transferring zero or more value; - it is the source or creation of a
CREATEoperation or contract-creation transaction endowing zero or more value; - as the block author (“miner”) it is the recipient of block-rewards or transaction-fees of zero or more value.
