From 87eefe1fd17900e306040197e55965a8731b533e Mon Sep 17 00:00:00 2001 From: lightclient Date: Wed, 19 Jun 2024 14:31:07 -0600 Subject: [PATCH 1/7] 7702: add delegation designation --- EIPS/eip-7702.md | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 764380d2b660b0..8c29a361980989 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -8,12 +8,12 @@ status: Review type: Standards Track category: Core created: 2024-05-07 -requires: 2718, 2929, 2930 +requires: 2718, 2929, 2930, 3541, 3607 --- ## Abstract -Add a new transaction type that adds a list of `[address, y_parity, r, s]` authorization tuples, and converts the signing accounts (not necessarily the same as the `tx.origin`) into smart contract wallets for the duration of that transaction. +Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and converts the signing accounts (not necessarily the same as the `tx.origin`) into smart contract wallets for the duration of that transaction. ## Motivation @@ -40,38 +40,47 @@ 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, 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). -The `authorization_list` is a list of tuples that store the address to code which the signer desires to set in their EOA temporarily. The third element is a list item mimicking an optional value. When the list length is zero, consider the authorization nonce to be null. When the list length is one, consider the single integer value to be the provided nonce authorization. Other lengths and value types in this optional are invalid and the transaction as a whole should be considered malformed. +The `authorization_list` is a list of tuples that store the address to code which the signer desires to point to from their EOA. The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. #### 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, y_parity, r, s]` tuple: -1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, [nonce]])), y_parity, r, s]` +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 empty. -4. If nonce list item is length one, verify the nonce of `authority` is equal to `nonce`. -5. Set the code of `authority` to code associated with `address`. -6. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).) +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 `0xef01 || 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).) 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 first occurrence. -At the end of the transaction, set the code of each `authority` back to empty. - Note that the signer of an authorization tuple may be different than `tx.origin` of the transaction. +##### Delegation Designation + +The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541) to designate the code has a special purpose. This designator requires all code retrieving operations follow the address pointer to fill the accounts observable code. The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`. + +For example, `EXTCODESIZE` would return the size of the code pointed to by `address` instead of `24` which would represent the delegation designation. `CALL` would similarly load the code from `address` and execute it in the context of `authority`. + #### Gas Costs The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. Additionally, we add a cost of `PER_CONTRACT_CODE_BASE_COST * authorization list length`. The transaction sender will pay for all authorization tuples, regardless of validity or duplication. +#### Transaction Origination + +Modify the restriction put in place by [EIP-3607](./eip-3607.md) to allow EOAs whose code is a valid delegation designation, i.e. `0xef01 || address`, to continue to originate transactions. Accounts with any other code values may not originate transactions. + ## Rationale ### No initcode @@ -108,9 +117,7 @@ An alternative to adding chain ID could be to sign over the code the address poi #### In-protocol revocation -A hotly debated element of this EIP is the need for in-protocol revocation. Although it is possible to implement revocation logic within delegated code, for some this isn't sufficient and it is the duty of the protocol to provide a revocation option of last resort. - -For this reason, the proposal provides two separate schemes. The first is an eternal delegation to a smart contract. At the protocol level, it is not possible to revoke. However, the contract you delegate to is one which can expect to use in your account for perpetuity; similar to how smart contract wallet users deploy proxy contracts to their account and point the target at a wallet implementation. The second is a scoped delegation with a revocation mechanism based on the EOA's nonce. This is a safer to begin using smart contract code in the context of your EOA without potentially committing to a specific piece of code forever. +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. ### Self-sponsoring: allowing `tx.origin` to set code From 7ec0e0e34b4cfe797d4aab4437487285cec7c7b8 Mon Sep 17 00:00:00 2001 From: lightclient Date: Thu, 20 Jun 2024 07:28:18 -0600 Subject: [PATCH 2/7] 7702: address pr feedback --- EIPS/eip-7702.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 8c29a361980989..ac4ecc5a316cc5 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -13,7 +13,7 @@ requires: 2718, 2929, 2930, 3541, 3607 ## Abstract -Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and converts the signing accounts (not necessarily the same as the `tx.origin`) into smart contract wallets for the duration of that transaction. +Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and deploy a delegation designator to the signing accounts so calls into the accounts execute the code at associated `address`. ## Motivation @@ -57,7 +57,7 @@ At the start of executing the transaction, for each `[chain_id, address, nonce, 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 `0xef01 || address`. This is a delegation designation. +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).) @@ -79,7 +79,7 @@ The transaction sender will pay for all authorization tuples, regardless of vali #### Transaction Origination -Modify the restriction put in place by [EIP-3607](./eip-3607.md) to allow EOAs whose code is a valid delegation designation, i.e. `0xef01 || address`, to continue to originate transactions. Accounts with any other code values may not originate transactions. +Modify the restriction put in place by [EIP-3607](./eip-3607.md) to allow EOAs whose code is a valid delegation designation, i.e. `0xef0100 || address`, to continue to originate transactions. Accounts with any other code values may not originate transactions. ## Rationale From f141b99de07cc1dd83aae99c9203c39f1b380332 Mon Sep 17 00:00:00 2001 From: lightclient Date: Sat, 22 Jun 2024 07:48:10 -0600 Subject: [PATCH 3/7] 7702: don't allow designator loops --- EIPS/eip-7702.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index ac4ecc5a316cc5..e7c3d693f3d50c 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -71,6 +71,8 @@ The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3 For example, `EXTCODESIZE` would return the size of the code pointed to by `address` instead of `24` which would represent the delegation designation. `CALL` would similarly load the code from `address` and execute it in the context of `authority`. +In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain. + #### Gas Costs The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. Additionally, we add a cost of `PER_CONTRACT_CODE_BASE_COST * authorization list length`. From 7cd84a11d6f108fe6c80e730ea82a40b191ddfc5 Mon Sep 17 00:00:00 2001 From: lightclient Date: Wed, 3 Jul 2024 15:37:46 -0600 Subject: [PATCH 4/7] 7702: fixup some prose --- EIPS/eip-7702.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index e7c3d693f3d50c..569a9de8de1ed4 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -1,7 +1,7 @@ --- eip: 7702 -title: Set EOA account code for one transaction -description: Add a new tx type that sets the code for an EOA during one transaction execution +title: Set EOA account code +description: Add a new tx type that sets the code for an EOA during execution author: Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923 status: Review @@ -13,7 +13,7 @@ requires: 2718, 2929, 2930, 3541, 3607 ## Abstract -Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and deploy a delegation designator to the signing accounts so calls into the accounts execute the code at associated `address`. +Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0000 ++ address)` to the signing account's code. All code reading operations must load the pointed to by the designator. ## Motivation @@ -45,7 +45,7 @@ authorization_list = [[chain_id, 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-1559](./eip-1559.md). -The `authorization_list` is a list of tuples that store the address to code which the signer desires to point to from their EOA. +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 [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. @@ -155,7 +155,7 @@ Specifically: * The "code pathways" that are used are code pathways that would, in many cases (though perhaps not all), continue to "make sense" in a pure-smart-contract-wallet world. * Hence, it avoids the problem of "creating two separate code ecosystems", because to a large extent they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset. * It does not require adding any opcodes, that would become dangling and useless in a post-EOA world. -* It allows EOAs to temporarily convert themselves into contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`. +* It allows EOAs to masquerade as contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`. * Once this is implemented, allowing EOAs to migrate permanently is "only one line of code": just add a flag to not set the code back to empty at the end. ## Backwards Compatibility From 5080bc279c02a85733166c86f0d63920c2406b33 Mon Sep 17 00:00:00 2001 From: lightclient Date: Fri, 5 Jul 2024 09:04:04 -0600 Subject: [PATCH 5/7] 7702: typo --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 569a9de8de1ed4..954ade31557f04 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -13,7 +13,7 @@ requires: 2718, 2929, 2930, 3541, 3607 ## Abstract -Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0000 ++ address)` to the signing account's code. All code reading operations must load the pointed to by the designator. +Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0000 ++ address)` to the signing account's code. All code reading operations must load the code pointed to by the designator. ## Motivation From fa64e0bed144a7775cf6a33564be205e10773885 Mon Sep 17 00:00:00 2001 From: lightclient Date: Fri, 5 Jul 2024 10:55:59 -0600 Subject: [PATCH 6/7] 7702: use last auth pointer instead of first --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 954ade31557f04..18b4ac27f1a57b 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -61,7 +61,7 @@ At the start of executing the transaction, for each `[chain_id, address, nonce, 6. Increase the nonce of `authority` by one. 7. 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 first occurrence. +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. Note that the signer of an authorization tuple may be different than `tx.origin` of the transaction. From e649f2be4e9e543f2070c83f7d6c65e04449eff2 Mon Sep 17 00:00:00 2001 From: lightclient Date: Mon, 8 Jul 2024 10:28:51 -0600 Subject: [PATCH 7/7] 7702: ref correct cost param --- EIPS/eip-7702.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md index 18b4ac27f1a57b..6db16091f9251a 100644 --- a/EIPS/eip-7702.md +++ b/EIPS/eip-7702.md @@ -75,7 +75,7 @@ In case a delegation designator points to another designator, creating a potenti #### Gas Costs -The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. Additionally, we add a cost of `PER_CONTRACT_CODE_BASE_COST * authorization list length`. +The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. Additionally, we add a cost of `PER_AUTH_BASE_COST * authorization list length`. The transaction sender will pay for all authorization tuples, regardless of validity or duplication.