Lovely Little Gas Protocol
Gas Protocol and how it fits into Staking v2 for Manifold
Lovely Little Gas Protocol is an implementation of a game mechanism for meta transaction submissions. Our implementation follows the smart contract wallet (SCW) design pattern with support for out-of-order transaction submission and EIP 4337 ('Account Abstraction via Private Mempool). This design enables customizing the retrieval of the contract tokens, which, for the LovelyLittleGasProtocol, is done only through 3 functions:
- Execute
- Exhaust
- Recoup
Note: This is why its called the Lovely Little Gas Protocol - the protocol is intended to be small and permissionless.
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
txPayloadis a meta transaction, and the transaction by Seller that invokesExecuteis the one that pays the required BASEFEE[1].
The protocol operates in three phases
Setup Phase
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.
Target Execution Phase
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.
Operant Phase
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
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 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.[2]
Interfaces
There are two primary interfaces to interact with, an end-user interface and a protocol interface. The protocol interface is described in the following post, with additional details including a new ethereum transaction type and information concerning the Gas Pricing Oracle for LLGP.
Staking V2
We can see that in this system, LLGP, that FOLD is used in a pro rata form to provide an incentive compatible mechanism for honest reporting from the Manifold Relay. Staked FOLD earns fees for all transactions using LLGP, furthermore, protocols can supply their token to provide for additional subsidy payments, etc. Staked FOLD primary risk is in operating an honest relay, so long as the relay operator is honest the collateral is not at risk of liquidation.
Comments
UI/UX Appeal for this system means that we eliminate the existing gas pricing controls, and replace them with two values: a ‘gas price’ and a ‘gas slippage%’ value. There is no ‘low, normal, fast’ verbs/controls, all transactions are priced to be included within the next < 8 blocks at most.
The Gas Pricing Oracle will provide a ‘network congestion ratio’ for mempool pending transactions as a way to provide back pressure information back to DApps and by extension their users.
This system does not require per se validators to participate directly. Those that are using the relay are already participating. However, having an enforcement mechanism (or lackthereof) provides counter-party risk, which is the reason for using FOLD for underwriting said risk.
Conditional Slashing Mechanisms like Eigenlayer would help enforce a greater and more expressive predicates w.r.t. additional functionality expanding beyond the user initiated transaction scope detailed here.
Citations (non exhaustive)
Chung, Hao and Elaine Shi. “Foundations of Transaction Fee Mechanism Design.” ArXiv abs/2111.03151 (2021) ↩︎
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) ↩︎