Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
State clearing #158
For all blocks where
The cases where a "touch" takes place can be enumerated as follows:
When the EVM checks for emptiness (for the purpose of possibly applying the 25000 gas cost), emptiness is defined by
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).
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.
This is hard to read. Did you mean:
In all cases where an operation would create a new empty account out of a previously nonexistent one, the account shall remain nonexistent.
EDIT: nope, see next comment.
How is "zero-value suicide" defined? Is it: execution of a
No, it should be read exactly as written; becoming nonexistent, not remaining. That is, in all situations where an operation would formerly turn a nonexistent account into an empty account, the operation would keep the account nonexistent, and in fact if there's an empty account in that position it would turn it into a nonexistent one. The condition for instantiation becomes a condition for deletion.
If a call with a value were to hit one of these empty but not deleted accounts would that permanently preserve an empty account?
Since it would require an action to remove these empty accounts it would require calling them with zero value and due to the low cost as you mentioned I assume the block gas limit would have to decrease to prevent huge block processing delays?
Does that mean if you were to zero value call twice on the same empty account it would delete it and then try to create it again realize it is empty and delete it again? So repetitively calling this account would require a lot of processing at the cost of a single call?
Yes, it would require such an action - zero-value calling them. But this is only a 14x difference from the cost of processing normal execution so it shouldn't break the chain while it's happening, though uncle rates would substantially go up in the meantime.
What about if there is an EVM exception such as running out of gas these state changes will be reverted back to the empty account which would require the state to be changed and reverted on each call and would allow the same empty accounts to be zero value called repetitively?
Unless the empty accounts are deleted even in the case of an EVM exception, if that is the case would that not break the guarantee that EVM exceptions revert the state back as if the transaction was never made?