Implement EIP-2681: Limit account nonce to 2^64-1 #827
Conversation
| @@ -306,7 +306,7 @@ \subsection{The Transaction} \label{subsec:transaction} | |||
| A transaction (formally, $T$) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. The sender of a transaction can not be a contract. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination\footnote{Notably, such `tools' could ultimately become so causally removed from their human-based initiation---or humans may become so causally-neutral---that there could be a point at which they rightly be considered autonomous agents. \eg contracts may offer bounties to humans for being sent transactions to initiate their execution.}. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). Both types specify a number of common fields: | |||
|
|
|||
| \begin{description} | |||
| \item[nonce]\linkdest{tx_nonce}{} A scalar value equal to the number of transactions sent by the sender; formally $T_{\mathrm{n}}$. | |||
| \item[nonce]\linkdest{tx_nonce}{} A 64-bit scalar value equal to the number of transactions sent by the sender; formally $T_{\mathrm{n}}$. | |||
There was a problem hiding this comment.
Perhaps the "64-bit" mention here is not entirely correct, as it is serialised via RLP, so it has no fixed size. However since the recipient field below states "160-bit address" I decided to include it.
Potentially the more clear way is to include these restrictions in the validation sections, which means the address should be just a scalar here, and a new rule would need to be added.
|
Equations (13) and (17) say that the nonce is a 256-bit word. Should they be changed too? |
|
Good point @acoglio. I think (13) is worth changing as that already mentions "types" (such as However not sure about (17). |
Fixes #813. Please note that this applies from genesis, and geth implements it now.
I tried to implement this and I think I found the correct place for the external transaction validation. However I have no good idea where to describe the rules for
CREATE/CREATE2.