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: Add decoding limits for AuthList items #8746

Merged
merged 11 commits into from
Aug 8, 2024
11 changes: 10 additions & 1 deletion EIPS/eip-7702.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ status: Review
type: Standards Track
category: Core
created: 2024-05-07
requires: 2718, 2929, 2930, 3541, 3607
Copy link

Choose a reason for hiding this comment

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

Trying to access on my funds

requires: 2, 2718, 2929, 2930, 3541, 3607
---

## Abstract
Expand Down Expand Up @@ -44,6 +44,15 @@ rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, dest
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
```

Transaction is considered invalid if authorization list items can't be decoded as:
Copy link
Member

Choose a reason for hiding this comment

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

Invalid, as in should be rejected by txpool? (If yes I think this should be clarified - and I also think this should be the case 😄 )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's invalid as it can't be added to the block. And if invalid tx is found in the block, the block is considered invalid.

Valid/Invalid should be the correct term used to spec out this.

It is assumed that txpool rejects invalid transactions.

Copy link
Member

Choose a reason for hiding this comment

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

Alright, yes sorry about this, I sometimes get confused about what terminology maps to what, since "invalid" could also be interpreted as the tx itself is valid but will be reverted immediately. (It would be great at some point to have a glossary EIP of the terminology we use to avoid confusion :) )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(It would be great at some point to have a glossary EIP of the terminology we use to avoid confusion :) )

true, this would be helpful


* `chain_id`: unsigned 256-bit integer.
* `nonce`: unsigned 64-bit integer.
* `address`: 20 bytes array.
* `y_parity`: Value 0 or 1.
* `r`: unsigned 256-bit integer.
* `s`: unsigned 256-bit integer and value less or equal than `secp256k1n/2`, specified in [EIP-2](./eip-2.md).

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 `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.
Expand Down
Loading