EIP-5806: Delegate transaction
Adds a new transaction type that allows a EOAs to execute arbitrary code through delegation
作者 | Hadrien Croubois |
---|---|
讨论-To | https://ethereum-magicians.org/t/eip-5806-delegate-transaction/11409 |
状态 | Draft |
类型 | Standards Track |
分类 | Core |
创建日期 | 2022-10-20 |
依赖 | 2718, 2930 |
英文版 | https://eips.ethereum.org/EIPS/eip-5806 |
Abstract
This EIP adds a new transaction type that allows EOAs to execute arbitrary code using a delegate-call-like mechanism.
Motivation
Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as EIP-4337 hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. EIP-3074 proposes another approach that favors existing EOAs but comes with replay risks.
This EIP proposes a simpler approach that addresses some of the objectives of account abstraction for EOAs with minimal change over the EVM. 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.
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, while being the msg.sender
of all the sub calls. Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes emitting events, using storage under the EOA’s account, or even deploying contracts using create2
.
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.
Specification
The key words “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.
Parameters
FORK_BLKNUM
=TBD
TX_TYPE
= TBD, > 0x02 (EIP-1559)
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
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s])
The definitions of all fields share the same meaning with EIP-1559. Note the absence of amount
field in this transaction!
The signature_y_parity, signature_r, signature_s
elements of this transaction represent a secp256k1 signature over keccak256(0x02 || 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 can set and read storage under the EOA. It can also emit an event from the EOA.
Rationale
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)
Security Considerations
The nonce mechanism, already used in other transaction types, prevents replay attacks. This makes this approach safer, but also less powerful than EIP-3074.
Contracts being called through this mechanism can execute any operation on behalf of the signer. Signers should be extremely careful signing this transaction (just like any other transaction).
Copyright
Copyright and related rights waived via CC0.
参考文献
Please cite this document as:
Hadrien Croubois, "EIP-5806: Delegate transaction [DRAFT]," Ethereum Improvement Proposals, no. 5806, October 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5806.