[EIP-7702] Response to `CODERESET` Proposal + Reflection on the Current Spec’s State

Introduction

The recent proposal “CODERESET for EIP 7702” brings a new set of suggested changes to EIP-7702. These changes are unlikely to seem necessary or appeal to all teams building products on the proposed protocol changes. More importantly, this proposal highlights the need for balance between safety and keeping the design space open to allow for innovation.

Like most teams building on EIP-7702 and contributing to the discussions around it, we are a for-profit business that wants to bring new products to the ecosystem. We see new opportunities to make Ethereum useful for people.

As much as it would make sense from a business standpoint, we do not want EIP-7702 tailored to our specific needs. We want these changes to be open-ended enough such that people can innovate and new things can be built. We think this is the correct approach for a decentralized ecosystem.

Our Stance

We are in favor of:

making the protocol changes safe for users
keeping the design space open to enable innovation
shipping, rather than delaying, these changes

We are not in favor of:

changes that restrict the design space to fit the needs of a single team (or a handful of teams)

Current EIP-7702 Spec with In-Protocol Revocation

We feel the latest proposal by lightclients strikes the correct balance between protocol safety and flexibility. In our opinion, having worked on a lot of the changes to Reth ourselves and having collaborated with other client teams, we believe it is feasible for teams to land these changes in Pectra.

Adding a new set of requirements at this late stage jeopardizes this EIP’s inclusion in Pectra. Adding restrictions narrows the design space unnecessarily.

Shared Storage

We have been through this extensively and are confident the only way to make shared storage viable would require that EVMs segregate storage. Namespacing (including using a nonce in the EVM) is predicable and exploitable by a malicious contract.

While delegated, an EOA/delegation contract pair has exclusive access to the EOA’s storage, but it is possible for a malicious contract to modify that storage if it is temporarily delegated to. An attacker could attack the namespaced storage at this moment.

There is no concept of 1:N contract storage in Ethereum. We feel it is ok to recommend:

the use of external storage with adequate access controls, or
clearing the required storage at the beginning of a delegation

The alternative to this would require fundamental changes to how Ethereum works. You could have the EVM enforce segregation but that would require changing how the storage trie works. This would require significant changes and would touch every existing contract in the network.

Mempool DoS

We are hesitant to directly address this as both the attack and the proposed mitigation are vague in the proposal mentioned in the title.

Alternative Ephemeral Delegation Solution

We understand some teams want the new proposal to include ephemeral delegations (like the first version of 7702). We propose a flag be added to the 7702 transaction’s authorization_list that would designate it as ephemeral, clearing the code hash at the end of the execution.

While we do not understand the use case for this particular feature, we feel like it opens up (rather than restricts) new possibilities and are therefore in favor of it. We do not think this requires a new opcode or significant changes to the current EIP and the resulting additional work by EC (and other) teams that would require.

– lattejed and julrach

Yoav Weiss

2024/07/18 12:31:11

by a malicious contract

Namespacing is not meant (and can't) protect against a malicious contract. It is meant to allow safe migration between *legitimate* implementations. E.g. switching between two unrelated account implementations without risking shadow signers/modules lurking in some mapping left from the old implementation.

2024/07/18 12:33:16

clearing the required storage at the beginning of a delegation

Not feasible if the account uses mapping (e.g. for signers or modules). You can't predict the storage slots that an implementation will use throughout its lifetime unless it only uses simple variables and fixed size arrays.

2024/07/18 12:54:25

attack

Example: 1. Set the implementation of `N` EOAs to a contract that has a `withdrawAllEth()`. Each of them can withdraw from any of the others. 2. Propagate `N/2` txns from `N/2` EOAs. Each txn pulls the eth from all these EOAs and sends it to the other half of the EOAs. These txns are mutually exclusive because each txn makes the others unable to pay gas. 3. For each of these EOAs, immediately propagate 62 pending txns (geth default max is 63 IIRC). Make some of them big 4844 blobs for extra effect. 4. As soon as one of the txns is included (and the others are dropped due to lack of eth), repeat with the other `N/2` which are now funded. 5. Rinse and repeat. Effect on the mempool: for each included txn, the mempool had to process and drop `63*N/2-1` transactions, many of which are blobs. The mempool would be saturated. Effect on block builders: assuming the DoS txns are the highest paying ones, builder includes one and processes and drops many others. For big N, it might miss slots.

2024/07/18 13:02:41

mitigation

The root cause for the attack is that the current 7702 added a 3rd account type, which is both an EOA and a contract. We could mitigate it in various ways but the one easiest to reason about is not to add a 3rd type. The proposal does this by making the account alternate between EOA and contract, but never be both at the same time. Nodes will be able to statically analyze 7702 txns and see which EOAs they convert to contracts. They'll know it's going to invalidate all pending txns from these EOAs and treat it accordingly. Once the account stops being an EOA, no further txns are propagated from it, until it CODERESETs. Other effective mitigations have been proposed so this proposal is not the only way. It just happens to cleanly mitigate the attack.

2024/07/18 13:05:23

new opcode

Not really a new opcode. Define the behavior of SELFDESTRUCT in the context of an EOA. Currently it is only defined in contracts (EIP-6780). We could define that in an EOA that has a 7702 implementation, it resets the implementation (but doesn't touch storage).

2024/07/18 13:10:52

significant changes to the current EIP

I think it'll require two simple changes: 1. Remove the "Transaction Origination" section which bypasses EIP-3607. That's one sentence in the EIP, and actually simplifies the implementation. 2. Define the behavior of SELFDESTRUCT to set the implementation to 0 when called in an EOA. The whole change seems like 2-3 sentences in the EIP and a small change to the implementation of one opcode. Any other significant changes needed?