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

Add a workaround for creation transaction and legacy nonce rules contradiction #28

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

Add a workaround for creation transaction and legacy nonce rules contradiction #28

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 22 additions & 3 deletions RIPS/rip-7712.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,14 +52,20 @@ This `nonce` is exposed to the EVM in a `NonceManager` pre-deployed contract loc

The `nonce` is [validated and incremented](#nonce-validation-frame) on-chain before the rest of the validation code.

### The old `nonce` account parameter use
### The legacy `nonce` account parameter use

The old 64-bit `nonce` account parameter is used when the `key` of the `AA_TX_TYPE` transaction's `nonce` is set to 0.
The legacy 64-bit `nonce` account parameter is used when the `key` parameter of the `AA_TX_TYPE` transaction's `nonce`
is set to 0.
Notice that this also prevents the previously signed transactions from becoming valid again.

The old `nonce` account parameter remains in use for transactions initiated by EOAs and for the `CREATE` opcode.
The legacy `nonce` account parameter remains in use for transactions initiated by EOAs and for the `CREATE` opcode.
It is not incremented when `sender` makes the `AA_TX_TYPE` transaction.

### Account deployment transaction does not increment the legacy `nonce`

The first `AA_TX_TYPE` transaction that contains a `deployer` and `deployerData` fields to create the `sender` account
does not increment the `sender`'s legacy `nonce` account parameter even in case the `key` parameter is set to 0.

#### Nonce validation frame

Before the first validation frame is applied during the validation phase,
Expand Down Expand Up @@ -119,6 +125,19 @@ TODO.
While there is no technical benefit to either option, allowing EVM code to control the nonce
seems to be a smaller change to the Ethereum protocol and is more aligned with the vision of Account Abstraction.

### Account deployment transaction does not increment the legacy `nonce`

The [EIP-684](https://eips.ethereum.org/EIPS/eip-684) explicitly prevents deployment of contracts for accounts with
non-zero nonce value. This rule collides with the normal flow of incrementing the `sender` nonce before execution
of a transaction starts.
However, [EIP-161](https://eips.ethereum.org/EIPS/eip-161) guarantees that the `nonce` of a newly created account
is set to `1` on creation.

This guarantees that the `sender` deployment transaction can pass the EIP-684 rule check and still increment the nonce.

Note that revert in the creation frame makes the `AA_TX_TYPE` transaction invalid and `sender`'s nonce
cannot be incremented without successfully deploying its code.

## Backwards Compatibility

As actual `nonce` value was never observable inside the EVM, there should be no major complications caused by the
Expand Down