为什么ERC-4337 Bundlers 必须与区块构建者协作？

在我们之前的文章中，我们提到了一些当前在账户抽象（Account Abstraction，AA）生态系统中不明确的问题，包括 Bundle 处理 UserOperations 的方式存在风险。风险在于，如果用户同时向两个 Bundler 发送具有相同 nonce 的 UserOperations，并且两个 Bundler 在同一个区块中提交了这些交易，那么其中一个交易将会失败。在这种情况下，失败的 Bundler 将会无缘无故地支付少量的 gas 费用。我们称之为 nonce 碰撞。即使这不是一种测试行为，这种情况在区块链上一直存在。

在 ERC-4337 的官方文档中提到，Bundler 自身是一个区块构建者，或者与区块构建者合作。在理论上，与区块构建者合作的 Bundler 可以完全避免因 nonce 碰撞导致的交易失败。然而，由于 AA 开发的早期阶段，实际上并不总是这样。

在本文中，我将详细讨论这个问题，以及 Bundler 生态系统的当前状态，并提供一些对公共 mempool 潜在出现的见解以及在 AA 被广泛采用后 Bundler 生态系统的未来。

具体发生了什么

为了最好地展示这个问题，我们在 Polygon Mumbai 上进行了一个测试，按照以下步骤进行：

1. 准备一个已经部署的合约钱包
2. 存入足够的资金以支付多个 UserOperations 的 gas
3. 构造一个短 calldata 且没有 Paymaster 或 Aggregator 的 UserOperation，以保持简单。
4. 同时将这个 UserOperation 使用相同 nonce 发送给两个不同的 Bundler。检查 EntryPoint 合约的历史记录，查看这两个 Bundler 发送的交易。

下表列出了一些交易的详细信息。 (交易 1; 交易 2)

表 1. 两个 bundlers 发送相同 UserOperation 的交易

以下是两个 Bundler 发生的情况。在接收到 UserOperation 后，每个 Bundler 根据当前区块链状态进行了模拟。由于钱包合约中的 gas 足够、calldata 正确、nonce 正确，因此每个模拟都成功。根据 gas 计算，这个 UserOperation 是有利可图的。因此，他们分别在链上提交了交易。

接下来，由于 EVM 按线性方式处理交易，因此这两个交易必然有顺序，其中一个交易在另一个交易之前被处理。当第一个交易完成时，EVM 在处理第二个交易时发现 UserOperation 的 nonce 不正确，因此第二个交易被回滚。因此，两个 Bundler 得到了完全不同的结果。如上表所示，第一个 Bundler 获得了 0.00028 $Matic，而第二个 Bundler 损失了 0.0000728 $Matic。下面的图表显示了工作流程。

图 1. 两个 bundlers 同时处理相同 UserOperation 的流程图

这仅仅是一个 UserOperation 的失败交易（一个 bundle）造成的 gas 损失。如果交易包含更多 UserOperation 呢？这是另一个测试的结果。按照之前测试的相同步骤进行，不同的是每个 bundler 发送的交易包含两个 UserOperations，而不是一个。 (交易 1; 交易 2)。Bundler A 的第一个 UserOperation 和 Bundler B 的第一个完全相同。具体而言，只要它们具有相同的发送者和 nonce，就会出现问题。我们发现整个交易失败，导致这个 bundler 无缘无故地支付了所有的 gas。与单个 UserOperation 的交易相比，gas 增加了 5408，并且同一交易中的其他可执行 UserOperation 也没有在链上执行。因此，这笔交易不仅对 bundler 造成了更大的经济损失，还给另一个用户造成了时间损失。

表 2. 两个 bundlers 发送包含两个 UserOperations（其中一个相同）的交易

在这里，calldata 是相同的且相当简单。如果这些 UserOperations 更复杂，涉及更多交互合约或自身内容更多，那么 gas 损失将会更高。另一方面，想象一下，当 AA 变得更加流行时，Bundlers 将会将更多的 UserOperations 打包在一起。如果发生回滚，gas 损失将会更大。下表显示了包含一个重复 UserOperation 的失败交易的 gas 以及 UserOperations 数量的增加，calldata 与上述测试相同。

表 3. 包含一个重复 UserOperation 的失败交易的 gas

黑暗森林或开放田野

除了故意测试或攻击者向多个 Bundler 发送交易外，上述情况在链上偶尔会发生。原因在于相当数量的 Bundler 将 Bundle 交易发送到以太坊 mempool，而没有 MEV 保护。当 UserOperation 是明文时，当 MEV 机器人在以太坊 mempool 中发现一个有利可图的 UserOperation 时，它将直接打包该 UserOperation，提交一个新的 Bundle 交易到同一块，但 gas 价格更高。出块节点自然优先处理 gas 价格更高的交易，使原始交易的发送者成为 nonce 碰撞的受害者。在这个过程中，MEV 机器人不仅提高了 gas 价格，而且最终消耗了更多的 gas，因为它们拥有自己的 MEV 机器人合约，增加了提交交易的竞争复杂性。这些在以太坊 mempool 中的 Bundle 交易就像在黑暗森林中举着火把的人，使自己成为掠食者的猎物。

无论是攻击者有意还是 MEV 机器人进行抢跑，在 ERC4337 之前的公共 mempool 中，这种情况可以认为是 UserOperation nonce 碰撞攻击。这种情况必须被防止。在这里，我们提出了一些在没有公共 mempool 时的临时解决方案。

公共 Mempool 之前

对于更直接的方法，Bundlers 可以在回滚发生后，主动阻止 UserOperation 的发送者或 IP 地址。然而，这种方法有两个问题。首先，禁止 IP 地址可能导致误报，攻击者可以更改其发送者和 IP 地址。其次，用户可能无意中采取了此行为。

关于 MEV 机器人，一个解决方案是使用对抗抢跑的 MEV 保护，如 Flashbots，但这无疑会产生一些成本或牺牲一些效率。另一个解决方案是计算提交的 Bundle 交易的 gas 与在提交 Bundle 交易时从 EntryPoint 合约返回的 gas 之间的差异，将其保持在一个低的有利可图水平，使 MEV 机器人抢跑交易没有利润。这应该是在 AA 早期采用阶段最简单直接的解决方案，因为目前大多数 Bundle 交易只包含一个 UserOperation，并且一个区块内的 AA 交易较少。

我们可以想到的另一个解决方案是向打包过程引入一些随机性。Bundler 可以在模拟和打包接收到的 UserOperation 之前，随机等待一个块（例如，0 到 5 个块之间）。这使得攻击的有效性大大降低，因为攻击者无法保证 Bundler 会在同一块中打包 UserOperation。攻击的成本随着随机数范围的增加而增加。这个解决方案在高速链上比较可行，如 Arbitrum，区块时间相对较短。然而，在低速链如以太坊上，每个区块需时 12 秒，用户体验可能不会很好。

上述解决方案是在公共 mempool 可用之前的临时方案。一旦有了公共 mempool，情况将会有所变化。

公共 Mempool 之后

在公共 mempool 被引入后，来自这个池的 UserOperations 将会增多。必须有一个机制来防止多个 Bundler 在 mempool 中打包相同的 UserOperation。开发 Skandha bundler 客户端的 Etherspot 正在开发 mempool 的 p2p 网络。根据 Etherspot 的信息，mempool 将在十月可用。需要打包的 UserOperations 将通过这个 p2p 网络传输，一旦打包并在链上处理，它们将被标记并下架。向 mempool 发送重复的 UserOperations 将毫无意义，因为可以很容易地通过 p2p 网络检测到。

此时，多个 Bundler 将访问同一组未处理的 UserOperations。Bundlers 将开始将更多的 UserOperations 打包到同一个 Bundle 交易中。如果交易仍被发送到以太坊 mempool，只要有一个 UserOperation 被抢跑，整个交易将会回滚。失败的概率显著增加。这对Bundler 社区和 AA 生态系统都是有害的。

正如来自 Etherspot 的核心开发者 Parthasarathy 所评论的，p2p 接口将在支持 mev-boost/区块构建者的链上进行试点。这将确保消除重复提交并减少在线拒绝。来自 Candide 团队的 Marc 也告诉我们，与区块构建者的合作是设计上的，而不是可选的，任何人都无法，也不应该在没有如 mevboost 的公共 mempool 上运行一个 bundler。

在理想的状态下，公共 mempool 启动后，Bundlers 将避免陷入黑暗森林混乱竞争的状态。通过结合他们的私有 mempool，Bundlers 可以更高效地处理 UserOperations，同时赚取最大的利润。

我们相信，AA 的发展必将经历一个发现和解决问题的过程，而我们在这里讨论的只是其中之一。经过这些发展，AA 最终会被广泛采用。作为创新的 web3 基础设施，我们将继续在 AA 领域进行更多研究和测试，希望更多的开发者能参与到我们的 AA 社区中。

• 原文链接： medium.com/blockpi/aa-us...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～