Gloated Rollups and Resource Markets
This is a draft copy, since Mirror.xyz sucks I am re-posting it on the forums to solicit
What is XGA?
Simple thesis:
— Ethereum Resource Market needs to be re-staked — Can’t do it as it’s off consensus protocol (off chain) — No in protocol gas market — ePBS is a dead end (as offchain agreements can be done, bypassing the market entirely). — Markets for the 21st century, e.g., Consensus, Data Availability, Settlement vs. Markets of the 20th Century: Petrochemicals, Raw Commodities, etc.
Preconfirmations vs. XGA
Relay Protect
The Relay operates a bundler service for normal L1 transactions, called ‘Relay Protect’ in which it abstracts away the XGA Auction for users: they simply submit
Based Rollups
Traditional rollups often rely on a centralized or semi-centralized sequencer to order transactions. This introduces a potential point of failure and requires trust in the sequencer’s honesty and availability. Based Rollups, on the other hand, eliminate this trust assumption by relying on Ethereum validators to determine the order of transactions in the rollup. In essence, the L1 Ethereum chain acts as the sequencer for the L2 rollup chain.
Gloated Rollups
In contrast to Based Rollups, a Gloated Rollup leverages the MEV Relay, which carries the same trust assumption that is already present vis a vie Ethereum Validators.
Based Differences
— Publishing to L1: The compressed transaction data is published to the Ethereum main net (L1) as a single transaction (or a series of transactions).
— Ethereum Validators Sequence: Ethereum validators, as part of their normal block production process, determine the order in which these L2 transaction batches are included in the Ethereum blocks. This is the crucial step!
— Rollup Execution: Rollup nodes on L2 then execute the transactions in the order determined by the Ethereum validators, updating the rollup’s state.
Taiko—Bolt Comparison
Validator Registration
At point (1) Validator BLS key to ECDSA key is mapped.
— With XGA, Validators register at the relay level. The validator delegates to the relay this signing duty, eliminating the node operator overhead of managing a hot key for signing, etc.
Electing Preconfirmation and Look ahead
At point (2) A look ahead submission scheme with an optimistic fraud proof mechanism is used for Electing preconfer’s.
— With XGA submissions are guaranteed, if settlement does not happen, an option (a convex payoff) is returned. There is no need to introduce election mechanisms.
AVS
At point (4) The AVS Node (here the L1 Proposer) detects if their duties are eligible (meaning their turn to preconf).
XGA decouples the preconf duties from any one specific AVS node and instead provides the preconf duties itself. XGA returns the set of transactions (or blocks, depending on your viewpoint) that can be included. Because of the market clearing pricing mechanism, only transactions that can clear the price can be preconf. The call option provides the ‘insurance’ against the preconf not being settled.
If the case is shown otherwise, the option payoff is used to compensate users. This is secured by the fact the returned block/bundle/TX sets can be signed by the Relay. Ultimately, the validator signs the L1 block only directly with its BLS key[1]. This proof is incompatible currently with the Taiko model, in which the validator is signing the L2 block as well. This can be overcome by the registration process, when the validator signs up, it also identifies a delegation key or party.
Bolt Preconfirmation
At point (6) This is where Bolt’s MEV Boost Inclusion List is utilized. Its failover is the L1 Public Mempool when it is not the preconfer’s slot.
This failover can expose MEV directlyd
With XGA, the relay includes the bundle/TX set. There is no broadcasting to public mempool. There is no leakage, as it is fully binary.
Inclusion is all you need
Currently Bolt only supports L1 inclusion preconfirmations and not execution preconfirmations. Inclusion preconfirmations only guarantee that the tx will be eventually included. For our PoC, we are implementing L2 execution preconfirmations, which guarantee a transaction’s exact sequence and state. We believe inclusion preconfirmations are much less useful for most use cases (but Bolt may add execution preconfirmations in the future, so this is about their current state). Source: Nethermind Taiko Preconf AVS Design Document [2]
Inclusion and execution preconfirmations aren’t mutually exclusive; they can potentially be combined to offer a tiered system of guarantees. For example, a system could offer a fast, execution preconfirmation for a premium fee, alongside a cheaper, inclusion preconfirmation for less time-sensitive transactions. This would cater to a wider range of user needs and preferences.
Additionally, this downplays liveness concerns: By focusing solely on execution guarantees, a system that provides perfect execution guarantees but frequently stalls or censors transactions is ultimately less useful. Compared to a system that provides weaker execution guarantees but maintains a high level of liveness and censorship resistance, inclusion guarantees are useful in these high volumes, contested scenarios.
Inclusion Lists are required for Execution Preconfirmations. Additionally, while leveraging EigenLayer for economic security is promising, the effectiveness of the slashing mechanisms depends on the value at stake and the potential profit from malicious behavior. If the slashing amount is insufficient, Preconfirms might be incentivized to equivocate or manipulate the look ahead. This introduces the necessity of Forced Inclusion Lists to attempt to prevent such potential equivocations.
You begin to see the thin gruel of execution preconfirmations is further watered down
Gloated Rollups
Instead of submitting to validators (really block builders), instead we use the MEV Relay to act as our sequencer.
- We send to the relay the transactions
- The transactions are kept by the relay as a bundle, additionally the relay can accept transactions from any arbitrary user.
- The relay keeps this bundle as part of its bidding process to validators, in which this bundle increases the bid value of blocks submitted to the relay
- block builders should bid more truthfully in an attempt to get the bundle added to its blocks, increasing the value of its block and thereby increasing its chances to win the priority auction (re: Flashbots auction).
This lazy bundling/sequencing process by the relay gives the additional benefit of stronger mev protection guarantees versus submitting to multiple block builders.
There are some differences between based and gloated:
Based requires a mempool in which transactions are pooled together in order for L1 Validators can draw from to construct the L2 Block
Gloated allows for sequencer and ‘forced inclusion’ transactions, except there is no need to actually go through the forced inclusion process as is typical. Since the XGA Auction is available, the relay will include transactions that are exercising their call option. In effect, this means you can force include any L2 transaction.
Finality Insurance
We can model a way to pay for finality risk insurance for super-low-latency bridges for L2 Rollups. These bridges facilitate fast transaction completion across different rollups (this could be extended to L1 networks), but they carry the risk of undercollateralization due to chain reorganizations (reorgs). The insurance would cover the finality risk, ensuring users or bridge deployers are protected against such events.
OK, then wait for part two.