mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-24 12:48:20 +00:00
15f61ed0fd
I have gone through and updated all existing EIPs to match this rule, including EIP-1. In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline. Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors. In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist. In these cases I tried to excise the reference from the EIP as best I could. It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).
64 lines
2.3 KiB
Markdown
64 lines
2.3 KiB
Markdown
---
|
|
eip: 2681
|
|
title: Limit account nonce to 2^64-1
|
|
author: Alex Beregszaszi (@axic)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324
|
|
status: Draft
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2020-04-25
|
|
---
|
|
|
|
## Abstract
|
|
|
|
Limit account nonce to be between `0` and `2^64-1`.
|
|
|
|
## Motivation
|
|
|
|
This is motivated by Eth1.x / Stateless Ethereum discussions, more specifically discussion around the ["witness format"](https://github.com/ethereum/stateless-ethereum-specs).
|
|
Introducing a restriction would allow storing the nonce in a more optimised way.
|
|
|
|
Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals.
|
|
|
|
Lastly this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number.
|
|
|
|
## Specification
|
|
|
|
If `block.number >= FORK_BLOCK` introduce two new restrictions:
|
|
|
|
1. Consider any transaction invalid, where the nonce exceeds `2^64-1`.
|
|
2. The `CREATE` instruction to abort with an exceptional halt, where the account nonce is `2^64-1`.
|
|
|
|
## Rationale
|
|
|
|
1. It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least `21000 * (2^64-1) = 387_381_625_547_900_583_915_000` gas.
|
|
|
|
2. It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of `2^20` in order to differentiate transactions from mainnet transactions.
|
|
This mode of replay protection is out of fashion since [EIP-155](./eip-155.md) introduced a more elegant way using chain identifiers.
|
|
|
|
3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum.
|
|
|
|
## Backwards Compatibility
|
|
|
|
While this is a breaking change, no actual effect should be visible:
|
|
|
|
1. There is no account in the state currently which would have a nonce exceeding that value. **Need to double check, but would be very surprised.**
|
|
|
|
2. go-ethereum already has this restriction in place (`state.Account.Nonce` and `types.txdata.AccountNonce` it as a 64-bit number).
|
|
|
|
## Security Considerations
|
|
|
|
TBA
|
|
|
|
## Test Cases
|
|
|
|
TBA
|
|
|
|
## Implementation
|
|
|
|
TBA
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|