Update EIP-7702: add delegation designation

Merged by EIP-Bot.

Author: lightclient

EIPS/eip-7702.md

@@ -1,19 +1,19 @@
 ---
 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
 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 `[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
 
@@ -40,38 +40,49 @@ 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 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])`.
 
 #### 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 `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).)
 
-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.
+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.
 
+##### 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`.
+
+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`.
+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.
 
+#### 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. `0xef0100 || address`, to continue to originate transactions. Accounts with any other code values may not originate transactions.
+
 ## Rationale
 
 ### No initcode
@@ -108,9 +119,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
 
@@ -146,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