这是关于异步执行的入门介绍：我们是如何在Monad中实现它的，为什么EIP-7702破坏了它，以及如何修复它。 为了提供背景，异步执行自从共识和执行客户端相互连接以来就已经在Monad中存在。 异步执行允许执行在交互的角度上滞后于共识固定数量的区块。 大多数区块链都有交错的共识。也就是说，执行发生在共识之前，这意味着将执行压缩到一个小于区块时间的时间预算中（其余时间被环绕世界的消息传递占用，即共识）。这本质上限制了系统的每秒燃气量。 L2通过完全不进行共识来规避这个问题。但我们希望拥有一个分布式、去中心化的L1，其性能保持高效。 异步执行让我们通过将执行移出共识的热路径来规避这个问题。相反，共识和执行在并行的泳道中进行。共识在区块2上进行，而区块1的执行则在并行运行。 不过，共识和执行之间仍然需要达成一致。具体来说，这种一致性是：执行只能滞后于共识最多k个区块，因为区块提案包含一个延迟的默克尔根。此外，共识是在对状态的延迟视图（延迟k个区块）下构建区块的。这意味着存在一个风险，即共识将包括一个发送者的交易，而在我们执行时，发送者的余额可能已经为空。 如果协议允许这种情况发生，那将是非常糟糕的，因为这将打开一个拒绝服务（DOS）向量。因此，为了解决这个问题并安全地启用异步执行，Monad共识客户端计算每个交易的最大MON借记为： MON_spent = gas_bid * gas_limit + value。 共识客户端在扣除每个发送者发送的交易的MON_spent后，保持一个可用账户余额的运行列表。 基于这个运行余额，共识客户端仅在能够确保交易可以支付的情况下才包括交易。 这是一种悲观的区块构建方法，因为它没有考虑任何账户因转账而增加余额的可能性。 让我用一个例子来解释我的意思。 假设Alice的账户有100 MON。然后，以下3个交易被包含在区块1000中： Tx 1：Alice向Bob发送20 MON，费用为1 MON Tx 2：Alice花费70 MON购买一个memecoin，费用为1 MON...