AlertSourceDiscuss
Ethereum Improvement Proposals

Appearance

EIP-2029: State Rent A - State counters contract

🚧 StagnantCore

Stagnant

This EIP has had no recent activity for at least 6 months, and has automatically been marked as stagnant. This EIP should not be used in production.

If you are interested in helping move this EIP to final, create a PR to move this EIP back to Draft and add yourself as an author, and an EIP editor will help guide you through the process. Thank you!

AuthorsAlexey Akhunov (@AlexeyAkhunov)
Created2019-05-15

Simple Summary ​

A smart contract is deployed on all Ethereum networks, at a pre-determined address, with the code that simply reads the slot in its storage specified by the only parameter. Later, this contract becomes "special" in that Ethereum start writing state counters (number of total transactions, number of accounts, etc.) into that contract.

Abstract ​

This is part of the State Rent roadmap. This particular change introduces a place in the Ethereum state where various state counters can be stored. At this point, the most important counter is the total number of transactions happened, and this counter will be used to populate the nonces of newly created non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them.

Motivation ​

Ethereum currently does not have a special place in the state for tracking state counters such as number of transactions or number of accounts.

Specification ​

Prior to the block A, a contract is deployed with the following code: 0x60 0x20 0x60 0x00 0x80 0x80 0x35 0x54 0x90 0x52 0xF3, which corresponds to this assembly: PUSH1 32 PUSH1 0 DUP1 DUP1 CALLDATALOAD SLOAD SWAP1 MSTORE RETURN Call to this contract accepts one 32-byte argument, x, and returns the value of the storage item [x].

This contract is deployed using CREATE2 opcode in such a way that it has the same address on any network.

Rationale ​

Two alternative solutions were considered so far:

  1. Extending the structure of the Ethereum state to introduce more fields, and hence change the way the state root is constructed. The main downside of this approach is the impact on the software what is currently coupled with the particular way the state root is constructed. Particularly it affects the software that deals with merkle proofs derived from the state root.
  2. Extended State Oracle (EIP-2014). Under such proposal, there will be a precompile contract with standardised interface, capable of returning current values of the counters. However, the actual data being returned by such oracle is not explicitly in the state, and is not Merkelised. It means that all the counters need to be added to the snapshots when the snapshot sync is perform, so they still present in the state, but implicitly.

Backwards Compatibility ​

This change is backwards compatible and does not require hard fork to be activated.

Test Cases ​

Tests cases will be created to ensure that the state counter contract returns its storage items correctly.

Implementation ​

Implementation is envisaged as a transaction that can be posted from any Ethereum address and will cause the deployment of the state counter contract.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Alexey Akhunov, "EIP-2029: State Rent A - State counters contract[DRAFT]," Ethereum Improvement Proposals, no. 2029, 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2029.