效率

由于 TWAMM 是为在以太坊上使用而设计的，因此为每个区块的多个虚拟交易明确计算交易的成本会高得惊人。然而，当我们有无限多的无穷小交易时，我们可以在一次计算中为交易者计算结果，无论自上次检查以来已经过去了多少个区块。

实施方案

惰性求值

TWAMM 将虚拟子订单视为发生在区块之间的空间中，这对于避免三明治攻击很重要。

要想以一种节省 gas 的方式实现这一点，TWAMM 使用惰性求值，仅在需要确定交互结果时才计算虚拟交易的影响。

每次用户与 TWAMM 交互时（例如，通过使用嵌入式 AMM 进行交易或添加新的长期订单），TWAMM 都会追溯计算自上次交互以来所发生所有虚拟交易的影响。

由于这些虚拟交易仅与 TWAMM 的嵌入式 AMM 交互，因此 TWAMM 的行为在外部交互之间是完全确定的。即使 TWAMM 在两次外部交互之间间隔了 100 万个区块，下次有人与之交互时，它也能够准确计算所有介入虚拟交易的结果。

插入 TWAMM 的前端将能够通过跟踪当前区块编号，并自行进行 TWAMM 计算，来处理尚未在链上显示的虚拟交易。

Gas 优化

订单池

如示例所示，当我们在同一交易方向有多个长期订单（例如，出售 ETH 换取 USDC）时，我们将它们汇集在一起，然后将它们拆分为虚拟订单。然后 TWAMM 可以使用用于跟踪 Compound 和 Uniswap 等协议中 LP 奖励波动的「十亿美元算法」，以跟踪账户余额。

从技术上讲，每个 TWAMM 总是有两个长期订单池，每个资产一个：例如，卖 出 USDC 的池和卖出 ETH 的池。在任何给定时间，这些池中的一个或两个都有可能是空的。

长期订单到期

将订单池与惰性求值结合使用时，会出现一种复杂情况。

想象一下，Bob 下订单在接下来的 100 个区块中出售 100 ETH，而 Charlie 下订单在接下来的 200 个区块中出售 200 ETH。两个订单都以每个区块 1 ETH 的速度卖出。

假设在接下来的 150 个块中没有人与 TWAMM 交互，此时会发生新的外部交互。在 Bob 和 Charlie 下订单后的前 100 个区块中，他们的订单汇集到一个共同订单中，每个区块出售 2 ETH。 然而对于之后的 50 个区块， Charlie 的订单是独立的，每个区块只出售 1 个 ETH。

这意味着我们必须进行两次单独的交易计算，才能发现发生了什么：一次计算前 100 个区块的结果，一次计算最后 50 个区块的结果。在最坏的情况下，如果过去 150 个区块中每个区块都有订单到期，这意味着 TWAMM 将不得不每个区块处理一笔交易，原本期待的节省 gas 的效率将大打折扣。 (责任编辑：admin)