This blog post discusses a fundamental problem within the Ethereum ecosystem - the gas cost management. One way to tackle this problem is to use gas reservation schemes (i.e., schemes that allow block producers and users to commit to a specific gas allocation at a predefined price before knowing the contents of the transaction). Let’s start by discussing the problem. Afterwards, we will analyze LedgerHedger, a concrete implementation of a gas reservation scheme. Finally, we will discuss the applicability of LedgerHedger for Ethereum rollups, which significantly consume Ethereum gas.

Gas management

The issue with f gas management begins with the concept of resource allocation. Ethereum has a cap on how many computing resources (i.e., gas units) can be included in a single block, and thus, block producers must decide which transactions to include in their scarce block space. In Ethereum, this problem of resource allocation was addressed through market dynamics. Users choose how much they are willing to pay in order to have their transaction included in the next block, and block producers pack their block in such a way as to maximize their earnings. This means that, in times of high congestion, only the users willing to pay more will have their transactions executed, with the rest remaining in the queue until gas prices come down.

This setup allocates block space very efficiently, in general, prioritizing high-value transactions over low-value ones. However, it comes at the expense of price stability. As we can see in the graph below, gas prices per hour experience high volatility.

But why is this volatility a problem? There are at least two types of stakeholders that are significantly exposed to this price volatility:

1. Intermediaries that submit transactions to Ethereum on behalf of their users. This includes rollups, oracles, wallets, etc. These services charge a fee to their users before submitting their transactions to Ethereum, which exposes them to price volatility. If they overestimate their future gas costs, they will overcharge their users, thus providing a suboptimal service. On the other hand, if they underestimate their future gas costs, they will incur losses, which will also affect their ability to serve their clients.

2. Small validators. The lower the probability of being selected to build a block, the more the validator will be exposed to fee volatility. In particular, even though a part of the fees are burned due to EIP-1559, the extra fees paid are still a considerable fraction of the validator’s revenue. Therefore, small validators may see their monthly revenue fluctuate with changes in gas fees.

There are a few proposals to tackle this, ranging from derivative products to hedge the gas fee volatility risk (e.g. Oiler ), tokenization schemes for gas (e.g. Gas Finance ) and commitment schemes (e.g. Alkimiya ). However, in this post, we will focus on commitment schemes, which represent a category of solutions where block producers commit to a specific gas allocation at a predefined price before knowing the contents of the transaction. In particular, we will concentrate on LedgerHedger, which is a mechanism proposed by Itay Tsabary, Alex Manuskin, and Ittay Eyal in their paper LedgerHedger: Gas Reservation for Smart-Contract Security .

LedgerHedger overview

According to the authors, LedgerHedger is a “two-party mechanism for assuring that a transaction will be confirmed in a target time frame”. On one side, we have the Buyer. This party wishes to execute a transaction at a predefined price, at a future date. On the other side, we have the Seller. This party commits to the execution under the Buyer’s specifications. Note that the Seller can be a validator or a block producer, but they don’t have to be one for the mechanism to work.

LedgerHedger was designed to work as a smart contract so that any two willing parties can engage in gas commitments in a manner that doesn’t need to be based on trust. It ensures that the committed transaction is executed within the predetermined time frame and at the predetermined gas fee by adding measures to handle scenarios where the Buyer or Seller doesn’t fulfill their part of the agreement.

LedgerHedger runs in two phases - Setup and Execution:

Setup Phase:

1. Initiation: The Buyer starts the process by creating a LedgerHedger contract instance. This includes setting specific parameters such as the time frame (in block ranges) for the execution phase, the required gas units, and the minimum collateral that the Seller must provide to enter into the commitment. The Buyer also deposits an up-front payment for the transaction at a gas price they are willing to pay.

2. Acceptance Period: Once initiated, there’s a countdown, during which a Seller can accept the contract by depositing the required collateral. If a Seller accepts the contract, no further interactions are allowed until the execution phase. If no Seller accepts it within the countdown, the Buyer can reclaim their tokens and close the contract instance.

Execution Phase:

1. Buyer’s Action: During this phase, the Buyer can publish a $\text{tx}_\text{payload}$ that the Seller must execute.

2. Seller’s Action: here, the Seller has two options:

   1. Execute Transaction: The Seller can use the $\text{tx}_\text{payload}$ from the Buyer to execute the transaction. Upon successful execution, the Seller receives the payment and their collateral back.
   2. Exhaust Contract: If the Buyer doesn’t provide a transaction or provides a faulty one, the Seller can “exhaust” the contract by performing null operations up to the gas limit specified. This still allows the Seller to claim the payment and the collateral, preventing a loss in case the Buyer is uncooperative. However, they receive a slightly lower payment than they would get if a transaction were executed.

In their paper, Eyal et al. not only propose the LedgerHedger mechanism, but also perform an in-depth analysis of the game-theoretical properties of the mechanism and provide some guidance on the conditions where the two parties are incentivized to follow the protocol, thus hinting at some strategies for setting the parameters of LedgerHedger.

They conclude that the more risk-averse the two parties are and the more volatile the gas fees are, the more amenable each party will be to engage with the contract. This is to be expected, given that increased volatility and/or increased risk aversion leads to a higher preference for certainty, achieved by interacting with the LedgerHedger contract.

The authors also found a few combinations of assumptions (i.e., utility functions and gas fee distributions), in which contract settings guarantee that both parties will follow the protocol.

LedgerHedger analysis

LedgerHedger and the accompanying paper form an excellent basis for reasoning regarding gas reservation commitments in Ethereum. One of the key advantages of the protocol is its simplicity. Firstly, it can be easily implemented and deployed as a smart contract, which means it is not just a theoretical solution that cannot be used in a real blockchain setting. Secondly, its simplicity allows the authors to formally analyze how rational parties are expected to interact with the protocol under various assumptions and conditions.

However, to conduct this formal game-theoretical analysis, the authors had to make some assumptions that may be questioned. Firstly, they assumed that within the setup and execution intervals, the gas fee was constant. This makes the analysis a lot simpler, since they only need to consider two fee prices - one for the setup phase and another for the execution phase. This assumption could be more realistic, but that would lead to a more complicated game. With a fixed fee, the Seller only needs to decide whether to execute the transaction, whilst with a variable fee, the Buyer also needs to decide when to execute the transaction.

Another assumption that may influence the results is the distribution of gas fee prices. Here, the authors assume that the difference in price at each block follows a truncated Gaussian distribution centered at 0. The authors did a Kolmogorov–Smirnov test test on 20-block batches of gas prices in September 2021. They concluded that only 66% of the batches follow a Gaussian distribution, assuming a significance level of 95%. They also plotted the distribution of the batches along the two distribution parameters (the mean, $\mu$, and the standard deviation, $\sigma$), showing that even though the majority of batches has $\mu=0$, there is a significant number of batches with different distribution means. The image is below:

Even though the authors must resort to some strong assumptions, the analysis still provides a solid base to reason about the incentives of gas reservation mechanisms, which is one of the key contributions of this work.

Another contribution is a framework based on the theoretical model for setting the contract’s parameters in a way that guarantees, with a high probability, that both parties will follow the protocol. With LedgerHedger, the Buyer is responsible for setting all the contract parameters at the start of the setup phase. Some parameters are simple to choose, such as the gas allocation required or the time intervals. However, the Buyer also has to set the fee per unit of gas beforehand and how much collateral the Seller has to deposit in order to accept the commitment, which is not an obvious thing. To help, the authors include an example of a rollup transaction, and compute how much collateral and payment the Buyer should set under different price distributions and utility functions.

Between the two phases, the setup is the most sensitive to these initial parameters. Once a Seller accepts a contract, a high enough collateral will ensure that the Seller will always be economically incentivized to either exhaust the contract or execute the transaction. However, the problem lies in finding a market of Sellers willing to accept contracts from Buyers at competitive rates. Let’s assume the Buyer estimates the future expectation of gas prices incorrectly. In that case, they will either overpay for their transaction or have no Seller accepting the commitment, thus losing the gas fees from interacting with the contract in the first place!

This is one of the most significant shortcomings of this design - we are essentially asking the least informed party (the end-user) to come up with a good model to estimate future gas prices, and we are letting the most informed party (the validator or the block builder) decide whether to engage or not in the contract. There are two ways to improve on this design:

• First, we could have a trusted party (e.g., a relay) taking the Buyer’s place on the end user’s behalf. First of all, this party would be more informed to set the contract parameters correctly, and then, they could work more directly with builders and validators in order to guarantee reasonable rates for their clients. However, this has the disadvantage of bringing another centralizing force into the ecosystem.

• Second, we could change the protocol to make the setup stage an auction market where Sellers compete to provide more competitive rates to end users. This design would add more complexity to the protocol, but it would not impact the decentralized nature of the current protocol.

Another important consideration is how LedgerHedger would fit within the current block-building structure in Ethereum. At the moment, a little over 90% of blocks use [MEV-boost]( https://boost.flashbots.net/ , which means that a majority of validators are not building their own blocks. Instead, they pick the highest revenue block from a feed of blocks created by searchers and block builders. The authors don’t consider these multi-party systems where various stakeholders operate at varying levels of a transaction life-cycle. At which stage should commitments be introduced? And which parties must be involved? And how does MEV impact the incentives for these commitments?

Lastly, one could explore in more detail how changes in the time frames of the two phases impact the incentives of the parties or the optimal parameters of the contract. An obvious impact comes from the gas price distribution - since they assumed a random walk process, the volatility of the distribution increases proportionally to the number of steps being forecasted. In other words, the longer the period between setup and execution, the higher the volatility of the price distribution will be. The authors explore how volatility impacts the incentives; however, it is unclear how the values they experimented with translated to block intervals. Therefore, a more in-depth analysis of time frames and their impact on incentives should be conducted.

LedgerHedger for rollups

Now that we understand how gas reservation schemes generally work and why they are relevant in the Ethereum ecosystem, we can discuss the way LedgerHedger and similar schemes could be applied to particular use-case — the rollups. In this case, we can think of two ways to implement these schemes.

Rollup as a Buyer

In rollups, there is a delay between the time when a user submits a transaction on the L2 and the time when the transaction data or the corresponding state is published in the L1. For simplicity, let’s call the actors responsible for publishing the rollup data in Ethereum “Sequencers.” Different rollups will have different names for this role, but Sequencer is a common denomination.

So, from the time a transaction is selected to be included in an L2 block and the time its data is published, the gas fees may have changed, and the Sequencer bears this volatility risk. They already made a soft commitment to post data (the transaction data, the state diffs, and/or proofs) in the L1, but they cannot know at that point how much posting that data will cost them.

Instead, the Sequencer could use LedgerHedger or similar schemes to protect itself from L1 gas fees volatility. As a specialized actor, the Sequencer should be capable of setting the initial parameters for the contract. In addition, Sequencers (at least for the larger rollups) are large gas buyers and, as such, have purchasing power. In other words, it would be hard for Ethereum validators and block builders to ignore gas reservation commitment requests if a significant source of fees moved to those schemes.

Besides having more stable gas costs, another advance for L2 users is a slightly stronger guarantee of finality. Since the Sequencer is committing, beforehand, to spend a certain amount of gas, the users know that the Sequencer is financially incentivized to follow through on that commitment and reveal valid transactions to the Seller (i.e., the validator or block builder).

From a first analysis, using gas reservation could be beneficial to rollups. However, more analysis is needed in order to finetune the parameter setting process and verify its applicability. In particular, we need to confirm if the conclusion in the paper holds for the time-frames for the particular rollup that wishes to implement these schemes.

Rollup as a Seller

Rollups are also a source of gas costs. Users wishing to submit transactions in the rollup must pay the fees. In this case, the fees usually encapsulate two main costs - the costs of L2 resources (similar to Ethereum) and the data publishing costs (which relate to the cost of publishing data in the L1).

All the larger rollups use a gas fee system, and therefore, their users can use LedgerHedger or similar schemes to cover the L2 gas fee costs. In this case, the rollup validators or sequencers would be the Sellers, and the L2 users would be the Buyers. Under this setup, users get more predictability over their gas costs and an earlier commitment that their transaction will be included in the L2 block.

Now, in this setup, we hit again the problem of requiring unsophisticated users to define the commitment parameters, which could be better from a usability perspective. Therefore, to make this work, we need to have a better way to initialize the contract, as we discussed in the previous section.

In addition, we still need to verify that the schemes work for the time frames required here.

Simulating LedgerHedger

In the previous section, we hinted at the fact that further testing would be essential to finetune these gas reservation schemes and verify their applicability to real use-cases. For example, let’s focus on applying LedgerHedger to the rollup space, assuming that the rollup is the Buyer.

There are two ways one could go about testing this. In both cases, we would first need to pick a specific rollup and gather their desired time-frames and gas allocation requirements.

• Backtesting. This would involve querying all the L1 transactions made by the rollup in question and the fees they paid. Then, we would consider each transaction as an independent “game” and make a simulation on how rational parties would behave under the conditions of that particular game. More concretely, we could use the actual gas fees experienced, the gas unit used, and the empirical gas fee volatility at the time, to derive the expected utility difference for both parties. We could test different collateral values, payments, and utility functions. Besides collecting the expected utility difference metrics (which allows us to understand whether the parties would be incentivized or not to enter the commitment), we can also compute the profit and loss for both parties by comparing their actual P&L with the P&L they would get with LedgerHedger.

• Monte-Carlo simulations. This analysis involves focusing on a single “game” occurring in the future (i.e., a single transaction and single LedgerHedger commitment being performed) and generating multiple paths of how the game could unfold under some assumptions. In particular, we would use the latest gas fee price data to fit a statistical distribution (likely a random walk process) and then generate multiple paths for gas prices for the desired time frame. Once these gas price paths are generated, we can apply the same analysis we did for backtesting, and compute the same metrics. The key difference here is that we can cover a wider scope of scenarios, since we are not limited to the actual gas prices experienced in the past.