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).

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.