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

Update EIP-7702: Add tx_origin field to authority #8763

Closed
wants to merge 2 commits into from
+12 −7
Closed

Update EIP-7702: Add tx_origin field to authority #8763

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f61f939
EIP-7702: Add `tx_origin` field to authority
jochem-brouwer Jul 26, 2024
034c458
Update EIPS/eip-7702.md
jochem-brouwer Jul 26, 2024
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
19 changes: 12 additions & 7 deletions EIPS/eip-7702.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ 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 = [[chain_id, address, nonce, tx_origin, 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-1559](./eip-1559.md).
Expand All @@ -51,15 +51,16 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta

#### Behavior

At the start of executing the transaction, for each `[chain_id, address, nonce, y_parity, r, s]` tuple:
At the start of executing the transaction, for each `[chain_id, address, nonce, tx_origin, y_parity, r, s]` tuple:

1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]`
2. Verify the chain id is either 0 or the chain's current ID.
3. Verify that the code of `authority` is either empty or already delegated.
4. Verify the nonce of `authority` is equal to `nonce`.
5. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
6. Increase the nonce of `authority` by one.
7. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
3. Verify that `tx_origin` is either `null` (empty bytes) or that `tx_origin` (20 bytes) is the address this transaction originates from.
4. Verify that the code of `authority` is either empty or already delegated.
5. Verify the nonce of `authority` is equal to `nonce`.
6. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
7. Increase the nonce of `authority` by one.
8. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)

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 specified by the address in the last occurrence.

Expand Down Expand Up @@ -121,6 +122,10 @@ An alternative to adding chain ID could be to sign over the code the address poi

Unlike previous versions of this EIP and EIPs similar, the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.

### Explicit `tx.origin` signing

A signer might desire that only a specific EOA account sends the EIP-7702 transaction. If this is the case, the signer should set the `tx_origin` field of the authority list to that address. If any EOA account is allowed to send the authority transaction, the `tx_origin` field should be set to `null` (empty bytes). Note that without `tx.origin`, once a EIP-7702 transaction enters the transaction pool, this delegation authority is now immediately available to all accounts, and could thus lead to undesired or unwanted results such as being frontrun by MEV.
Copy link
Member

Choose a reason for hiding this comment

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

This either requires a trusted party to relay or self-relay. I don't support protocol features that are only useful if you trust a third party. If you need to self-relay, just gate initialization of your contract with ORIGIN.

Copy link
Contributor

Choose a reason for hiding this comment

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

if i understand your comment correctly, this is not a security feature for the wallet provider (their gated contract), but for the user doing the delegation.

The basic security principal is keep the attack surface minimal, and this is what this does. it only allows trusted wallet provider/party to use the authorization to prevent timing/reuse attacks (of a tx that couldn't make to block but is in mempool or failed)

This anyway doesn't hinder someone to sign a public authorization by allowing origin to be null.


### Self-sponsoring: allowing `tx.origin` to set code

Allowing `tx.origin` to set code enables simple transaction batching, where the sender of the outer transaction would be the signing account. The ERC-20 approve-then-transfer pattern, which currently requires two separate transactions, could be completed in a single transaction with this proposal.
Expand Down
Loading