Merge pull request #652 from cdetrio/eips-158-161

create files for EIPs 158 and 161

EIPS/eip-158.md

@@ -0,0 +1,42 @@
+```
+EIP: 158
+Title: State clearing
+Author: Vitalik Buterin
+Type: Standard Track
+Category: Core
+Status: Superseded
+Created: 2016-10-16
+Superseded-By: 161
+```
+
+# Specification
+
+For all blocks where `block.number >= FORK_BLKNUM` (TBA):
+1. In all cases where a state change is made to an account, and this state change results in the account state being saved with nonce = 0, balance = 0, code empty, storage empty (hereinafter "empty account"), the account is instead deleted.
+2. If a address is "touched" and that address contains an empty account, then it is deleted. A "touch" is defined as any situation where if the account at the given address were nonexistent it would be created.
+3. Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution.
+4. Zero-value calls and zero-value suicides no longer consume the 25000 account creation gas cost in any circumstance
+
+The cases where a "touch" takes place can be enumerated as follows:
+- Zero-value-bearing CALLs
+- CREATEs (if the code that is ultimately saved is empty and there is no ether remaining in the account when it is saved)
+- Zero-value-bearing SUICIDEs
+- Transaction recipients
+- Contracts created in contract creation transactions
+- Miners receiving transaction fees (note the case where the gasprice is zero, and the account does not yet exist because it only receives the block/uncle/nephew rewards _after_ processing every transaction)
+### Specification (1b)
+
+When the EVM checks for emptiness (for the purpose of possibly applying the 25000 gas cost), emptiness is defined by `is_empty(acct): return get_balance(acct) == 0 and get_code(acct) == "" and get_nonce(acct) == 0`; emptiness of storage does not matter. This simplifies client implementation because there is no need to add extra complexity to make caches enumerable in the correct way and does not significantly affect the intended result, as the cases where balance/code/nonce are empty but storage is nonempty where this change would lead to an extra 25000 gas being paid are pathological and have no real use value.
+### Specification (1c)
+
+Do not implement point 2 above (ie. no new empty accounts can be created, but existing ones are not automatically destroyed unless their state is actually _changed_). Instead, during each block starting from (and including) N and ending when there are no null accounts left, select the 1000 null accounts that are left-most in order of sha3(address), and delete them (ordering by hash is necessary so as to allow the accounts to be easily found by iterating the tree).
+# Rationale
+
+This removes a large number of empty accounts that have been put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol, thereby greatly reducing state size and hence both reducing the hard disk load of a full client and reducing the time for a fast sync. Additionally, it simplifies the protocol in the long term, as once all "empty" objects are cleared out there is no longer any meaningful distinction between an account being empty and being nonexistent, and indeed one can simply view nonexistence as a compact representation of emptiness.
+
+Note that this proposal does introduce a **temporary** breaking of existing guarantees, in that by repeatedly zero-value-calling already existing empty accounts one can create a state change at a cost of 700 gas per account instead of the usual 5000 per gas minimum (with SUICIDE refunds this goes down further to 350 gas per account). Allowing such a large number of state writes per block will lead to heightened block processing times and increase uncle rates in the short term while the existing empty accounts are being cleared, and eventually once all empty accounts are cleared this issue will no longer exist.
+
+# References
+
+1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
+2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161

EIPS/eip-161.md

@@ -0,0 +1,56 @@
+```
+EIP: 161
+Title: State trie clearing (invariant-preserving alternative)
+Author: Gavin Wood
+Type: Standard Track
+Category: Core
+Status: Final
+Created: 2016-10-24
+```
+
+# Specification
+
+a. Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation 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 remain 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 receipt population.
+
+An account _changes state_ when:
+- it is the target or refund of a `SUICIDE` operation for **zero or more** value;
+- it is the source or destination of a `CALL` operation or message-call transaction transferring **zero or more** value;
+- it is the source or newly-creation of a `CREATE` operation or contract-creation transaction endowing **zero or more** value;
+- as the block author ("miner") it is recipient of block-rewards or transaction-fees of **zero or more**.
+
+## Notes
+
+In the present Ethereum protocol, it should be noted that very few state changes can ultimately result in accounts that are empty following the execution of the transaction. In fact there are only four contexts that current implementations need track:
+- an empty account has zero value transferred to it through `CALL`;
+- an empty account has zero value transferred to it through `SUICIDE`;
+- an empty account has zero value transferred to it through a message-call transaction;
+- an empty account has zero value transferred to it through a zero-gas-price fees transfer.
+
+# Rationale
+
+Same as #158 except that several edge cases are avoided since we do not break invariants:
+- ~~that an account can go from having code and storage to not having code or storage mid-way through the execution of a transaction;~~ [corrected]
+- that a newly created account cannot be deleted prior to being deployed.
+
+`CREATE` avoids zero in the nonce to avoid any suggestion of the oddity of `CREATE`d accounts being reaped half-way through their creation.
+
+# References
+
+1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
+2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161