ERC-7796: 有条件发送交易 RPC

面向区块构建者的 JSON-RPC API，允许用户表达交易包含的前提条件

摘要

本 EIP 提出了一种新的 JSON-RPC API 方法 eth_sendRawTransactionConditional，用于区块构建者和排序器， 通过允许用户表达交易包含的前提条件来增强交易集成。

此方法旨在通过减少交易模拟的需求来提高效率， 从而提高交易排序的计算效率。

动机

当前私有区块构建者 API，例如 Flashbots API， 要求区块构建者模拟交易以确定其是否有资格被包含， 这个过程是 CPU 密集型的且效率低下。

这个提议的 RPC 方法通过允许交易指定前提条件来解决这个问题， 从而减少计算开销，并可能降低交易成本。

此外，flashbots API 没有为区块构建者提供一种机制来确定不同交易的 交叉依赖关系。

保证另一个交易不干扰给定交易的唯一方法是将其放置为 区块中的第一笔交易。 这使得这种位置非常有利可图，并且成本高得不成比例。

此外，由于无法保证其他插槽，因此其定价必须相应地降低。

由于没有简单的方法来检测不同交易的交叉依赖关系， 因此找到交易的最佳排序是 CPU 密集型的。

规范

• 方法: eth_sendRawTransactionConditional

• 参数:

1. transaction: 原始的、已签名的交易数据。类似于 eth_sendRawTransaction。
2. options: 一个包含交易必须包含的条件的 object。
   • options 参数可能包含以下任何可选成员：
   • knownAccounts: 账户与其预期存储槽值的映射。
     • 映射的键是帐户地址。
     • 特殊键 balance 定义了帐户的预期余额。
     • 特殊键 code 定义了帐户的预期代码。 使用 "" 表明预期该地址没有任何代码。 使用 "0xef0100" 前缀来指示特定的 EIP-7702 委托。
     • 特殊键 nonce 定义了帐户的预期 nonce。
     • 如果该值是 hex string，则是该帐户的已知存储根哈希。
     • 如果该值是 object，那么它是一个映射，其中每个成员的格式为 "slot": "value"。 value 字段是帐户存储的显式槽值。 slot 和 value 都是十六进制编码的字符串。
   • blockNumberMin: 包含的最小区块高度。
   • blockNumberMax: 包含的最大区块高度。
   • timestampMin: 包含的最小区块时间戳。
   • timestampMax: 包含的最大区块时间戳。
   • paysCoinbase: 调用者声明此交易向 coinbase 支付的最低金额， 包括 gas 费用和直接支付。

在接受请求之前，区块构建者或排序器应：

• 如果指定了区块高度范围值，请检查区块高度是否在区块高度范围内。
• 如果指定了时间戳范围，请检查区块时间戳是否在时间戳范围内。
• 对于所有具有指定存储根哈希的地址，验证当前根是否未修改。
• 对于所有具有指定插槽值映射的地址，验证所有这些插槽是否都具有指定的精确值。

如果任何地址未通过上述规则，则排序器应拒绝该请求。

返回值

如果成功包含，则调用应返回新提交的交易的哈希值。 此行为等效于 eth_sendRawTransaction JSON-RPC API 方法。

如果立即无法验证交易的条件， 则区块构建者应返回带有失败原因指示的错误。

错误代码应为 “-32003 transaction rejected”，并带有描述原因的字符串： 例如，存储错误、超出区块/时间范围等。

如果重复失败或 knownAccounts 映射对于当前区块构建者来说过大而无法处理， 则错误代码应为 “-32005 limit exceeded”，并带有错误描述。

注意：与 eth_sendRawTransaction 方法相同， 即使 RPC 方法调用没有导致错误并且交易最初被 接受到内部区块构建者的 mempool 中， 调用者也不得假设交易将被包含在区块中，而应监视区块链。

示例请求

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_sendRawTransactionConditional",
    "params": [
        "0x2815c17b00...",
        {
            "blockNumberMax": 12345,
            "knownAccounts": {
                "0xadd1": "0xfedc....",
                "0xadd2": { 
                    "0x1111": "0x1234...",
                    "0x2222": "0x4567..."
                }
            }     
        } 
    ]
}

局限性

• 调用者不应假定成功的响应意味着该交易已被包含。 具体来说，区块重新排序可能会删除交易或导致交易失败。

原理

knownAccounts 仅允许指定存储槽的精确值。 虽然在某些情况下，为插槽指定 minValue 或 maxValue 可能很有用， 但这将大大增加提议的 API 的复杂性。 此外，确定插槽值的有效范围对于交易发送者来说是一项非易事的工作。

为交易条件提供更复杂规则的一种方法是指定 paysCoinbase 参数， 并在某些条件下向 coinbase 地址发出转账。

向后兼容性

这是对新 API 方法的提议，因此预计不会出现向后兼容性问题。 eth_sendRawTransactionConditional API 的现有非标准实现可能需要修改，以便与标准兼容。

安全注意事项

区块构建者应保护自己免受 API 滥用。 也就是说，恶意行为者提交大量已知会失败的请求可能会导致拒绝服务。

以下是建议的潜在缓解机制列表：

• 节流：区块构建者应允许每个发送者每秒最大 RPC 调用速率。 区块构建者可以在成功包含后提高该速率。 重复拒绝交易应降低允许的速率。
• Arbitrum 风格保护：Arbitrum 实现了此 API，但他们不仅对当前区块运行存储验证， 还对过去 2 秒进行验证。 这可以防止滥用 API 进行 MEV，同时使其适用于 ERC-4337 帐户验证。
• Fastlane on Polygon 明确将其用于 ERC-4337， 通过检查提交的 UserOperations 是否存在于公共 mempool 中，否则拒绝交易。

版权

版权和相关权利已通过 CC0 放弃。

Citation

Please cite this document as:

Dror Tirosh (@drortirosh), Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Shahaf Nacson (@shahafn), "ERC-7796: 有条件发送交易 RPC [DRAFT]," Ethereum Improvement Proposals, no. 7796, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7796.