EIP-2681 Capping the account nonce at 2^64-1 (Limit account nonce to 2^64-1)
Final · EVM & execution · EIP status Final · created 2020-04-25
Restricts the values an account nonce can take to between 0 and 2^64-1. Once a nonce reaches the limit, transactions become invalid, and the CREATE and CREATE2 opcodes return 0 and halt.
Why it is needed
Ethereum accounts carry a transaction counter called a nonce. Under the current specification this number has no defined length, so in theory it can grow without bound. But a number with no fixed length is awkward to handle. It is hard to represent optimally in a state witness, the data that proves an account's state is correct, and client software must keep the nonce as a generously sized 256-bit number. This EIP sets the nonce's upper bound at 2^64-1. That lets proof data represent the nonce more efficiently, and gives clients a small optimization: storing the nonce as 64 bits. The original text notes this could also help at least three other proposals aimed at improving transaction formats.
What changes
Today
- The nonce is an integer with no length limit, so by specification it can grow without bound
- State witnesses must be able to hold an arbitrary-length nonce, which makes optimization difficult
- Per spec, clients must handle the nonce as a 256-bit number
After EIP-2681
- The nonce is restricted to between 0 and 2^64-1, applied retroactively from genesis
- State witnesses can represent the nonce in a more optimized form
- Clients can store the nonce as a 64-bit number
Who is affected
- Users: No practically noticeable change. As of the original writing (November 2020), the highest account nonce was about 29 million, far below the limit.
- Client teams: Many implementations, such as go-ethereum, already treated the nonce as 64 bits, so the specification now matches actual implementations.
- Contract and app developers: A new rule is added: for an account whose nonce has reached the limit, CREATE and CREATE2 halt by pushing 0 onto the stack.
In depth
Transaction validity rule: invalid if the nonce is 2^64-1 or greater
This EIP introduces two restrictions applied retroactively from the genesis block. The first is a transaction validity rule: a transaction whose nonce equals or exceeds 2^64-1 is considered invalid. The original text also explains why the upper bound value 2^64-1 itself is invalid: if such a transaction were included in a block, the sending account's nonce would exceed 2^64-1. So the values an account nonce can actually take run from 0 to 2^64-1, and once an account's nonce reaches that limit, it can no longer send transactions.
CREATE and CREATE2 halt by returning 0
The second restriction affects the EVM's contract-creation opcodes. If the CREATE or CREATE2 opcode executes while an account's nonce is 2^64-1, execution halts and pushes the result value 0 onto the stack. In this case, the gas for executing the initcode, the initialization code run when creating a new contract, is not deducted. In other words, for an account that has hit the limit, contract creation does not proceed, and the caller can tell from the 0 pushed onto the stack that no contract was created.
Cost of reaching the limit
The original text considers it unlikely that any account's nonce would reach or exceed the proposed limit. Reaching that limit through external transactions would require at least 21000 * (2^64-1) = 387,381,625,547,900,583,915,000 gas. Since each transaction costs at least 21000 gas and increments the nonce by 1, this is the cost of repeating that 2^64-1 times. The original text also notes that most clients already treat the nonce field as 64 bits, citing go-ethereum as an example.
The Morden testnet and EIP-155
The old Morden testnet used to set a new account's starting nonce to 2^20 to distinguish mainnet transactions from testnet transactions, using the nonce to prevent the same transaction from being replayed and reprocessed across both networks. The original text notes that this approach is no longer used now that EIP-155 introduced a more elegant method using a chain identifier. This points out that the practice of overloading the nonce with meaning beyond a simple transaction counter has disappeared.
Backward compatibility and current status
The original text explains that while this is technically a retroactive breaking change to the specification, it should have no observable effect in practice. As of November 2020, no account in the state has a nonce exceeding the limit, and the highest nonce, held by account 0xea674fdde714fd979de3edf0f56aa9716b898ec8, is only about 29 million. go-ethereum already partially enforces this restriction, keeping state.Account.Nonce and types.txdata.AccountNonce as 64-bit numbers. The original text states there are no security considerations, and this EIP's status is Final, meaning the specification is settled.