EIP-5806: 委托交易

添加一种新的交易类型，允许 EOA 通过委托执行任意代码

摘要

本 EIP 添加了一种新的交易类型，允许 EOA 使用类似于委托调用的机制执行任意代码。

动机

EOA 是使用最广泛的账户类型，但它们执行操作的能力仅限于部署合约和发送 “调用” 交易。目前，EOA 无法执行任意代码，这极大地限制了用户与区块链的交互。账户抽象已被广泛讨论，但实现主流采用的道路仍不明确。某些方法，例如 ERC-4337，希望提高智能钱包的可用性，而无需解决应用程序对智能钱包支持的问题。

虽然智能合约钱包在用户体验方面有很多优势，但由于相关的成本以及某些 EOA 持有不可转让资产的事实，所有用户都很难在短期内迁移。

本 EIP 提出了一种方法，允许 EOA 执行任意代码，只需对 EVM 进行最小的更改，并使用用户习惯的安全模型。通过允许 EOA 对合约执行委托调用（类似于合约如何使用 EIP-7 将调用委托给其他合约），EOA 将能够更好地控制他们想要执行的操作。本提案的目标不是提供账户抽象原语。

通过对多重调用合约（例如部署到 0xcA11bde05977b3631167028862bE2a173976CA11 的合约）执行委托调用，EOA 能够将多个交易批处理到单个交易中（作为所有子调用的 msg.sender）。这将为希望与协议交互的用户提供更好的用户体验（无需多个交易，具有可变的 gas 价格和 21k gas 开销），并提高此类交互的安全性（通过避免在 approval 和后续的 transferFrom 之间利用不安全的 token 审批）。

其他无法预见的逻辑可以在智能合约中实现并由 EOA 使用。 这包括发出事件。

本 EIP 并非旨在取代其他帐户抽象提案。它有望成为一种易于实施的替代方案，可在不久的将来显着改善 EOA 所有者的用户体验。

规范

本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 必须按照 RFC 2119 中的描述进行解释。

参数

• FORK_BLKNUM = TBD
• TX_TYPE = TBD, > 0x03 (EIP-4844)

从 FORK_BLOCK_NUMBER 开始，引入了一个新的 EIP-2718 交易，其 TransactionType = TX_TYPE(TBD)。

新交易的内在成本继承自 EIP-2930，特别是 21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count。

EIP-2718 此交易的 TransactionPayload 为

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])

所有字段的定义都遵循与 EIP-1559 相同的语义。请注意此交易中缺少 amount 字段！

to 字段与语义略有不同，但它 MUST NOT 为 nil，因此必须始终表示一个 20 字节的地址。这意味着委托交易不能采用创建交易的形式。

此交易的 signature_y_parity, signature_r, signature_s 元素表示对 keccak256(TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])) 的 secp256k1 签名。

EIP-2718 此交易的 ReceiptPayload 为 rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])。

此新交易类型的执行等同于 EIP-7 中引入的委托调用机制，但由 EOA（交易发送者）执行。这意味着 destination 处存在的代码（如果有）应在发送者的上下文中执行。因此，此类交易会从 EOA 发出一个事件，或使用 EOA 的地址作为创建者来使用 Create2。但是，此交易包括一些限制。

操作码限制

出于安全原因，某些操作码不应在 EOA 的上下文中执行：

• SSTORE (0x55): 在 EOA 下设置存储会破坏许多假设。特别是，通过委托交易设置的存储可能会导致问题，如果帐户稍后使用 EIP-7377 或类似方式“迁移”。此外，如果单个 EOA 使用委托交易来定位以不同方式解释此帐户下存储布局的代码，则存储可能成为冲突的根源。出于所有这些原因，应禁止 EOA 在委托交易的上下文中执行 SSTORE。如果委托交易执行 CALL，则调用的目标可以正常操作存储。

• CREATE (0xF0), CREATE2 (0xF5) 和 SELFDESTRUCT (0xFF): 可能会期望来自给定发送者的交易应具有连续的 nonce。如果 EOA 能够执行一个或多个更改发送者帐户 nonce 的操作，则此假设将被打破。因此，执行委托交易的 EOA 不应能够使用 CREATE、CREATE2 或 SELFDESTRUCT 操作码。如果委托交易执行 CALL，则调用的目标可以正常创建合约。

任何尝试执行这些受限操作之一的操作都将抛出异常。

理由

EOA 是使用最广泛的钱包类型。

通过使用 EIP-7 中引入的预先存在的且已得到充分理解的委托机制，并且无需向 EVM 添加新的复杂性，本 EIP 将极大地扩展 EOA 与智能合约交互的能力。

向后兼容性

由于交易信封 (EIP-2718)，没有已知的向后兼容性问题。

由于包含逻辑和 gas 成本与 2 型交易相似，因此应可以将这种新的交易类型包含在同一 mempool 中。

安全注意事项

nonce 机制（已在其他交易类型中使用）可以防止重放攻击。与现有交易类型类似，可以通过用支付更多费用的虚拟交易替换委托交易来取消该交易。

由于钱包签名的对象是一个交易，而不是可能以多种方式处理的签名（如 EIP-3074 的情况），因此与签名滥用相关的风险降低了。钱包可以模拟此委托交易的执行，并提供良好的保证，即用户签名的操作不会被操纵。

通过此机制调用的合约可以代表签名者执行任何操作。与其他交易类型一样，签名者在签署委托交易时应格外小心。

版权

通过 CC0 放弃版权及相关权利。

Citation

Please cite this document as:

Hadrien Croubois (@Amxx), "EIP-5806: 委托交易 [DRAFT]," Ethereum Improvement Proposals, no. 5806, October 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5806.