Introduction

A theoretical attack on Time-Weighted Average Market Maker (TWAMM) pools is introduced and empirically shown to be of negligible concern to arbitrageurs herein. The effect is mitigated further in practice by the practical settings of a TWAMM pool’s order interval, be it block or time based, collating order expiries at fixed intervals for increased gas efficiencies. Additionally, it is shown that in implementation, the attack is largely circumvented by the Ethereum Virtual Machine’s accounting of gas use for SSTORE operations related to the attack.

A brief discussion on block and time based TWAMM order intervals is also featured. Not only is the size of the order interval important for TWAMM pools as shown in [1], but the implementation dimension of the interval, time or blocks, is shown to have an important consequence in the event of an Ethereum blockchain outage, where arbitrage is impossible.

“No Soup for You!” - Service Denial

During a discussion about problematic scenarios for TWAMM, the issue of Gas Denial of Service (GDoS) was raised. The GDoS vulnerability arises from the virtual order execution loop, shown in Figure 1 as implemented in the TWAMM reference design [2].

Given enough iterations of the circled loop in Figure 1, it’s possible there will be insufficient gas in a transaction block to execute the function. This would break most TWAMM public functions for users, denying service. The number of iterations is determined by the block the function was previously executed, the current block the function is being executed, and the Order Block Interval (OBI) value.

This problem and its relationship to Order Block Interval (OBI) is discussed extensively in [1]. A mitigation for the problem is also presented in [1], whereby a maximum block can be specified to limit loop iterations to within gas constraints. While the mitigation alleviates the problem-- it introduces additional gas use, complexity, and inconvenience.

Order Bombing

A part of the discussion alluded to earlier regarding problematic scenarios for TWAMM, raised concerns about causing a GDoS with strategically issued Long-Term (LT) swaps with expiries amplifying the iteration cost of the virtual order execution loop in Figure 1. This type of attack can more colorfully be referred to as Order Bombing.

Order Bombing isn’t a threat to TWAMM pools with lots of activity or volatility attracting arbitrageurs--more attractive than the gas for virtual order execution. The worst scenario for Order Bombing would likely be when a TWAMM pool is both inactive for long durations and is low-volatility. Note that the resulting effect of Order Bombing--increased gas use handling expiring virtual orders-- could also occur organically in inactive low-volatility pools, where many LT orders coincidently expire within a region of inactivity.

The original Paradigm TWAMM article [3] suggests order pooling, as per the Billion Dollar Algorithm [4], and what amounts to OBI in the following block quote--both of which dramatically reduce the gas impact of Order Bombing:

The simplest workaround for this is to limit the number of blocks eligible for order expiry: for example, the TWAMM could specify that orders are only eligible to expire every 250 blocks, or roughly once per hour. [3]

Figure 2 below depicts a deliberate Order Bombing attack with strategically placed consecutive LT swaps of contiguous expiries to effect a GDoS. The pool in this attack has the worst case configuration, a gas inefficient pool with OBI=1.

Importantly, LT Swap 1 and LT Swap 1.1 in Figure 2 do not add an additional gas load upon the target because of their shared expiry and aggregated sales rate. Restated, the gas load to the target would be roughly the same if LT Swap 1.1 is not present, due to the Billion Dollar Algorithm’s efficient order pooling. Consult Table 2 in Appendix A for measurements showing this efficiency.

On inspection, it might appear that handling an expiry of each whole numbered LT Swap pictured in Figure 1 would result in increased gas load, effecting a GDoS pool failure at some future point indicated by the target in the figure. The mitigation presented in [1] can resolve this situation. However, the more pressing problem is that the additional gas load may be sufficient to dissuade an arbitrageur from correcting resulting virtual trade price movements, nullifying TWAMM’s slippage reduction benefit.

Quantifying an Order Bombing Attack

The attack effectiveness is expected to be greater for low activity, low volatility pools, but depends heavily on the TWAMM implementation. To quantify the effect of the attack illustrated in Figure 2, the isolating gas methodology described in [5] can be installed into the reference TWAMM contract [2], to provide accurate isolated attack gas measurements. Gas use logging was added to the function executeVirtualOrdersUntilCurrentBlock; the functions executeVirtualTradesAndOrderExpiries and updateStateFromBlockExpiry were modified to pass data back for logging purposes.

Measuring One-Sided & Two-Sided Order Bomb Attacks

With isolating gas measurement instrumentation in the contract, an extensible test scenario generator replicating the transactions depicted in Figure 2 was constructed. The scenario generator introduced the ability to perform two-sided Order Bombs--an attack where trades from both sides of the pool are performed as shown in Figure 3.

The test scenario generator is parametrizable permitting two-sided, one-sided and control scenarios; a control scenario is identical to the one or two-sided scenarios but without attack LT swaps. The control permits measurement against a baseline to determine the severity of the impact of an Order Bomb attack. The documentation for the test is illustrated below in Figure 4. The safety is a small number of additional blocks to mine before execute virtual orders is called, ensuring attack order expirations have occurred. Note that the swap amounts of the attack LT swaps are small, but differ from each other slightly to impart maximum gas use in execution of virtual orders (maximizing dynamic gas use related to SSTORE). The duplicate attack, LT Swap 1.1, shown in Figure 1, is can be optionally removed in the test scenario generator. The duplicate attack has been removed in subsequent tests--consult Appendix A for a comparison of this feature enabled and disabled for a one-sided Order Bomb attack.

The result of running the generated tests on a pool with OBI=1, for 10 attacks expiring 15 block intervals from issue is shown in Table 1 for control, one-sided and two-sided attack scenarios. Table 1 shows each iteration of the test’s final call to execute virtual orders along with the simulation block number and isolated gas measured for the iteration. Additionally, the change to each order pool’s sales rate is also shown. A change greater than zero implies one or more LT swap order expiries.

The increased gas use over the control scenario in both one and two-sided attack scenarios measured in Table 1 is insignificant (+0.287% and +0.490% gas, respectively). The most significant impact occurs at iteration 07, where 2840 and 5650 additional gas is measured from the attacks. The remainder of the measured gas increase in both attack scenarios appears to be a trivial amount, likely due to arithmetic computation and SSTORE dynamic gas.

Analyzing Gas Increases From Order Bomb Attacks

The additional gas at iteration 07, 2840 and 5650 for one and two-sided attacks, respectively, is caused by changes to the order pool’s sales rate that are stored on chain. Prior to iteration 07, the pool’s sales rate change is zero. During iteration 07 it is non-zero, resulting in gas use from SSTORE. The SSTORE gas difference for the one-sided attack is 2900 (offset by slight differences in the control run, resulting in a net difference of 2840); Figure 5 below shows a rough accounting of the increased gas use with SSTORE documentation from [6].

For a two-sided attack, both order pool’s sales rates are changing the value on chain, thus the approximate gas increase is twice that shown in Figure 5, 2 x 2900 = 5800. Slight differences in gas use in the control scenario results in a net difference of 5650 for the two-sided attack, slightly less than the 5800 related to SSTORE in isolation.

Examining Order Bomb Gas Increases to Service Denial

Though gas use increase from an Order Bomb attack was shown to be negligible in the previous section, it is possible to quantify the reduction in maximum inactivity resulting from an attack experimentally. From trial and error and extrapolation, it was found that 193 blocks of inactivity brought total gas use to execute virtual orders near the nominal Ethereum block limit of 15M gas. Configuring a two-sided order bomb attack to issue 185 attacks with an attack delay of 190 blocks (resulting in 193 blocks of inactivity) shows that the attack does not even reduce the maximum inactivity by a single block, increasing the arbitrage margin by only 21970 gas. Optimized TWAMM contracts will likely see even less of an impediment to arbitrage. These comparison and measurements appear in Figure 6.

Regardless of how the Order Bomb attack might be restructured, for instance interleaving attacks with empty blocks etc., the nature of SSTORE gas charges to a contract are such that this attack will prove ineffective and is no more of a concern than inactivity for a pool based on the negligible gas increases shown herein.

The Living Dead

Can LT Swaps stay active when the Ethereum blockchain network is dead?

The reference design in [2] expresses order intervals in blocks referred to as Order Block Interval (OBI). The FRAX TWAMM implementation [7] significantly differs, expressing order intervals in time, specifically fixed 3600 second (1 hour) intervals.

Order Time Interval (OTI)

Block based and time based intervals result in different TWAMM operation, regardless of whether or not the interval is fixed or configurable. One of the most important differences is how an LT Trade will behave in the event of a blockchain outage for the two different interval types.

Network Outage: The Zombie Swap

If the Ethereum blockchain were to suffer a total network outage, LT swaps in a time-based interval TWAMM pool would continue to trade. This is because despite the Ethereum blockchain stopping, time would not stop. The underlying code of the FRAX contract [7] is shown in Figure 7, where the virtual order loop of Figure 1 has been modified to use timestamps instead of block numbers.

Upon network operation resuming, the first transaction issued to the TWAMM pool executing virtual orders would update all virtual trades for active virtual orders for the elapsed time interval since the start of the outage. For example in a 5 hour network outage, the FRAX TWAMM implementation would compute 5 intervals of virtual trade updates for active LT swaps when a transaction executing virtual orders is issued subsequent to the outage. This is illustrated in Figure 8, where block and time interval based pools are shown, each with an active LT swap and a 5-hour network outage.

The implication of the outage in the worst case is that the time-based pool LT swap would suffer increased slippage due to the inability of arbitrageurs to correct price shifts in the pool resulting from virtual trades continuing during a network outage. Slippage potential increases with the duration of the network outage. In practice, this would likely be inconsequential for pool assets only featured on the Ethereum blockchain--however this is not the case for assets on other blockchains or synthetic assets and derivatives (i.e. wrapped Bitcoin).

Conversely a pool using block based order intervals need not suffer this issue, depending on how the Ethereum blockchain resumes operation after an outage. If the blockchain starts at the next block number after the outage occurred, then no block intervals would have transpired. No block intervals transpiring means that no virtual trades will have occurred. Only if the block number is advanced multiple blocks after the block number of the blockchain outage would the behavior of the block based interval TWAMM pool mimic the time based interval pool in preventing arbitrage and continuing virtual trades.

Benefits of Time-Based Intervals

Beyond the intuitive nature of time based intervals, other benefits to adopting a time-based interval include:

• The TWAMM pool can participate across blockchains, where blocks differ in duration and elapsed time remains uniformly applicable.
• Tracking time is amenable to concentrated liquidity TWAMM implementations (see [8] for concentrated liquidity’s use of timestamps).
• Potentially reduced gas use. Choosing a 1 hour time interval equates to approximately 257 blocks and large block intervals were shown in [1] to increase contract gas efficiency.
  • The tradeoff is reduced resolution for order expiry and increased minimum LT swap duration.
• Other features requiring timestamps benefit from implementation and shared capture of moments in time, for instance the Time-Weighted Average Price (TWAP) oracle described in [8] that no longer requires sampling TWAP value and recording the associated sample time for later use.

Downside of Time-Based Intervals

Apart from the earlier discussion on the potential for increased slippage in the event of a network outage, increased contract complexity and possibly gas usage related to implementation details, any downsides to using time-based intervals in TWAMM pools are unknown at this juncture.

Conclusion

Comparative measurement for multiple scenarios of an Order Bomb attack were shown to be largely inconsequential for arbitrageurs of a TWAMM pool. Furthermore, an analysis of the mitigating mechanisms was presented and accounted for.

The effect of choosing not only the size of an order interval, but the dimension, time or blocks, was discussed. Time based intervals were explained to permit the continuation of virtual orders in an Ethereum network outage, where block based intervals do not. The result being potentially higher slippage for the LT swaps in a time-based interval TWAMM pool because of the inability to arbitrage the effect of the resulting virtual orders. In practice this would only effect pool assets not exclusive to the Ethereum block chain.

References

1. “Time Weighted Average Market Maker Operational Parameters vs. Gas Usage Analysis”, March 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4. Accessed: May 22, 2022.
2. TWAMM (2021). Online. Available: https://github.com/FrankieIsLost/TWAMM. Accessed: May 19, 2022.
3. Paradigm, “TWAMM”, May 20, 2021, Online. Available: https://www.paradigm.xyz/2021/07/twamm. Accessed April 14, 2022.
4. B. Batog, L. Boca, and N. Johnson, “Scalable Reward Distribution on the Ethereum Blockchain”, Online. Available: https://uploads-ssl.webflow.com/5ad71ffeb79acc67c8bcdaba/5ad8d1193a40977462982470_scalable-reward-distribution-paper.pdf. Accessed May 22, 2022.
5. “TWAMM Algorithm Optimization & Approximation Analysis“, April 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4. Accessed: May 22, 2022.
6. EVM Codes, “An interactive reference to Ethereum Virtual Machine Opcodes”, Online. Available https://www.evm.codes. Accessed May 22, 2022.
7. frax-solidity Uniswap_V2_TWAMM (2022). Online. Available: https://github.com/FraxFinance/frax-solidity/tree/master/src/hardhat/contracts/Uniswap_V2_TWAMM. Accessed: May 10, 2022.
8. H. Adams, N. Zinsmeister, M. Salem, R. Keefer and D. Robinson, “Uniswap v3 Core”, March 2021. Online. Available: https://uniswap.org/whitepaper-v3.pdf. Accessed: May 22, 2022.

Appendix A: Multiple Attacks With Same Expiry

Table 2 below shows the results with and without attack LT Swap 1.1 of Figure 2. As stated earlier, there is no significant increase in gas resulting from the additional LT Swap expiring at the same block as LT Swap 1. The measurements of Table 2 confirm this where a modest 20 gas increase at iteration 07 is shown for the One-Sided Shared Expiry Attack Scenario compared to the One-Sided Attack Scenario. An overall increase of 110 gas is observed between both scenarios for all iterations.