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.

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

Update EIP-7702: remove chain_id in authorization tuple #9152

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
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: 12 additions & 13 deletions EIPS/eip-7702.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,18 +41,15 @@ We introduce a new [EIP-2718](./eip-2718.md) transaction, "set code transaction"
```
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
authorization_list = [[unchained, address, nonce, y_parity, r, s], ...]
```

The fields `chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `destination`, `value`, `data`, and `access_list` of the outer transaction follow the same semantics as [EIP-4844](./eip-4844.md). *Note, this means a null destination is not valid.*
The transaction fields `chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `destination`, `value`, `data`, and `access_list` follow the same semantics as [EIP-4844](./eip-4844.md). *Note, this means a null destination is not valid.*

The `authorization_list` is a list of tuples that store the address to code which the signer desires to execute in the context of their EOA. The transaction is considered invalid if the length of `authorization_list` is zero.

The transaction is also considered invalid when any field in an authorization
tuple cannot fit within the following bounds:
`authorization_list` is a list of tuples that store the address to code which the signer desires to execute in the context of their EOA. The transaction is considered invalid if the length of `authorization_list` is zero. It is also considered invalid when any field in an authorization tuple exceeds the following bounds:

```python
assert auth.chain_id < 2**64
assert auth.unchained == 0 || auth.unchained == 1
Copy link
Member

Choose a reason for hiding this comment

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

This specific check looks like the yParity check (where yParity is also either 0 or 1).

Suggested change
assert auth.unchained == 0 || auth.unchained == 1
assert auth.unchained < 2**8

There should be an added check for each tuple to validate if the auth.unchained is 0 or 1 (if not, skip the tuple).

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I think this line should be reverted. This section has to do with decoding txs and I think 1 byte is the highest resolution we want here. I think many languages represent boolean as 1 byte value despite it only needing 1 bit of information.

We would verify unchained is 0 or 1 in the tuple validation.

assert auth.nonce < 2**64
assert len(auth.address) == 20
assert auth.y_parity < 2**8
Expand All @@ -66,17 +63,19 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta

At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, y_parity, r, s]` tuple do the following:

1. Verify the chain id is either 0 or the chain's current ID.
1. Establish signed-over chain ID of the authorization.
* 1a. If `unchained` is zero, set `auth_chain_id` to the transaction `chain_id` (which must equal the executing chain's ID).
* 1b. If `unchained` is one, set `auth_chain_id` to zero.
2. Verify the `nonce` is less than `2**64 - 1`.
3. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]`
* `s` value must be less than or equal to `secp256k1n/2`, as specified in [EIP-2](./eip-2.md).
3. `authority = ecrecover(keccak(MAGIC || rlp([auth_chain_id, address, nonce])), y_parity, r, s]`
* 3a. The `s` value must be less than or equal to `secp256k1n/2`, as specified in [EIP-2](./eip-2.md).
4. Add `authority` to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
5. Verify the code of `authority` is either empty or already delegated.
5. Verify the code of the `authority` account is either empty or already delegated.
6. Verify the nonce of `authority` is equal to `nonce`. In case `authority` does not exist in the trie, verify that `nonce` is equal to `0`.
7. Add `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` gas to the global refund counter if `authority` exists in the trie.
8. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
* As a special case, if `address` is `0x0000000000000000000000000000000000000000` do not write the designation. Clear the account's code and reset the account's code hash to the empty hash `0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`.
9. Increase the nonce of `authority` by one.
* 8a. As a special case, if `address` is `0x0000000000000000000000000000000000000000` do not write the designation. Clear the account's code and reset the account's code hash to the empty hash `0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`.
9. Increase the nonce of the `authority` account by one.

If any of the above steps fail, immediately stop processing that tuple and continue to the next tuple in the list. It will in the case of multiple tuples for the same authority, set the code using the address in the last valid occurrence.

Expand Down
Loading