đ¤Inactivity
Last updated
Last updated
To visualize the gas used by different amounts of inactivity for a range of OBI values, the same procedure that generated figures 2.0 and 4.0 was replicated. However, OBI was set to fixed values of 1, 10, 30, and 60 while inactivity was swept from 0 to 200 in 10 block steps. Figure 5.0 below shows the results of these measurements:
The gas units depicted in the vertical axis of figure 5.0 are logarithmically scaledâitâs important to note this and the approximately linear growth of gas used as a function of inactivity (there is some deviation from linearity for large OBI values due to the floor and mod operations present in equation 1, but for smaller OBI values this appears to be less of an issue).
Figure 5.0 shows that for the LT-swap scenario in this experiment, 200 blocks of inactivity is near the maximum nominal Ethereum block target gas when OBI is 1, at 15,010,686 gas units. Figure 5.0 again illustrates the significant advantage of larger OBI values, 10 and beyond, in reducing gas usage for the inactivity of a TWAMM pool with concurrent opposing direction LT-swaps.
For a specific OBI value and the constraints of the Ethereum blockchainâs target and maximum gas per block, it is important to understand the maximum permissible inactivity before a TWAMM transaction cannot be completed.
Consider the case where OBI is 10, gas usage for the experiment described in the previous section is plotted in figure 6.0 below:
Figure 6.0 Gas usage vs. inactivity measured in blocks for concurrent opposing active LT-swaps in a TWAMM pool with order block intervals 10. Inactivity is swept from 0 to 200 blocks in steps of 10 blocks.
Using the formula for a line, itâs possible to extrapolate and compute an approximate maximum inactivity for a nominal target of 15M gas units and a maximum of 30m gas units:
Assuming an approximate Ethereum average block time of 14s, the maximum inactivity time for a pool with OBI 10 and two concurrent opposite direction LT-swaps is 7.7 and 15.6 hours for the 15 million and 30 million gas limits, respectively.
The 15 and 30 million gas usage bounds represent an upper limit and are impractical for a contract deployed on mainnet that is expected to be used by consumers in addition to institutional customers.
A more practical study would present inactivity as a function of multiples of the average gas used per Uniswap V2 swap transaction. Recent Crypto.com data [6] suggest this average is 154,919 gas units. Using the same pool with an OBI of 10, the delay in time assuming 14s block time for multiples of 154,919 gas appears below in Figure 7.0:
Figure 7.0 shows that a minimum of 3 average network transactions, 464757 gas, is required for TWAMM to be inactive for about 10 minutes. To get to almost 20 minutes of inactivity, the gas of 5 average UNI V2 swap transactions would be required. This suggests that without low-level solidity optimizations, the TWAMM contract under test, derived from [2] is not competitive with existing CPAMMs for consumer trades (i.e. simple swaps of small amounts) because of the larger gas costs. A combination of intelligent operating parameter selection and low-level solidity optimizations can potentially address this problem.
Idle can be defined as the scenario when there are no active LT-Swaps in any directionâthis is scenario 1 from figure 3.0. Replicating the measurements from the procedure used to create figure 5.0, but in the absence of any active transactions yields the following results for gas usage at idle, swept for inactivity from 0 to 200 blocks:
Comparing the data of figures 5.0 and 8.0 shows that gas use is significantly reduced at idle, however, it is important to note that there will still be a maximum inactivity duration when a pool is at idle, albeit markedly more than for the worst-case gas usage of opposing direction LT-swaps.
What happens if a pool is inactive for so long that the gas required to execute virtual orders exceeds that provided in an Ethereum block?
For the TWAMM contract in [2], nothing can be done (as of 3/9/2022). However, a simple contract modification is possible that allows a contract user to execute virtual orders up to a specified block. By specifying the block up to which virtual orders are executed, the user can manually limit the number of iterations that are computed, and thus limit the gas used by the call.
Itâs conceivable that such a long period of inactivity has occurred that multiple block limited execute virtual order calls are required before the pool is useable.
TWAMM (2021). Online. Available: github.com/FrankieIsLost/TWAMM.
Crypto.com, âDEFI DASHBOARD Gas Feesâ, Online. Available: crypto.com/defi/dashboard/gas-fees.