EIP-2681: Limit account nonce to 2^64-1

Discussion topic for https://github.com/ethereum/EIPs/pull/2681


@jpitts: adding some background from the EIP here.

This is motivated by Eth1.x / Stateless Ethereum discussions, more specifically discussion around the “witness format”.

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.

I think the EIP should be officially finalized (not requiring a hardfork)

Do you mean to remove the “if hard fork” and replace it with “these rules apply from the genesis on mainnet” ?

Yup, that’s what I mean. That we’ll just retroactively say “This was always so” and bob’s your uncle.

2 Likes

I’m with @holiman on this, can we just remove the mention of the hardfork and merge this as a retroactive specification? Is it even possible for any nonce to be greater than 2^61 right now? Worst case napkin math scenario, someone was able to increment a nonce for 1 gas, for 10M blocks, at 12.5M gas per block. That would only get you to about 2^46, nowhere near 2^64.

Totally share the same sentiment. The EIP has this in backwards compatibility:

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.

I do not have access to a full client right now, less to an archival one, but it would be nice to check if by some freak accident there was any such account at any point of time. If geth always had that limitation of 64-bit then the answer is no. @holiman?

Could we consider limiting this further to 2^32-1? That would require a change in go-ethereum and possibly other clients, but it is also unreachable in practice (would cost 90.014 Eth with 10 gwei gas price via external transactions). Though I could potentially see some exchange account reaching that if they started in 2015 :wink:

The benefit reducing this limit further could show with transaction formats: it would be possible to serialise the nonce as a fixed-size field, because 4 bytes with zeroes likely would be worth the reduced complexity of having some more complicated encoding scheme (such as RLP).

That is correct. There is no such account

In total, there are somwhere around 600M transactions in the history of ethereum. 2^32-1 means that there’s a max nonce of 4300M. Meaning that if one single account made all transactions from genesis to somewhere around block 50M, then it could potentially reach it.

However, changing it to to a fixed-size field is a massive change, since it affects the rlp-encoding of every account in the trie, aswel as the rlp-encoding of all transactions. Unless I misunderstand what you mean…?

This EIP does not propose to change the merklization rule (“RLP encoding of the accounts in trie”) or the transactions encoding. However future EIPs proposing changes in those could benefit from the limit to 2^32-1.

Yeah ok… I think 2^32-1 is within the theoretically reachable segments, whereas limiting to full 64-bit is on the like “millions of years” - unreachable segment. So the original suggestion makes definite sense, the latter suggestions seems to me to be not as clear-cut.

I weakly support 64-bit if we don’t really care about the size.

If we do care about the size, then I weakly support 32-bit as I don’t think we are realistically going to run out anytime soon and we can change the size later if it ever becomes a real problem.