Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

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

wants to merge 1 commit into from

Conversation

axic
Copy link
Member

@axic axic commented Nov 26, 2021 •
edited

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.

axic
axic commented Nov 26, 2021
View reviewed changes
Paper.tex
@@ -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}}$.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@acoglio
Copy link
Member

acoglio commented Nov 28, 2021

Equations (13) and (17) say that the nonce is a 256-bit word. Should they be changed too?

@axic
Copy link
Member Author

axic commented Nov 30, 2021 •
edited

Good point @acoglio.

I think (13) is worth changing as that already mentions "types" (such as B_32 vs N_256) and doesn't deal with RLP.

However not sure about (17). That seems to deal with RLP encoded data and is less strict about types. It is also missing T_t which should be N_160. Never mind, it is described in (19). In this case I'll update both (13) and (17).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Implement EIP-2681: Limit account nonce to 2^64-1
2 participants
@axic @acoglio