Update EIP-5806: Disable create2 following pushback

Merged by EIP-Bot.

EIPS/eip-5806.md

@@ -17,15 +17,15 @@ This EIP adds a new transaction type that allows EOAs to execute arbitrary code
 
 ## Motivation
 
-EOA are the most widely used type of account, yet their ability to perform operations is limited to deploying contracts and sending "call" transactions. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interactions users can have with the blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [ERC-4337](./eip-4337.md) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](./eip-3074.md) proposes another option to extend the ability of EOA to execute batched or conditional calls, but remains limited to calls operation (with no access to opcodes such as create2).
+EOA are the most widely used type of account, yet their ability to perform operations is limited to deploying contracts and sending "call" transactions. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interactions users can have with the blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [ERC-4337](./eip-4337.md) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications.
 
 While smart contract wallets have a lot to offer in terms of UX, it is unlikely that all users will migrate any time soon because of the associated cost and the fact that some EOAs have custody of non-transferable assets.
 
 This EIP proposes an approach to allow the execution of arbitrary code by EOAs, with minimal change over the EVM, and using the same security model users are used to. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](./eip-7.md)), EOAs will be able to have more control over what operations they want to execute. This proposal's goal is NOT to provide an account abstraction primitive.
 
 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`, or emitting events.
+Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes 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.
 
@@ -64,17 +64,10 @@ For security reasons, some opcodes should not be executed in the context of an E
 
 - `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) and `SELFDESTRUCT` (0xFF): There may be an expectation that transactions from a given sender should have consecutive nonces. This assumption would be broken if an EOA was able to execute one or multiple operations that alter the sender account's nonce. Consequently, EOA performing a delegate transaction should not be able to use the `CREATE` or `SELFDESTRUCT` opcodes. If a delegate transaction performs a CALL, the target of the call is free to create contracts normally.
+- `CREATE` (0xF0), `CREATE2` (0xF5) and `SELFDESTRUCT` (0xFF): There may be an expectation that transactions from a given sender should have consecutive nonces. This assumption would be broken if an EOA was able to execute one or multiple operations that alter the sender account's nonce. Consequently, EOA performing a delegate transaction should not be able to use the `CREATE`, `CREATE2` or `SELFDESTRUCT` opcodes. If a delegate transaction performs a CALL, the target of the call is free to create contracts normally.
 
 Any attempts to make execute one of these restricted operations will instead throw an exception.
 
-### Opcode modification
-
-Additionally, some opcodes behavior should be slightly modified in the context of an EOA:
-
-- `CREATE2` (0xF5): Similarly to `CREATE`, `CREATE2` does increment the nonce of the caller. However, unlike `CREATE` that depends on the nonce to compute the address of the created contract, and needs to increment it so that all contracts created have a proper address, `CREATE2` does not depend on that increment. Therefore, if an EOA tries to deploy a contract using `CREATE2` as part of a delegate transaction, the nonce of the EOA should not be incremented. The rest of the `CREATE2` logic remains unmodified.
-
-
 ## Rationale
 
 EOAs are the most widely used type of wallet.