52 lines
3.1 KiB
Markdown
52 lines
3.1 KiB
Markdown
|
---
|
||
|
|
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: Stagnant
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2019-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](./eip-2014.md)). 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
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|