Simulation: Optimism with GasHawk

Introduction

Ethereum is a decentralized, open-source blockchain that enables the creation of smart contracts and decentralized applications (dApps). One of the key features of Ethereum is the ability to execute transactions on the network, which is facilitated through the use of a native cryptocurrency called Ether. In order to process transactions, Ethereum uses a mechanism called "gas," which is a unit of measurement that represents the amount of computational effort required to execute a particular operation on the network. Transactions on Ethereum are charged a fee in the form of gas, and the cost of executing a transaction is dependent on the current demand for gas on the network since EIP-1559.

As the Ethereum network has grown in popularity, the demand for gas has also increased, leading to higher fees for executing transactions. This has led to the development of various solutions designed to help users save on transaction fees, such as the use of layer-2 solutions or services that optimize the timing of transaction submission to the mempool.

One such service is GasHawk, which aims to help users save on transaction fees on the Ethereum mainnet by timing the submission of transactions to the mempool in such a way as to target a local minimum in fees. In this blog post, we will be discussing the findings of a simulation performed by the GasHawk team for the "Optimism" layer-2. This simulation was conducted in order to assess the potential for GasHawk to provide cost savings for the sequencer of Optimism, which is responsible for around 2% of the total gas used on the Ethereum mainnet. The scope of the simulation, the findings, and the conclusions will be discussed in more detail in the following sections.

Scope

The purpose of the simulation conducted by the GasHawk team was to evaluate the trade-offs between waiting time and savings for an Ethereum layer-2 "Optimism" sequencer using various GasHawk strategies with different deadlines. In order to conduct the simulation, the team gathered data on transactions from blocks 15585957 to 15617094, which corresponds to approximately 4 days 8 hours of activity on the Ethereum mainnet in late September 22’. This time frame was chosen because it was a period of relatively stable gas prices, allowing for a more accurate assessment of the potential cost savings provided by GasHawk. Note, that the average savings of GasHawk rise with increased volatility of Ethereum’s base fee.

The simulation included approximately 9800 transactions in total, all of which were sent from the ‘Optimism: Sequencer’ address 0x688…985 to the ‘Optimism: Canonical Transaction Chain’ address 0x5e4…dd2. The sequencer is a component of the Optimism L2 that is responsible for scheduling and executing transactions on the Ethereum mainnet.

In order to evaluate the trade-offs between waiting time and savings, the GasHawk team compared the actual cost incurred by the sequencer transactions to the cost that would have been incurred by the "perfect strategy." The perfect strategy refers to the hypothetical scenario in which a transaction is always submitted at the minimal cost within the given deadline. This allowed the team to assess the potential cost savings provided by GasHawk in comparison to the optimal scenario.

The GasHawk team evaluated the performance of the service using a number of different strategies, each with a different deadline for submission. The simulated deadlines included 5, 10, 15, 20, 25, and 30 minutes. These deadlines were chosen to represent a range of potential waiting times, allowing the team to assess the trade-offs between waiting time and cost savings across a range of scenarios.

In order to conduct the simulation, the GasHawk team made certain assumptions about the behavior of the Ethereum network. One such assumption was that transactions would be included 1 block after submission. The team also assumed that the sequencer transactions would be selected by validators based on certain criteria, such as the priorityFeesPerGas of the transaction being sufficient to maximize yield.

Findings

According to the results of the simulation, GasHawk has the potential to provide significant cost savings for Optimism. The team found that the sequencer using GasHawk was able to save approximately 13% of its costs with a median delay of the sequencer transactions of 10 minutes (compare fig. 1 and 2). This suggests that GasHawk has the potential to provide a meaningful reduction in the cost of executing transactions on the Ethereum network, particularly for the sequencer.

Fig. 1: Overall savings with varied deadline durations. Allowing a time window of 20 minutes results in approximately 13% less transaction costs.

Fig. 2: Distributions of simulated waiting times with varied deadlines.

The team also found that the longer the deadline for submission, the greater the potential for cost savings (and also their efficiency compared with the ‘perfect’ strategy, see fig. 3). This is because longer deadlines allow GasHawk to more effectively target local minima in fees, resulting in lower costs for users. However, it is important to note that longer deadlines also result in longer waiting times for transactions to be executed, which may not be desirable for all users (fig. 4).

Fig. 3: Comparison of GasHawk’s performance using varied deadlines with an imaginary ‘perfect’ strategy that could always submit the TX to the block with the cheapest base fee possible.

Fig. 4: Effective mean and median waiting times for transactions using varied deadlines. Using a deadline of 20 minutes results in a median waiting time of approx. 10 minutes (compare also fig. 2).

In addition to providing cost savings, the team also found that GasHawk had the potential to reduce the volatility of base fees on the Ethereum mainnet (see fig. 5). The team found that GasHawk transactions had a more narrow base fee distribution and a lower standard deviation (sigma) compared to transactions submitted without the use of GasHawk. This suggests that GasHawk has the potential to make fee pricing more predictable, which can be beneficial for users of the network.

Fig. 5: Base fee distribution of all simulated transactions with and without GasHawk.

It is important to note that there are some considerations that need to be taken into account when integrating GasHawk into an L2 solution. For example, GasHawk should never be the only publication route for transactions, and there should be a robust fail-over in place in case of any issues with the service. Additionally, GasHawk may work best when the maxFeePerGas is set to a relatively high value, as this allows transactions to be included quickly in the event that a deadline is not met. Finally, very large transactions may be difficult to place in blocks that are generally full, which is a problem that exists outside of GasHawk as well. Mitigations for this issue may include special arrangements with block producers or the use of top percentile priority fees.

Finally, the team also identified the issue of "tx stacking," which refers to the phenomenon of multiple transactions stacking up and being released at once. This can result in the mempool rules applying to the transactions, leading to the selection of transactions based on criteria such as nonce, maxBaseFeePerGas, and priorityFeesPerGas. In order to mitigate the potential impact of tx stacking on the cost savings provided by GasHawk, the team recommends the use of a "minimalistic approach" in which the sequencer only sends the necessary number of transactions to the network.

Conclusion

The simulation has shown that the use of GasHawk has the potential to provide significant cost savings for Optimism on the Ethereum mainnet. The team found that the sequencer using GasHawk was able to save approximately 13% of its costs which translates to possible savings of around 32 ETH per month (~37.800 USD), if it could accept a median delay of 10 minutes. This demonstrates that GasHawk could significantly reduce the cost of executing transactions on the Ethereum network, particularly for layer-2s like Optimism.

The team also found that the longer the deadline for submission, the greater the potential for cost savings. This is because longer deadlines allow GasHawk to more effectively target local minima in fees, resulting in lower costs for users. However, it is important to balance the chance for cost savings with the need for timely transaction execution, as longer deadlines may result in longer waiting times for transactions to be executed.

In addition to providing cost savings, the team also found that GasHawk can help to reduce the volatility of base fees on the Ethereum mainnet. The team found that GasHawk transactions had a more narrow base fee distribution and a lower standard deviation (sigma) compared to transactions submitted without the use of GasHawk. This suggests that GasHawk could make fee pricing more predictable, which can be beneficial for users of the network.

There are some considerations that need to be taken into account when integrating GasHawk into an L2 solution. For example, GasHawk should never be the only publication route for transactions, and there should be a robust fail-over in place in case of any issues with the service. Additionally, GasHawk may work best when the maxFeePerGas is set to a relatively high value, as this allows transactions to be included quickly in the event that a deadline is not met. Finally, very large transactions may be difficult to place in blocks that are generally full, which is a problem that exists outside of GasHawk as well. Mitigations for this issue may include special arrangements with block producers or the use of top percentile priority fees.

Overall, the simulation conducted by the GasHawk team has shown that the service has the potential to provide significant cost savings for Optimism and other layer-2s that are regularly settling transactions on the Ethereum mainnet.

Fig. 6: Cumulative transaction cost and savings over TX count for the simulated time range.