EIPs/EIPS/eip-2681.md
Pandapip1 9e393a79d9
Force usage of included LICENSE file (#5055)
* Include LICENCE in the Jekyll build

* Replace old licence link with new and improved licence link

* Add note to EIP-1 mandating the new link

* Maybe this fixes it?

* Rename LICENCE so that jekyll picks it up

* Add original LICENCE file back

* Delete the markdown file

* Add Jekyll header

Hopefully the tooling still detects it as CC0

* Remove Jekyll header

* Maybe this will trick Jekyll and satisfy github?

* Remove config changes

* Enable incremental build

* Will it work if I rename it?

* I'll just paste the content of the licence into the file...

* Perhaps this will work

* Replace the licence file

* Fix false positive

Co-authored-by: Micah Zoltu <micah@zoltu.net>

* Resolve feedback

* Perhaps this might work

* It didn't work

This reverts commit 55116e15168fb20ae57dea97388bb260c0941465.

* Will licencee still detect this correctly?

* Jekyll Preamble in licence file

* Include it?

* Licence -> License, get rid of CC0.md

* Force wording of copyright waiver

* Formatting consistent with the rest of the list

* Spelling

* Escape

* Task failed successfully

* Fix two more links

* Will this render it?

* Perhaps this will work too

* .md essential

* Fix the issues Micah noted

Co-authored-by: Micah Zoltu <micah@zoltu.net>
2022-05-06 00:29:09 -07:00

2.5 KiB

eip title author discussions-to status type category created
2681 Limit account nonce to 2^64-1 Alex Beregszaszi (@axic) https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324 Final Standards Track Core 2020-04-25

Abstract

Limit account nonce to be between 0 and 2^64-1.

Motivation

Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized 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

Introduce two new restrictions retroactively from genesis:

  1. Consider any transaction invalid, where the nonce exceeds or equals to 2^64-1.
  2. The CREATE and CREATE2 instructions' execution ends with the result 0 pushed on stack, where the account nonce is 2^64-1. Gas for initcode execution is not deducted in this case.

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 introduced a more elegant way using chain identifiers.

  3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum.

  4. The reason a transaction with nonce 2^64-1 is invalid, because otherwise after inclusion the sender account's nonce would exceed 2^64-1.

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. As of November 2020, the account 0xea674fdde714fd979de3edf0f56aa9716b898ec8 is responsible for the highest account nonce at approximately 29 million.

  2. go-ethereum already has this restriction partially in place (state.Account.Nonce and types.txdata.AccountNonce it as a 64-bit number).

Security Considerations

None.

Copyright and related rights waived via CC0.