LedgerHedger : Gas Reservation for Smart-Contract Security

Prominent smart contracts, e.g., roll-ups, critically rely on timely confirmations of their transactions. Sadly, that’s not how blockchain works, as confirmation times depend on transactions fees, where the required fee is determined by the volatile fee market. We present LedgerHedger, the first smart contract that facilitates a reservation for a future transaction confirmation. LedgerHedger is secure, incentive-compatible, and has low overhead for practical future-transaction parameters.

We start with some blockchain background, discuss current transaction confirmation modus operandi and its shortcomings, present how regulated markets overcome volatility and the inadequacy to blockchains, and present our LedgerHedger design and Solidity implementation. You can find the full details in the technical report.

Preliminaries

Ethereum uses an append-only log called the blockchain. It comprises elements called blocks, and parsing the log results with the system state, i.e., how much cryptocurrency everybody has.

Entities called miners create blocks, using methods like PoW or PoS (doesn’t matter for our context today), and include transactions in these blocks. Only included transactions affect the cryptocurrency possessions.

Transactions consume gas, an internal measure of their complexity. The system limits how much gas can be consumed by transactions in a single block, hence miners pick only subset of the available transactions. Transaction issuers assign fees to their transactions to incentivize miners to confirm their transactions. Miners prioritize transactions according to their fee-per-gas ratio.

It follows block gas is a scarce resource, hence a fee market forms. For each block there is a gas market price, the minimal fee-per-gas ratio required for having a transaction confirmed. The varying demand results with a volatile market price, which can even double itself within a day.

A Transaction Just Wants to Be Confirmed

Now, say you are an Ethereum user and you want your transaction confirmed in the next block. For that, your offered fee simply needs to meet the market price, which you can quite easily determine for the next block using services like the gas station. Follow their advice and you are usually golden.

But, what if you want your transaction to be included in a future block interval, say, during a specific afternoon next Thursday? How can you predict the market price a week ahead? And what happens if you miss?

As it turns out, these questions are more than a theoretical experiment, but actually decisions that system operators face on a daily basis. These include any system that relies on its transactions being confirmed in a timely manner, e.g., optimistic and ZK roll-ups, atomic swaps, state channels, contingent payments and so forth. Even more crucially, the safety and liveness guarantees of these systems rely on a timely confirmation of their transactions; failing in that can result with significant cryptocurrency thefts.

Nowadays, these systems operate in a naive manner – they defer worrying about the future confirmation to its due date. Specifically, they take actions at present times assuming the market price does not surge. If that assumption fails then the system operator either has to incur the unexpected additional expense, or forfeit the confirmation and the system guarantees.

A Trip in Regulated Markets

Well, this future-price-prediction-or-we-go-out-of-business is not unique to cryptocurrencies and transaction fees, there are plenty of volatile markets out there. For example, airlines are dependent on the rather-volatile oil prices, where a price spike can put them in a hole. To overcome this volatility, airlines and oil suppliers often engage in a hedging contract, where they agree on a deal at future time frame for a predetermined price.

Could this resolve our future gas needs in a blockchain? Can we have hedging in cryptocurrencies?

Well, turns out this is a bit tricky: airlines and oil suppliers operate in regulated markets, i.e., there is an external enforcer (court) that can make sure both parties comply with the contract. In cryptocurrencies, the miners are the enforcers, and they (and only they) decide what transactions are confirmed. With soaring cryptocurrency prices, the stakes are too high for naively relying on miner altruism, and there is a need for a robust solution. Moreover, who should the hedging contract be with – various miners produce blocks in the target interval.

Enters LedgerHedger.

LedgerHedger Design

LedgerHedger takes a different approach – it incentivizes the correct execution rather than enforcing it. We set a hedging contract between a single miner and the transaction issuer. This enables LedgerHedger to have only a relatively-low overhead – there is no need for elaborate proofs of misbehavior.

LedgerHedger operates in two phases. At the setup phase, the gas-purchasing user (the Buyer) sets the contract parameters, namely the target confirmation interval, the required gas, and payment details. Buyer also locks the payment upfront, and then the gas-selling miner (the Seller) can accept the contract by depositing a collateral of her own. At this point Buyer does not commit to a future transaction.

At the target execution phase, Buyer publishes a (zero fee) transaction of her choice, which Seller can then confirm through a designated apply function. LedgerHedger verifies the provided transaction was indeed created by Buyer, and if it executes successfully, it sends the funds to Seller.

But what happens if Buyer publish a transaction that exceeds the agreed-upon gas amount, or a transaction that fails, or maybe does not even publish a transaction at all? For that there exists an alternative function, exhaust, that enables Seller to extract the funds without any corporation from Buyer. However, to prevent Seller abusing this function, its invocation spends gas equal to the agreed-upon amount through repeated null operations. This construction results with the apply function being preferred in case Buyer abides by the contract, while protecting Seller if not.

To analyze LedgerHedger we first consider what are the possible interactions Buyer and Seller can have with it – who can do what, and when. These, in turn, give rise to a game, which we analyze using the subgame perfect equilibrium solution concept. Our analysis confirms that fulfilling the contract as intended is the subgame perfect equilibrium for a wide range of practical parameters.

LedgerHedger Solidity Implementation

We can only hope that Ethereum-savvy readers have not pulled out their pitchforks yet – our description above of the apply function does not address the minimal base-fee required by EIP1559, which prevents zero-fee transactions. But worry not, LedgerHedger circumvents this requirement by utilizing meta transactions, decoupling the transaction creator (in our case, Buyer, who decides what the transaction does) from the transaction issuer (i.e., Seller, who pays the necessary fees).

For the exhaust function, LedgerHedger expends the required gas by performing null operations, specifically, by increasing a counter sufficiently many times.

We implement LedgerHedger to be reusable for the Buyer, amortizing the contract deployment cost. This, along with the function invocation costs result with an overhead of roughly 50K gas per usage. Considering a practical value of 10M for a roll-up proof, the overhead is orders of magnitude lower.

We bring the full analysis, implementation and deployment details in our technical report. You can also find the contract code in our repository. This post also appears in Itay Tsabary’s site.

Use LedgerHedger at your own risk. We did not have LedgerHedger audited. We take no responsibility for any possible vulnerability, error, technical issue or bug.

Follow @ItayTsabary
Follow @Amanusk
Follow @IttayEyal