# Lovely Little Gas Protocol

- [ ] Inclusion Protocol
- [ ] Gas Price Oracle
- [ ] New Tx Type
- [ ] Planned Featureset

> Gas Protocol and how it fits into Staking for Manifold

Lovely Little Gas Protocol is an implementation of the LedgerHeadger[^1] specification.

> Note: an audit has been completed by 20squares, results will be posted here

Our implementation follows the smart contract wallet (SCW) design pattern. This design enables customizing the retrieval of the contract tokens, which, for LovelyLittleGasProtocol, is done only through the Execute, Exhaust, and Recoup functions.

Additionally, this design enables decoupling the transaction issuer (i.e., the party that pays the transaction fees) from the transaction signer (the party that creates the transaction). This, in turn, enables having one party, Seller, use his gas allocation (or pay the transaction fees) to confirm a transaction by the other party Buyer, using so-called meta transactions

> The implementation is compatible with EIP1559 since `txPayload` is a meta transaction, and the transaction by Seller that invokes `Execute` is the one that pays the required BASEFEE[^2].

## Protocol Phases

The LLGP Protocol operates in **three phases**


At the setup phase, the gas-purchasing user (the Buyer) sets
the contract parameters, namely:

- The target confirmation interval (Note, this is configured by us as to not exceed 2 epochs worth of slots)
- The required gas.
- Payment details.

Buyer also locks the payment upfront, and then the gas-selling block builder (the Seller) can accept the contract by depositing a collateral of his own. At this point Buyer does not commit to a future transaction.

At the target execution phase, Buyer publishes a (zero fee) transaction of his choice, which Seller can then confirm through a designated Execute function. LLGP 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 cooperation 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 Execute function being preferred in case Buyer abides by the contract, while protecting Seller if not.

## Constraints

Parameter : acc, start, end, block number operation ranges
Parameter $\quad: g_{\text {alloc }}$, required gas
Parameter $\quad: c o l$, the required collateral by Seller
Parameter : payment, payment for execution
Parameter $\quad: \varepsilon$, additional payment for successful execution.
Global Variable : current, current block number
Variable $\quad$ : status $\leftarrow \perp$, contract status variable
Variable $\quad: P K_{\text {Seller }} \leftarrow \perp$, public identifier of Seller
Variable $\quad: P K_{\text {Buyer }} \leftarrow \perp$, public identifier of Buyer

The Buyer also deposits the token payment for the future transaction confirmation. This token payment enables 'gasless' transactions, a way of paying for transactions that abstracts away the need for ETH by the end user (the Buyer in our example). Take note, ETH is still used behind the scenes for 'gasless' transactions!.

Following its initiation, the contract starts an acceptance block countdown, during which a Seller can accept it using a transaction. Additionally, accepting the contract requires Seller to deposit tokens as a collateral matching the collateral parameter. This is handled by the Staking Vault: Stakers of FOLD underwrite the risk of counterparty default and thereby earn fees from doing so. This risk-underwriting enables the system to process and handle capacity based off of a measured net asset value of the total vault less 20%. The seller is marked as an authorized Relay address, enabling other relays to potentially put up collateral and participate in this system.

The collateral is 'returned' conditioned on Seller further interacting with the contract. Either if Seller accepted the contract, or if the acceptance countdown is completed, the contract accepts no further interactions until the exec phase. Returned means in our context 'available unused vault balance', meaning it is no longer counting towards the vault's currently in use collateral.


Towards or even during the exec phase, Buyer can publish `txPayload`. This allows Seller to Execute it, executing `txPayload`, and getting the payment and collateral tokens from the contract. This is the main functionality of LovelyLittleGasProtocol – enabling Seller to execute a transaction provided by Buyer. Alternatively, Seller can exhaust the contract, consuming the hedged gas on null operations, and then receiving its tokens. The motivation for this functionality is to enable Seller to claim the tokens, regardless if Buyer provides a transaction or not; this protects Seller from a faulty or malicious Buyer. However, the naive solution of letting Seller report Buyer as faulty is not sufficient: It allows a Seller to falsely accuse a correct Buyer, getting the contract tokens without providing the confirmation service. By making Seller waste equivalent gas, we remove his incentive to do so. If Seller has not accepted the contract, then Buyer can recoup the contract tokens using a transaction.[^3]

### Notes

## Citations

[^1]: Itay Tsabary, Alex Manuskin, and Ittay Eyal. (2022). LedgerHedger: Gas Reservation for Smart-Contract Security. *Preprint*

[^2]: Chung, Hao and Elaine Shi. “Foundations of Transaction Fee Mechanism Design.” ArXiv abs/2111.03151 (2021): n. pag.

[^3]: Liu, Yulin, Yuxuan Lu, Kartik Nayak, Fan Zhang, Luyao Zhang and Yinhong Zhao. “Empirical Analysis of EIP-1559: Transaction Fees, Waiting Times, and Consensus Security.” Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (2022)