Update EIP-5806: Restrict SSTORE and CREATE

Merged by EIP-Bot.

EIPS/eip-5806.md

@@ -25,7 +25,7 @@ This EIP proposes an approach to allow the execution of arbitrary code by EOAs,
 
 By performing a delegate call to a multicall contract (such as the one deployed to `0xcA11bde05977b3631167028862bE2a173976CA11`), EOAs would be able to batch multiple transactions into a single one (being the `msg.sender` of all the sub calls). This would provide a better UX for users that want to interact with protocols (no need for multiple transactions, with variable gas prices and 21k gas overhead) and increase the security of such interactions (by avoiding unsafe token approvals being exploited between an `approval` and the following `transferFrom`).
 
-Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes deploying contracts using `create2`, emitting events, or using storage under the EOA's account.
+Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes deploying contracts using `create2`, or emitting events.
 
 This EIP doesn't aim to replace other account abstraction proposals. It hopes to be an easy-to-implement alternative that would significantly improve the user experience of EOA owners in the near future.
 
@@ -56,7 +56,15 @@ The `signature_y_parity, signature_r, signature_s` elements of this transaction
 
 The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.
 
-The execution of this new transaction type is equivalent to the delegate call mechanism introduced in [EIP-7](./eip-7.md), but performed by an EOA (the transaction sender). This implies that the code present at `destination`, if any, should be executed in the context of the sender. As a consequence, such a transaction can set and read storage under the EOA. It can also emit an event from the EOA or use `Create2` with the address of the EOA as the creator.
+The execution of this new transaction type is equivalent to the delegate call mechanism introduced in [EIP-7](./eip-7.md), but performed by an EOA (the transaction sender). This implies that the code present at `destination`, if any, should be executed in the context of the sender. As a consequence, such a transaction emit an event from the EOA or use `Create2` with the address of the EOA as the creator. This transaction includes some restrictions though.
+
+### Opcode restriction
+
+For security reasons, some opcodes should not be executed in the context of an EOA:
+
+- SSTORE (0x55): Setting storage under an EOA breaks many assumptions. In particular storage set through a delegate transaction could cause issues if the accounts later "migrates" using [EIP-7377](./eip-7377.md) or similar. Additionally, storage may be a source of conflicts if a single EOA uses delegate transactions to target codes that interpret the storage layout under this account differently. For all these reasons, EOA should be forbiden from performing SSTORE in the context of a delegate transaction. If a delegate transaction performs a CALL, the target of the call is free to manipulate storage normally.
+
+- CREATE (0xF0): Executing a delegate transaction, like any other transaction, increments the sender's nonce. There may be an expectations that transactions from a given sender should have consecutive nonces. Performing multiple contract creations using the CREATE opcode, as part of a delegate transaction would break that assumption. Consequently, EOA performing a delegate transaction should not be able to use the CREATE opcode. Batching contract deployments remains possible using CREATE2, which is not restricted. If a delegate transaction performs a CALL, the target of the call is free to create contracts normally.
 
 ## Rationale
 
@@ -78,10 +86,6 @@ Since the object signed by the wallet is a transaction and not a signature that
 
 Contracts being called through this mechanism can execute any operation on behalf of the signer. As with other transaction types, signers should be extremely careful when signing a delegate transaction.
 
-Because an EOA may perform delegate transactions to multiple contracts in its lifetime, there are risks associated with the storage under the EOA. Multiple contracts could have conflicting views of storage and tamper with one another. This would be potentially dangerous if wallets perform delegate transactions to arbitrary contracts that rely on existing storage. Wallets, on the other hand could hide this transaction type behind abstract interfaces for batch transactions (or others) that use standard contracts as targets (such as the one at `0xcA11bde05977b3631167028862bE2a173976CA11`). In any case, storage conflict should be detectable through simulation of the delegate transaction and could be resolved using a delegate transaction.
-
-If another EIP introduces a mechanism to place code at an EOA address, effectively turning it into a smart contract, then storage set by delegate transactions before the deployment of the code may interfere with the expectation that contracts are deployed to accounts with empty storage.
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).