# `CODERESET` for EIP 7702

### TLDR

The core of the suggested changes it to enable EOAs with contract code to reset themselves to have no contract code. Once the account is an SCA, it may return to being an EOA by removing it's own account code using a `CODERESET` opcode. This enables both ephemeral and persistent SCAs, removes extra work required to manage DOS and unlocks new use-cases.

### Context

There are currently two types of accounts in the Ethereum blockchain:

1. **EOAs**: an account with no contract code that is tightly coupled to a ECDSA key pair holding user assets with the ability to invoke smart contract code.
2. **SCAs:** smart contract acting as a user account that holds assets and proxies user requests to other smart contracts

SCAs offer several UX improvements such as:
1. Transaction batching
2. Paymasters and Gas sponsorship
3. Encoding granular permissioning

7702 aims to bring programability to EOAs and effectively allow them to act as SCAs under specific conditions.

### Current 7702 proposal

The current 7702 spec intoduces a new transaction type which allows the EOA to set a pointer to contract code which would execute in place of the EOA. There has been some back and forth regarding whether a 7702 account should be ephemeral (ie, only hold code for the duration of the transaction), or persistent (ie, retain contract code which may be invoked by other transactions). The persistent proposal retains the ability of the EOA to author transaction requests in paralel to the possibility of its code being called by other accounts. This is in part to enable it to update it's code pointer if desired.


### Motivation for changes

7702 as currently proposed allows an account type to always behave as an EOA and sometime behaves as a SCA. This makes it difficult to reason about it's security and impossible to enforce permissioning policies.

1. **Bypassing on-chain policies**: Since a 7702 account under the current proposal can always generate valid EOA transactions, it can bypass all on-chain policies encoded in the contract code.
a. The 7702 account cannot implement multisig logic or other more advanced policies.
b. The 7702 account cannot issue timelocks over it's tokens, thus being incompatible with credible accounts / cross-chain applications which need equivocation protection.
2. **Network DOS**: The mempool DOS properties for EOAs and smart contract are robust, but it is difficult to reason about the DOS vector of a new account type. Several mitigations have been suggested, but will require additional work before considered robust.

### Suggested changes

The core of the suggested changes is to remove the ability of EOAs to make transactions when the account has code. This enforces that an account can either act as an EOA or as an SCA, but not both. Once the account is an SCA, it may return to being an EOA by removing it's own account code using a `CODERESET` opcode.

The following changes would be made to the EIP:

1. **Disable EOA transaction origination:** Continue to prevent an account with code from originating a transaction, as specified in EIP-3607. [ref](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md#transaction-origination)
2. **`CODERESET` opcode**: The account can return to acting as an EOA through a `CODERESET` OPCODE which deletes its code. `CODERESET` only removes code and not the state of the account. The SCA needs to call the `CODERESET` method via a contract call to enable switching back to EOA.
3. **Optional calldata**: An optional calldata field should be added to the signed 7702 transaction. This is so that the user can properly initialize the storage variables of the SCA. If calldata is provided, it must be called and must not revert. If it reverts, the code is not set up but the transaction itself remains valid (and pays for that revert). If calldata is specified, the user also has to specify a gas limit. [ref](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md#no-initcode)

### Discussion

#### Benefits of the suggested changes

1. **DOS resistance**: Since the account is only ever either an EOA or a smart contract, there exists robust DOS resistance at the network layer.
2. **Policy compatibility**: Since the holder of the private key cannot bypass the code of the account, advanced permissioning policies such as multisigs can be enforced. A multisig account would place the `CODERESET` OPCODE behind a valid multisig request.
3. **Timelock compatibility**: Since the `CODERESET` OPCODE can be placed behind a timelock, the account can act as a credible account and thus be compatible with cross-chain applications.
4. **Ephemerality compatibility**: The calldata passed in the initialization transaction may execute the `CODERESET` OPCODE thus returning it to being an EOA in the same transaction. This provides the option to support both ephemeral accounts or presistent accounts.

#### Drawbacks of the suggested changes (and potential mitigations)

1. **No invalidation of signed messages**
Apps which rely on `ecrecover` alone without the use of ERC1271 for authenticating a signed message will improperly verify the privileges of the requestor. This issue exists for all 7702 proposals where switching from EOA to SCA creates a change of assumption over what is considered a valid signed message. Immutable contracts which do not suport ERC1271 will hopefully eventually be deprecated, thus minimizing the surface for error.
2. **Storage slot collisions between implementations**
Since `CODERESET` does not delete storage, an account risks accidentaly overwriting or reusing old values in the accounts storage.
This issue can be mitigated in paralel to 7702 and should not be a blocker
1. **Compiler level mitigation (Solidity Pragma)**: For each new implementation developers manually define the namespace for calculating the storage slot hashes by specifying the namespace in the #pragma of their solidity file. The hash from the namespace is calculated at compilation. It allows to reuse the existing storage layout for old variables as well as define a new one for the newly introduced variables.
2. **EVM level mitigation (Storage Nonce)**: A `storage_nonce` variable can be added to all accounts to ensure fresh storage namespace is used after every initialization. The nonce is hashed and prefixed to `SLOAD` and `SSTORE` opcode calls.
For example: `SSTORE'(key, value) := SSTORE(keccak(key, storage_nonce), value)`.
3. **Improper SCA code**: An application may improperly implement the logic around `CODERESET` thus bricking an account.
4. **Multi-wallet compatibility**: Once upgraded to a SCA, a user may be confused why there account no longer works with wallets which do not support SCAs.

### Reviewers

These changes were initially discussed at the eip 7702 workshop organized by WalletConnect at ETHCC 2024.

- lightclient from geth
- Yoav and Dror from 4337 team
- Pedro and Derek from Walletconnect
- Richard and Lukas from Safe
- Greg from Chainsafe
- Arik from Fireblocks
- Cola from OKX
- David Kim from Trust Wallet
- Itamar from Argent
- Denxi from Rabby wallet
- Alex Bash from Zerion
- Ankit and Stephane from Frontier Research