同时，我们设置每个 Rollup 批次最多可包含的交易数量是 TXS_PER_BATCH。Alice 可以自己检查，Rollup A 即将到来的批处理之前有多少未处理交易，用她在 IVAN_B 合约中看到的资金减去这个值，并检查剩余的金额是否足够。由于提币是按顺序处理的 (这是上面顺序机制的目标)，Alice 不需要担心在她自己提币之前 IVAN_B 会去处理后面的提币需求。

在一个批次中可以交易的最大金额是 TRADE_LIMIT * TXS_PER_BATCH，因此 IVAN_B 合约需要至少持有这个数量的 ETH，再加上足够的资金来覆盖未处理的交易。

例如，假设 TRADE_LIMIT = 0.1 ETH （上限可以设得比较低，因为一笔较高金额的交易可以通过多笔交易完成)，并且 TXS_PER_BATCH = 1000。那么，IVAN_B 需要有 100 ETH 的资金。

注意，在这个设计中还有额外的隐含费用，因为任何交易超过 0.1 枚 ETH 的人都需要消耗区块空间，这与资金要求相权衡：如果你消耗掉一半的区块空间，那么你的资金要求也会翻倍（可能指隐含费用更高），反之亦然。要建立合适的平衡，似乎应该让隐含费用比市场上出现的显性费用少几倍。

如果我们想减少或消除这种消耗，Rollup A 可以被设计成这样，例如，让排序器发送一个签名消息，向 Alice 证明到目前为止，批次中批准的所有消息。然后 Alice 就会知道在她之前没有交易 (尽管恶意的排序器可以欺骗 Alice，但代价很高)。

备注

上面的设计建立在 Rollup A 上的交易有一个备注字段的假设上，Alice 可以使用该字段指定 ALICE_B 作为她接收代币的目的地址。如果 Rollup 没有此特性，那么我们可以使用以下解决方案。

Alice 可以在顺序注册合约的 Rollup B 上注册 ALICE_B，并获得一个按顺序分配的 ID(因此 Alice 的 ID 等于在她之前注册的用户数量)。设置 MAX_USER_COUNT 为用户数的最大值，如果有必要，这个值可以随时间向上调整。Alice 可以简单地确保 TRADE_VALUE % MAX_USER_COUNT 等于 (Alice 的 ID)，使用 TRADE_VALUE 的低阶位 (这个数字表示一个不重要的值) 来表示她想交易的代币数量。

从 Rollup B 到 Rollup A 的交易

如果 Alice 把 Rollup B 上的代币转移到 Rollup A，可以使用类似的机制，只是角色颠倒了：

• Alice 将代币发送给 IVAN_B

• 经过一段时间的延迟，她将获得收回代币的权利

• 如果 Ivan 可以向 IVAN_B 证明，他在 Rollup A 上给 Alice 发送了代币，Alice 就失去了这个权利

总结

所以我们可以看到，在这个过程中，许许多多的「Ivan」其实就是去中心化的银行，在两条 Rollup 上分别扮演存款机和取款机的角色，从而赚取手续费。

如果 Ivan 作恶，Rollup A 和 RollupB 间不需要进行过多的交互，Alice 就可以提供打币证明。根据 Vitalik 的表述，在从 Rollup A 向 Rollup B 转账的场景中，提供证明这一步操作可以直接在 Rollup B 上进行，只要 Rollup B 能获取 Rollup A 的区块哈希，就可以计算出 Rollup A 上的交易记录，从而向 Ivan 索赔。 (责任编辑：admin)