在我们之前的文章中，我们提到了账户抽象生态系统中目前存在着一些待解决的问题，其一就是Bundler处理UserOperations的风险问题。具体来讲，是如果用户同时向两个Bundler发送具有相同nonce的UserOperation，而这两个Bundler将交易提交到同一个区块中，那么其中一个交易将会失败。在这种情况下，交易失败的Bundler也要支付少量的gas费用，但却无法从EntryPoint合约拿到gas，由此而发生亏损。这个我们称之为nonce碰撞。就算不是测试行为，这种情况在链上也一直在发生。

在ERC-4337的官方文档中，可以找到对Bundler的定义。其中提到Bundler自己应该就是block builder，或者就要与block builder合作。理论上讲与block builder合作的Bundler可以完全避免因nonce碰撞发生交易失败。但是我们发现现实情况是很多Bundler都是独立在运行，并且没有被MEV保护。

在本文中，我将详细讨论这个问题以及Bundler生态现状，并且对公共mempool出现以及未来AA被广泛采用后的生态做一些展望。

交易发生失败的具体过程

为了更好地说明这个问题，我们在Polygon Mumbai上进行了测试，以下为测试步骤：

1. 准备一个已经部署好的合约钱包，即准备一个sender。

2. 存入足以支付多个UserOperations gas费的资金, 避免发生gas不足的错误影响测试。

3. 构建一个包含简短calldata的UserOperation，不设置Paymaster和Aggregator。

4. 同时向两个独立运作的Bundler发送这个具有相同nonce的UserOperation。在EntryPoint合约历史记录中查看这两个Bundler发送的交易记录。

下表列出了这两笔交易的一些细节。(Transaction 1; Transaction 2)

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

两个Bundler在接收到UserOperation后，每个Bundler根据当前的区块链状态进行了交易模拟验证。由于钱包合约中有足够的gas，calldata也没有问题，nonce也正确，所以每个Bundler的验证都是成功的。根据计算gas，打包这笔UserOperation是有利可图的。因此，他们分别在链上提交了一笔交易。这笔交易包含了这个UserOperation。

接下来，由于EVM按照线性方式处理交易，所以这两个交易会有先后顺序，先处理一笔交易再处理另一笔交易。当第一笔交易完成后，EVM在处理第二笔交易时发现UserOperation的nonce不正确，因此第二个交易被revert了。于是，这两个Bundler发送同一笔UserOpeations得到了不同的结果。如上表所示，第一个Bundler赚取了0.00028 Matic，而第二个Bundler损失了0.0000728 Matic。下图展现了两笔交易的流程。

图 1. 两个Bundler同时处理同一个UserOperation的流程图

这只是包含一个UserOperation的交易（一个bundle）的gas损失。如果一笔交易包含更多的UserOperations呢？以下是另一组测试结果。每个Bundler发送了一个包含两个UserOperation的交易。Bundler A的第一个UserOperation与Bundler B的第一个UserOperation是相同的。更准确的说，只要被发送的UerOperations具有相同的发送者和nonce，上述冲突就会发生。测试后我们发现整个交易失败了，导致Bundler白白支付了gas。与只有一个UserOperation的交易相比，gas数额增加了5408，同一交易中的其他UserOperation也没有在链上执行。因此，这个打包了多笔UserOprations的交易不仅给Bundler造成了更多的经济损失，还给另一个用户带来了时间上的损失。

表 2. 两个bundler发送包含两个UserOperations的交易，其中有一个UserOperation相同

在以上测试中，calldata是相同的，也比较简单。如果这些UserOperation更复杂，涉及更多的合约交互或本身包含更多的内容，那么gas损失将会更高。另一方面，想象一下，当AA变得更普及时，Bundler会将更多的UserOperation捆绑在一起。如果发生revert，gas损失也将会更高。下表列出了包含一个有冲突的UserOperation的失败交易的gas，损失的gas随着包含的UserOperation的数量增加而增加。

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

黑暗森林

由于有相当一部分Bundler在没有MEV保护的情况下把Bundle交易发送到了以太坊mempool，所以除了测试或者进行攻击，一笔UserOperation被发给多个Bundler的情况依旧在链上不时发生。。原因是有相当一部分Bundler在没有MEV保护的情况下把Bundle交易发送到了以太坊mempool。又因为UserOperation是明文的，MEV机器人在以太坊mempool发现有利可图的Bundle之后，就会直接打包该Bundle里面的UserOperation，用更高的gas价格在同一区块提交交易。出块节点自然是先打包gas价格高的交易，于是包含该UserOperation的bundle会整个revert，而原先发送交易的bundler就成为了nonce碰撞的受害者。这个过程中，MEV机器人不仅为了抢跑而提高了gas价格，也由于他们有自己的合约，抢跑的交易消耗资源更多，最终消耗的gas数量也就要多一些。这些在以太坊mempool里面的Bundle交易，就像在黑暗森林中亮着的火把，成为他人攻击的目标。

无论是有攻击者故意为之还是有MEV机器人抢跑，在ERC4337的mempool出现之前，上述情况都可以被认为是一种UserOperation nonce碰撞攻击。我们必须要有一些防范措施。下面是一些临时的解决方案。

公共Mempool之前

对于从用户端发起攻击的攻击者，Bundler可以在revert发生后主动禁用该笔UserOperation的sender或IP地址。然而，这种方法会存在两个问题。首先，禁止IP地址可能会导致误伤其他用户，另外攻击者也可以更改其发送者和IP地址。其次，用户可能只是无意地重复提交了UserOperation。当然，Bundler使用像Flashbot这样的防抢跑的MEV保护可以完全避免nonce碰撞导致的交易失败，但是这需要付出一些成本或者是牺牲一些效率。

对于抢跑攻击，一是使用像Flashbot这样的防抢跑的MEV保护，同样需要付出成本或者牺牲效率。二是在提交Bundle交易的时候计算好提交的交易gas与UserOperation返还的gas差额，保持在一个微盈利的水平，使MEV机器人抢跑交易无利可图。这个在AA采用早期应该是最简单直接的解决方案，因为现阶段大部分一个Bundle交易只包含一个UserOperation，并且一个区块中包含的AA交易也很少。事实上我们发现现在的生态情况就是这样的，即使没有MEV保护，许多交易都没有被抢跑。

上述解决方案是在AA大规模采用之前的临时解决方案。在公共mempool开始运行并且每个区块都有一定数量的UserOperation之后，情况就不一样了。

公共Mempool之后

ERC4337的公共mempool推出后，大多数UserOperations都来自于该mempool。必须有一种机制防止多个Bundler在mempool中捆绑同一个UserOperation。开发了Skandha bundler客户端的Etherspot正在开发mempool的p2p网络。根据Etherspot提供的信息，mempool有望在10月份推出。等待打包的UserOperations将在这个p2p网络中传输，一旦捆绑并在链上处理，它们将被标记并从列表中删除。这时，攻击者发送重复的UserOperation到多个Bundlers是无意义的，因为Bundler连接的公共mempool网络可以轻松地检测并排除掉重复的UserOperation。

此时，多个Bundler仍将能够访问同一组未确认的UserOperations。此时，bundler已经开始将更多的UserOperations打包到同一交易中。如果还是将交易发到以太坊mempool里面，只要有一笔UserOperation被抢跑，整个交易就失败了。一次失败的概率大大提高。这对Bundler社区和AA生态系统都是有害的。

所以根据Etherspot的核心开发者Parthasarathy对此进行的评论，mempool 的p2p网络将在支持mev-boost/block builders的区块链上进行试点。这将确保不发生UserOperation nonce碰撞。Candide团队的Marc也告诉我们，Bundler社区与block builders合作是必需的，Bundler不应该在没有像mevboost这样的服务的情况下直接在mempool p2p网络上运行。这就对这条链的MEV保护的覆盖率提出了要求。

理想状态下，public mempool上线后的bundler将会避免走入黑暗森林中混乱的竞争状态。并且通过结合自己的私有mempool，Bundler可以更高效地处理UserOperations，同时赚取最大利润。

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