EIPs/EIPS/eip-2029.md

---
eip: 2029
title: State Rent A - State counters contract
author: Alexey Akhunov (@AlexeyAkhunov)
discussions-to: https://ethereum-magicians.org/t/eip-2029-state-counters-contract-change-a-from-state-rent-v3-proposal/3279
status: Draft
type: Standards Track
category: Core
created: 2019-05-15
---

<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
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
<!--A short (~200 word) description of the technical issue being addressed.-->
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
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
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
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
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
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
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](https://eips.ethereum.org/EIPS/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
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
This change is backwards compatible and does not require hard fork to be activated.

## Test Cases
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
Tests cases will be created to ensure that the state counter contract returns its storage items correctly.

## Implementation
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
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
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).