Update EIP-7702: restrict field sizes

Merged by EIP-Bot.

Author: lightclient

EIPS/eip-7702.md

@@ -2,13 +2,13 @@
 eip: 7702
 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)
+author: Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), lightclient (@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: 2, 2718, 2929, 2930, 3541, 3607
+requires: 2, 161, 1052, 2718, 2929, 2930, 3541, 3607
 ---
 
 ## Abstract
@@ -31,7 +31,7 @@ There is a lot of interest in adding short-term functionality improvements to EO
 | ------------------------ | ------- |
 | `SET_CODE_TX_TYPE`       | `0x04`  |
 | `MAGIC`                  | `0x05`  |
-| `PER_AUTH_BASE_COST`     | `2500`  |
+| `PER_AUTH_BASE_COST`     | `15000`  |
 | `PER_EMPTY_ACCOUNT_COST` | `25000` |
 
 ### Set Code Transaction
@@ -52,10 +52,10 @@ The transaction is also considered invalid when any field in an authorization
 tuple cannot fit within the following bounds:
 
 ```python
-assert auth.chain_id < 2**256
+assert auth.chain_id < 2**64
 assert auth.nonce < 2**64
 assert len(auth.address) == 20
-assert auth.y_parity < 2**256
+assert auth.y_parity < 2**8
 assert auth.r < 2**256
 assert auth.s < 2**256
 ```
@@ -73,7 +73,8 @@ At the start of executing the transaction, after incrementing the sender's nonce
 5. Verify the code of `authority` 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.
+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 accounts code and reset the account's code hash to `0x0000000000000000000000000000000000000000000000000000000000000000`.
 9. Increase the nonce of `authority` 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.
@@ -106,8 +107,22 @@ If a code reading instruction accesses a cold account during the resolution of d
 
 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.
 
+Additionally, if a transaction's `destination` has a delegation designation, add the target of the delegation to `accessed_addresses`.
+
 ## Rationale
 
+### Cost of Delegation
+
+The `PER_AUTH_BASE_COST` is the cost to process the authorization tuple and set the delegation destination. We are able to compute a fair cost for this operation by reviewing its impact on the system:
+
+* ferry 101 bytes of calldata = `101 * 16 = 1616`
+* recovering the `authority` address = `3000` 
+* reading the nonce and code of `authority` = `5000`
+* storing values in already warm account = `200`
+* cost to deploy code = `200 * 23 = 4600`
+
+The impact-based assessment leaves us with `14416` gas for the operation. We round up to `15000` to account for miscellaneous costs associated with shuttling data around the state transition.
+
 ### No initcode
 
 Running initcode is not desirable for many reasons. The chief concern is it's unnatural. Initcode is intended to initialize and deploy contracts. With this EIP, it will take on a new role of determining whether it is appropriate to deploy code to the EOA. Suppose a user only wants code deployed to their account if they also have an operation bundled with the general transaction calldata. This gives EOAs a unique power to control when and what code executes in their account. Although [EIP-7702](./eip-7702.md) as written still allows this to a degree, the lack of programmability in the decision will force wallets to not sign many authorization tuples and instead focus on signing only a tuple pointing to a configurable proxy. This affords EOAs a similar experience to smart contract wallets.
@@ -180,6 +195,14 @@ Specifically:
 * It does not require adding any opcodes, that would become dangling and useless in a post-EOA world.
 * It allows EOAs to masquerade as contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`.
 
+### Clearing Delegation Designations
+
+A general design goal of state transition changes is to minimize the number of special cases an EIP has. In early iterations, this EIP resisted a special case for clearing an account's delegation designation.
+
+For most intents and purposes, an account delegated to `0x0` is indistinguishable from a true EOA. However, one particular unfortunate case is unavoidable. Even if a user has a zeroed out delegation designation, most operations that interact with that account will encounter an additional `COLD_ACCOUNT_READ_COST` upon the first touch. 
+
+This is not ideal and may be a significant enough concern to impact the overall adoption of the EIP. For these reasons, we have opted to include a mechanism which allow users to restore their EOA to its original pureness.
+
 ## Backwards Compatibility
 
 This EIP breaks the invariant that an account balance can only decrease as a result of transactions originating from that account. It also breaks the invariant that an EOA nonce may not increase after transaction execution has begun. These breakages have consequences for mempool design, and for other EIPs such as inclusion lists. However, because the accounts are listed statically in the outer transaction, it is possible to modify transaction propagation rules so that conflicting transactions are not forwarded.