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

### Introduction

The recent proposal [“`CODERESET` for EIP 7702”](https://hackmd.io/@S9AwbucvTS6GYodLz-G1SQ/S102UtTwA) 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](https://eips.ethereum.org/EIPS/eip-7702) by [lightclients](https://hackmd.io/@matt) 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:

1. the use of external storage with adequate access controls, or
2. 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](https://hackmd.io/@lattejed) and [julrach](https://hackmd.io/@julrach)