forked from DecentralizedClimateFoundation/DCIPs
52 lines
3.2 KiB
Markdown
52 lines
3.2 KiB
Markdown
|
---
|
||
|
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).
|
||
|
|