💣Order Bombing

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.

Figure 2: Worst case Order Bomb attack on a pool with OBI=1 and inactivity between attack concluding transaction, LT Swap n, and target transaction.

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, affecting 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, and 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.

Figure 3: Worst case two-sided Order Bomb attack on a pool with OBI=1 and inactivity between attack concluding transaction, LT Swap n, and target transaction.

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 executing 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 the 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.

Figure 4: Test scenario generator documentation showing event timeline for attack scenario testing. Note that after deploying and funding the pool, non-attack LT Swaps are issued, followed by attack LT swaps, simulating market activity to attract arbitrage. The attack delay determines when the attacking LT swaps expire. After the attacking swaps expire, a call to execute virtual orders is made.

The result of running the generated tests on a pool with OBI=1, for 10 attacks expiring 15 block intervals from the 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.

Table 1: Measured gas for control, one-sided and two-sided Order Bomb attack scenarios.

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 iterations 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 the 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].

Figure 5: Accounting for the increase in gas usage at iteration 07 for one-sided attack gas measurements using SSTORE documentation from [6].

For a two-sided attack, both order pools’ 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 result 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 comparisons and measurements appear in Figure 6.

Figure 6: Measured gas use for the control and two-sided Order Bomb attack scenarios for a pool with OBI=1 suffering 185 two-sided LT swap attacks with a 193 block inactivity period. The 21970 additional gas used to execute virtual orders in the attacked pool is insufficient to push the total gas use beyond the nominal Ethereum block limit of 15M.

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 is 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.

References

1. “Time Weighted Average Market Maker Operational Parameters vs. Gas Usage Analysis”, March 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4.

2. TWAMM (2021). Online. Available: https://github.com/FrankieIsLost/TWAMM.

3. Paradigm, “TWAMM”, May 20, 2021, Online. Available: https://www.paradigm.xyz/2021/07/twamm.

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.

5. “TWAMM Algorithm Optimization & Approximation Analysis“, April 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4.

6. EVM Codes, “An interactive reference to Ethereum Virtual Machine Opcodes”, Online. Available https://www.evm.codes.