EIP-7727: EVM 交易捆绑

启用元交易来排序其他交易，而无需回滚保护。

摘要

本 EIP 引入了两个新的 EIP-2718 交易类型和一个新的 opcode，使智能合约和交易能够将其本地排序权限委托给链下实体。这些新的交易类型协同工作，创建 EVM 原生的“捆绑包”，这些捆绑包类似于但不强于构建者为搜索者提供的提案者-构建者分离 (PBS) 捆绑包。

其中一个 EIP-2718 交易是扩展的常规交易，它支持：

• 指定可以将交易放入捆绑包中的实体。
• 可选的交易有效的区块号。

另一个 EIP-2718 交易是“元”交易，它不进入执行，而是对其自身的类型和其他新类型的交易进行排序。“元”交易还可以指定允许将其包含在捆绑包中的实体和一个有效的区块号。

新的 opcode 向 EVM 揭示了将交易放入捆绑包中的实体（如果交易在捆绑包中）。

动机

目前，单个区块构建者对区块交易的最终排序拥有不受限制的控制权。 这就出现了一个问题，因为排序（选择谁可以与特定的状态片段交互以及以何种顺序交互）会显著影响价值流。 本 EIP 的目标是允许更多方参与单个区块的构建，方法是在 EVM 内部公开排序概念。 这种改变将使 EVM 应用程序能够收回目前由区块构建者垄断的一些排序价值，并将其重定向回应用程序本身。

规范

常量

新的交易负载类型

两种新的 EIP-2718 交易，类型为 DELEGATED_TX_TYPE 和 BUNDLE_TX_TYPE。

对于 DELEGATED_TX_TYPE，交易负载应解释为：

0x05 || rlp([
	bundleSigner,
	blockNumber,
	chainId, 
	nonce, 
	gasPrice, 
	gasLimit, 
	to, 
	value, 
	data, 
	signatureYParity, 
	signatureR, 
	signatureS
])

DELEGATED_TX_TYPE 的 signatureYParity、signatureR、signatureS 元素表示对以下内容的 secp256k1 签名：

keccak256(0x05 || rlp([bundleSigner, blockNumber, chain_id, nonce, gasPrice, gasLimit, to, value, data]))

对于 BUNDLE_TX_TYPE，交易负载应解释为：

0x06 || rlp([
	bundleSigner,
	blockNumber,
	chainId, 
	nonce, 
	gasPrice, 
	transactionList
	signatureYParity, 
	signatureR, 
	signatureS
])

其中 transactionList 元素是 DELEGATED_TX_TYPE 或 BUNDLE_TX_TYPE 类型的语法上有效的交易的列表。 列表中必须至少有一笔交易。

transactionList 的一个例子是：

[
	DELEGATED_TX_TYPE.payload, 
	BUNDLE_TX_TYPE.payload, 
	DELEGATED_TX_TYPE.payload
]

BUNDLE_TX_TYPE 的 signatureYParity、signatureR、signatureS 元素表示对以下内容的 secp256k1 签名：

keccak256(0x06 || rlp([bundleSigner, blockNumber, chainId, nonce, gasPrice, transactionList]))

我们将把此签名解析的地址称为捆绑交易的签名者。

BUNDLE_SIGNER 操作码

BUNDLE_SIGNER 是一个新的操作码，由 BUNDLE_SIGNER_OPCODE_NUMBER 标识，需要零个堆栈参数。

当交易类型为 DELEGATED_TX_TYPE 时，此操作码会将交易负载中的 bundleSigner 作为地址推送到堆栈上。 如果交易类型不同，则返回零地址。

此操作码的 gas 成本为 GAS_VERY_LOW gas 常量。

交易有效性规则

要使 DELEGATED_TX_TYPE 有效，必须满足以下条件：

• 交易必须包含在 BUNDLE_TX_TYPE 的 transactionList 中才有效。
• 交易指定的 bundleSigner 必须等于对 BUNDLE_TX_TYPE 进行签名并将交易包含在 transactionList 中的地址。
• 负载变量 blockNumber（如果非零）必须是交易执行的区块号。

要使 BUNDLE_TX_TYPE 有效，必须满足以下条件：

• transactionList 中的所有交易都必须指定 BUNDLE_TX_TYPE 的签名者作为 bundleSigner。
• 如果 bundleSigner 负载变量不是零地址，则该交易必须包含在 BUNDLE_TX_TYPE 的 transactionList 中。
• 负载变量 blockNumber（如果非零）必须是交易执行的区块号。

Gas 成本

BUNDLE_TX_TYPE 有一个新的 gas 成本公式，该公式根据 transactionList 中的交易在执行时是否有效而变化。

如果 transactionList 中的交易无效，则 BUNDLE_TX_TYPE 交易的收费方式与无效交易的字节是典型交易的 CALL_DATA 的一部分相同。 如果内部交易有效，则将其包含在列表中不收取任何费用。

该公式计算如下：

BUNDLE_BASE_GAS_COST +
    (CALL_DATA_TOKEN_COST * transaction_list_invalid_tx_byte_length)

在处理开始时，BUNDLE_TX_TYPE 的签名者将按所有内部交易均无效的方式收取费用，并在每个有效交易完成执行后，退还有效交易的 gas 费用。

DELEGATED_TX_TYPE 遵循典型的 gas 成本计算规则。

执行

DELEGATED_TX_TYPE 正常执行，其中 BUNDLE_SIGNER 操作码返回 bundleSigner 负载变量。

BUNDLE_TX_TYPE 不启动执行上下文。 必须在任何 transactionList 执行开始之前增加 BUNDLE_TX_TYPE 的 NONCE。

ReceiptPayload 定义

对于能够开始执行的 DELEGATED_TX_TYPE 交易，其 EIP-2718 收据负载应解释为：

rlp([status, cumulativeGasUsed, logsBloom, logs])

无效的 DELEGATED_TX_TYPE 交易不会获得交易收据。

BUNDLE_TX_TYPE 交易的 EIP-2718 收据负载应解释为：

rlp([statusArray, cumulativeGasUsed])

其中 statusArray 是内部 transactionList 的交易的状态结果列表。 该列表的长度必须与 transactionList 相同，并按相同的顺序报告状态。 状态类型 0x3 应用于报告无效交易。

cumulateGasUsed 是 BUNDLE_TX_TYPE 的签名者在 CALLDATA 退款后在 BUNDLE_TX_TYPE 交易成本上花费的 gas 量。

理由

允许将无效交易包含在 BUNDLE_TX_TYPE 的 transactionList 中

如果不了解应用交易的状态根，就很难知道交易将如何执行。 BUNDLE_TX_TYPE 交易的创建者只能访问前一个区块的状态根，并且无法预测哪些交易将位于即将到来的区块总订单中的 BUNDLE_TX_TYPE 交易之前。 如果仅允许有效交易，则 BUNDLE_TX_TYPE 交易列表很容易因单个内部交易试图通过 nonce 或 gas 无效来破坏捆绑包而无效。

对无效交易向 BUNDLE_TX_TYPE 的签名者收取 CALLDATA gas 成本

区块链必须对节点执行的工作收费，以防止 DoS 攻击。 即使 BUNDLE_TX_TYPE 交易列表中的无效交易不执行，它们仍然以字节形式占用区块空间，并且必须由某个实体支付费用。 假设 BUNDLE_TX_TYPE 的创建者将是能够以相对准确性模拟先前区块状态并能够产生足够的利润来抵消所产生的任何无效成本的复杂实体。

应设置 BUNDLE_BASE_GAS_COST，以使尝试破坏 BUNDLE_TX_TYPE 签名者的成本高于覆盖无效交易的字节成本。

要求将 DELEGATED_TX_TYPE 类型交易包含在 BUNDLE_TX_TYPE 的 transactionList 中

如果 DELEGATED_TX_TYPE 交易能够在 BUNDLE_TX_TYPE 交易列表之外执行，那么 BUNDLE_TX_TYPE 签名者和总区块构建者之间将存在竞争，以争夺选择如何在本地对交易进行排序的权利。 如果 DELEGATED_TX_TYPE 交易签名者希望允许总区块构建者选择本地排序，则不应使用 DELEGATED_TX_TYPE 交易类型。

同样的原则适用于 BUNDLE_TX_TYPE 交易。 那些指定 bundleSigner 的交易必须仅包含在 BUNDLE_TX_TYPE 列表中，而那些未指定 bundleSigner 的交易不得包含在此类列表中。

不允许将其他交易类型包含在 BUNDLE_TX_TYPE 的 transactionList 中

此限制是作为预防措施实施的，将来可能会重新考虑。 允许将未指定 bundleSigner 的其他交易类型包含到 transactionList 中可能会导致多个搜索者尝试将同一交易包含在捆绑包中。 这可能会在区块中产生垃圾邮件。

与 PBS 搜索者捆绑包的差异

PBS 区块构建者目前以交易列表的形式向搜索者提供“捆绑包”作为服务，这些交易列表要么全部执行而不会回滚，要么不包含在区块中。 搜索者通常使用这些捆绑包来竞标成为第一个与某个状态片段交互或将逻辑放置在由非搜索者实体创建的交易之前或之后的权利，其中回溯和夹层是示例。 PBS 区块构建者提供此服务是为了获得订单流并增加其区块的价值。

BUNDLE_TX_TYPE 交易在两个关键方面有所不同：

1. 没有回滚保护。
2. 只有显式委托给 bundleSigner 的交易才能捆绑。

做出这些选择是为了防止对构建者的 DoS 攻击，并与其他运行其他算法的非 PBS 区块构建者兼容。

向后兼容性

未发现向后兼容性问题。

安全注意事项

如今，区块构建者存在问题，部分原因是他们能够执行审查和强制执行恶意排序。 即使将排序权限委托给特定实体，这些担忧仍然存在。 生成链下排序的代码应该是公开的，并以最小化信任的方式执行，例如在 TEE（可信执行环境）中或在具有更快区块时间的区块链上。

同样，将功能限制为由特定 BUNDLE_SIGNER 签名的交易的智能合约应提供一种机制，允许用户在不依赖委托排序实体在线或不恶意的情况下提取资金。 可以实施两步资金移除过程，以允许与捆绑包构建和模拟逻辑进行安全交互。

版权

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

Citation

Please cite this document as:

Lily Johnson (@lilyjjo), "EIP-7727: EVM 交易捆绑 [DRAFT]," Ethereum Improvement Proposals, no. 7727, June 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7727.