DCIPs/EIPS/eip-2031.md

52 lines
3.2 KiB
Markdown
Raw Normal View History

---
eip: 2031
title: State Rent B - Net transaction counter
author: Alexey Akhunov (@AlexeyAkhunov)
discussions-to: https://ethereum-magicians.org/t/eip-2031-net-transaction-counter-change-b-from-state-rent-v3-proposal/3283
status: Stagnant
type: Standards Track
category: Core
created: 2019-05-15
requires: 2029
---
## Simple Summary
Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore
it is called *Net* transaction count).
It is done by incrementing a storage slot in the special contract, called *State counter contract* ([EIP-2029](./eip-2029.md)).
## Abstract
It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot
in the *State counter contract*. 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 number of transactions.
## Specification
A new field, with the location 0 (that means it resides in the storage slot 0 in the state counter contract, and can
be read by calling that contract with argument being 32 zero bytes), is added to the state counter contract. It will eventually contain `txCount`, the total number of transactions processed up until that point.
On an after block B, or after the deployment of the state counter contract (which comes first), the field `txCount` is incremented after each transaction. Updating `txCount` means updating the storage of state counter contract at the location 0. These changes are never reverted.
## Rationale
Two main alternatives were proposed for the replay protection of the accounts that were evicted by subsequently brought back by sending ether to them:
1. Temporal replay protection. The nonce of the new accounts (and those brought back) is still zero, but a new `valid-until` field is introduced, making
transactions invalid for inclusion after the time specified in this field. This, however, has unwanted side effected related to the fact that account
nonces are not only used for replay protection, but also for computing the addresses of the deployed contracts (except those created by `CREATE2`).
2. Setting nonce of new accounts (and those brought back) to something depending on the current block number. This approach requires coming up with
an arbitrary parameter, which is the maximum number of transaction in the block, so that the new nonces never clash with the existing nonces.
This is mostly a concern for private networks at the moment, because they will potentially have significantly more transactions in a block.
## Backwards Compatibility
This change is not backwards compatible and requires hard fork to be activated.
## Test Cases
Tests cases will be generated out of a reference implementation.
## Implementation
There will be proof of concept implementation to refine and clarify the specification.
## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).