Adds a new transaction type that allows EOAs to execute arbitrary code through delegation.
Introduces a new transaction type that allows Externally Owned Accounts (EOAs) to execute arbitrary code using a delegate-call-like mechanism. This is significant because it extends the capabilities of EOAs, which are traditionally limited to deploying contracts and sending "call" transactions, by enabling them to perform more complex operations similar to those of smart contracts. EIP-5806 is noteworthy for its potential to significantly enhance the functionality and security of EOAs, paving the way for more complex and secure interactions on the Ethereum network.
This EIP adds a new transaction type that allows EOAs to execute arbitrary code using a delegate-call-like mechanism.
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 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), 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 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.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
FORK_BLKNUM = TBDTX_TYPE = TBD, > 0x03 (EIP-4844)As of FORK_BLOCK_NUMBER, a new EIP-2718 transaction is introduced with TransactionType = TX_TYPE(TBD).
The intrinsic cost of the new transaction is inherited from EIP-2930, specifically 21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count.
The EIP-2718 TransactionPayload for this transaction is
The definitions of all fields follow the same semantics as EIP-1559. Note the absence of amount field in this transaction!
The to field deviates slightly from the semantics with the exception that it MUST NOT be nil and therefore must always represent a 20-byte address. This means that delegate transactions cannot have the form of a create transaction.
The signature_y_parity, signature_r, signature_s elements of this transaction represent a secp256k1 signature over keccak256(TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).
The EIP-2718 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, 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.
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 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 forbidden 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), 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.
EOAs are the most widely used type of wallet.
This EIP would drastically expand the ability of EOAs to interact with smart contracts by using the pre-existing and well-understood delegation mechanism introduced in EIP-7 and without adding new complexity to the EVM.
No known backward compatibility issues thanks to the transaction envelope (EIP-2718).
Due to the inclusion logic and the gas cost being similar to type 2 transactions, it should be possible to include this new transaction type in the same mempool.
The nonce mechanism, already used in other transaction types, prevents replay attacks. Similar to existing transaction types, a delegate transaction can be cancelled by replacing it with a dummy transaction that pays more fees.
Since the object signed by the wallet is a transaction and not a signature that could potentially be processed in many ways (as is the case for EIP-3074), the risks associated with the miss-use of the signature are reduced. A wallet could simulate the execution of this delegate transaction and provide good guarantees that the operation that the user signs won't be manipulated.
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.
Copyright and related rights waived via CC0.