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: updates for devnet4 #8929

Merged
merged 4 commits into from
Oct 9, 2024
Merged

Update EIP-7702: updates for devnet4 #8929

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3e5de77
7702: restrict field sizes
lightclient Oct 3, 2024
9a9256e
7702: update cost of auth, add mechanism to fully clear delegation
lightclient Oct 9, 2024
7d7f09a
7702: add more rationale
lightclient Oct 9, 2024
9d4d17a
7702: typo
lightclient Oct 9, 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
35 changes: 29 additions & 6 deletions EIPS/eip-7702.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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
```
Expand All @@ -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`.
Copy link
Member

Choose a reason for hiding this comment

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

Why is the account code hash set to these zeros? It should be set to keccak256("")?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah you're right. Let me update it.

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.
Expand Down Expand Up @@ -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`
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I see where the 101 comes from (flat bytes of the authority tuple) but this is not super clear. 16 is calldata gas cost for nonzero bytes.

* recovering the `authority` address = `3000`
Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a note that this is ecrecover precompile cost?

* reading the nonce and code of `authority` = `5000`
Copy link
Member

Choose a reason for hiding this comment

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

Where does the 5000 cost come from? (If I would check cold extcodecopy I pay 2600 gas, and then nonce can be directly read since we have to read the account RLP (which contains the nonce))

* 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.
Expand Down Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

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

This is a super great addition 😄 👍


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