Rollup-Centric Considerations of Based Preconfimations (Part 1)

July 29th, 2024

This article is written by @CeciliaZ_ with special thanks to Lin Oshitani, Conor McMenamin, Jonas Bostoen, Christian Matt for the reviews 🎉

You can also find it on EthResearch.

**Note: the designs in this article are subject to change

💡 TLDR

This article introduces how we transition from Taiko to Gwyneth - our prospective rollup design with based preconfirmations and synchronous composability. Gwyneth is at the frontier of our research effort for the second half of 2024, and it will be the focus of our development apart from Taiko’s main chain.

In Part 1, we outline the Taiko chain setup, discuss the profitability and timeliness of L2 block building, and explore how implementations of preconfirmations can configure blocktime and more efficient data publishing. We also address the issue of nondeterministic proposals caused by multiple preconfirmers through leader election, which affect UX for builders and usersAs the preconfirmation space evolves, we will provide an overview in Part 2 of the designs and developments from various teams including Nethermind, Chainbound, Limechain, Primev, and Espresso Systems. Reflecting on the origins of the collaboration at ZuBerlin and EthCC, we anticipate a future Ethereum supported by a preconfirmation ecosystem.

Why does Based Rollup need preconfimation?

We've been working closely with multiple teams engaged in preconfirmation. As a Based Rollup, Taiko requires preconfirmations and additional designs to deliver steadily high throughput, fast finality, L1 sequencing, and decentralized building.

At present, Taiko Labs is subsidizing block production by running proposers, effectively burning ETH to maintain a fast and inexpensive network. However, we're pleased to observe a growing number of unique addresses submitting blocks. Well done, Taiko community! 🎉

The Simplest Taiko Chain

With that in mind, our effort on preconfirmations needs to be expedited, as we aim to facilitate profitable block building in the community without compromising security and throughput. Let's examine why preconfirmations are essential given the basic setup of the Taiko chain:

(In the following literature, we denote L1 block #100 as L1-100, L2 block #75 as L2-75)

Decentralized proposers run their taiko-geth to sync with the L2 mempool.
When a batch of Tx constitutes a profitable block, the rational proposer submits this block to L1.
- The profitable criteria is the total tip collected from all Tx plus their MEV covers the costs to interact with L1 and prover:

Taiko smart contract on L1 contains the decentralized ledger of L2 Tx batches. These batches will, inevitably, contain invalid Tx with vanilla proposing strategy, since the sequencing is not coordinated. For example:
- L2-75 has a Tx transferring 100 ETH from Alice to Bob without Alice’s correct signature
- L2-76 and 77 both contain a Tx from Cassy with nonce equaling 9;
In such cases, taiko-client, similar to Ethereum’s consensus client, will witness the invalid Txs from the L1 ledger and exclude them from the actual block being synced to L2.
Back to L2, each taiko-client (fork of Ethereum’s consensus client), witnesses the L1 ledger and applies a deterministic rule that invalidates the above Txs. Subsequently, the client can form a correct batch constituting the next block and construct the blockhash.
This blockhash is considered finalized when a prover submits proof of the execution of valid Txs, as well as the exclusion of invalid Txs from the state of the ledger.

As Vitalik noted, a based rollup can be a "total anarchy" amid the chaos, but it remains functional as long as the decentralized ledger persists and the L2 network maintains synchronization. Taiko will continue to progress by inheriting L1 security and finality. However, proposers may still encounter challenges, resulting in a liveness issue due to lack of profitability. Let's dive deep.

Challenges and Solutions

Profitability & Timing Game in L2 Block Building

In the diagram below proposer Alice observes L2-75 upon confirming L1-100, and she creates L2-76 with blockhash 0xabc. Proposer Bob, attempting the same, causes a fork with an alternate blockhash 0xf3c. Both submit proposals to L1-100 and pay the current L1 transaction fee. However, since Alice’s transactions were incorporated first, Bob’s transaction reverts due to L1_UNEXPECTED_PARENT(), causing Bob to lose his proposing fee. Alice successfully earns the tip and MEV of L2-76, but she still needs to compensate the prover to validate her block afterward.

An L2 block is proposed to the rollup Contract as a raw transaction batch. Consequently, each node subscribing to the event derives the blockhash in their own execution clients. Despite this, the rollup state is finalized when the proposal is confirmed on L1 because block hash derivation is deterministic. We still need a proof to validate the block hash to rollup’s L1 ledger, enabling light clients to fetch the states and users to perform withdrawals. Hence, real-time proving solutions such as SGX are important because they enforce L2 state finality with high probability. Let’s recall:

Solving for MEV is a knapsack problem - the larger the knapsack, the more value extracted. It’s been well-studied that L1 proposers will play the timing game to extend the MEV solving window as much as possible; the same logics apply to L2. Even worse, because L2 users typically tip much lower in an ecosystem with significantly less liquidity, the current 12s block time on Taiko is far less than enough for anyone to profit, which results in a liveness issue for decentralized proposing. This is why Taiko Labs operates an unprofitable proposer to sustain the 12s block time. Without taking measures, the L2 blocktime would be arbitrarily long if rational proposers play the timing game.

Solving Blocktime & Data Publishing with Preconfirmations

Essentially, we’re facing a conflict in a UX property of L2 (blocktime) versus decentralized block building. In centralized L2, timeliness is easily managed by the centralized sequencer, while on L1, the beacon attestation enforces the time to publish the execution payload. Thus, we observe that timeliness must be enforced by some mechanism other than builders in the game. How do we resolve the conflict? Preconfirmations!

In this case, a preconfirmer can periodically issue preconfirmations to builders for smaller sequenced batches, then batch publish the batches to reduce the data publishing costs. The periodic issuance of batches now constitutes L2 blocks. The L2 protocol, which allows the preconfirmer to opt in, can facilitate timeliness by ensuring preconfirmed blocks are released every T second. Now, we define T as the L2 blocktime, which can be adjusted faster to improve user experience.

Regarding data publishing, Taiko currently publishes all encoded L2 transaction lists in blobs. This requires the proposer to cover the L1 gas fee for a whole blob regardless how much data is actually necessary, further reducing the block's profitability. In Gwyneth, preconfirmations will allow for more batching of L2 blocks into blobs if the preconfirmer is assigned multiple L1 slots, which also implies the separation of sequencing commitment and data availability:

Preconfirmations Issuance ⇒ commit L2 sequencing
Preconfirmations Delivery ⇒ data publishing to L1

Now we can characterize the L1 preconfirmer as the de facto L2 proposer, and the existing decentralized sequencer who submits batches as L2 builders - we just migrate the PBS architecture to L2. Moreover, this L2 PBS mechanism can use a similar pipeline as on L1, because the L2 proposer is exactly an L1 validator who runs something like MEV-boost with a preconfirmation add-on. The new fee model functions as follows:

For clarification, L2 proposers are the preconfirmers who opt into the Gwyneth protocol to propose L2 blocks, and the preconfrmers are the L1 validators who can issue preconfirmations.

Overall, preconfirmations enable Gwyneth blocks to be built in short and steady intervals by decentralized participants, while not compromising profitability. A deficiency of liveness caused by lacking liquidity on L2 will not jeopardize blocktime; in other words, users can always enjoy fast transaction confirmation. It also provides a clear model for L2 MEV compatible with the existing PBS pipeline.

From Decentralized Block Proposing to Based Sequencing

We have discussed how preconfirmation benefits L2 proposers. Now, let's consider proposal inclusion from the perspective of L1 validators.

Initially, we have a distinct group of L2 participants who compete to propose the next L2 batch by calling the ProposeBlock function in the Taiko smart contract. Their proposal transactions with encoded L2 batches are exposed in the public mempool, and L1 validators or builders will choose to include these proposals. Apparently, the L1 parties can easily capture the transactions, stealing the L2 tip and MEV when producing the L1 block. Sound familiar? Indeed, since we're revisiting the PBS playbook. PBS allows validators to outsource block-building to the highest-bidding builder. The builder subsequently sends the full block back through a trusted relay, which conceals the block body until receiving the validator’s signature. Rollup with permissionless sequencing can implement similar mechanisms to mitigate block stealing.

However, there’s no need for mitigation following the definition of base rollup:

A rollup is said to be based, or L1-sequenced, when its sequencing is driven by the base L1.

In other words, all L2 proposers are L1 validators. Given access to both mempools, a builder can incorporate L2 batches in her L1 bundles, which is by far the most efficient paradigm for Gwyneth block-building, and it validates the subset relation we mentioned above:

Recall also in PBS, validators have a choice to build the block natively without using MEV-boost connecting to external builders. The L1 validator, who’s also an L2 proposer, can issue consecutive preconfirmations to self-produce L2 blocks until her slot to propose. In this case, we may also omit the separate role of builders, and rewrite the fee model for L2 proposers:

With the inclusion model much simplified, we note that the L1 validator who includes the L2 proposal is the deterministic proposer of L2. Given Taiko’s current 12s blocktime, there is a one-to-one correspondence between each L1 and L2 block, hence the state of the chain at any slot is deterministic.

Nondeterministic Proposer and Leader Election

Now, as we decouple the correspondence with preconfirmation, we argue that nondeterminism is also introduced because, during the L1 epoch, multiple preconfirmers exist to perform sequencing concurrently.

If these preconfirmers are the subset of L2 proposers who produce blocks natively, everyone will start building on top of the latest finalized parent. This continues until the set of preconfirmations is settled, updating the head of the chain. Then, a proposer will restart with the new head and abandon their local ledger, resulting in previous preconfirmed transactions being reverted upon delivery. If the proposer does not restart and proposes the local fork with data publishing during their slot, that proposal will also revert. In such a case, the L2 will miss a slot to update; users will experience the chain halting until the next proposer comes on board. The malfunctioning proposer might be slashed depending on the protocol implementation.

Considering builders in the PBS setting, who can send their sequenced batches to all L2 proposers in the current epoch, the head of the chain will appear nondeterministic to them, as all proposers will endorse different forks simultaneously. However, only the next-in-line proposer holds the source of truth, since her ledger will be settled first. Therefore, a rational builder should request preconfirmation only from the next-in-line proposer. Nonetheless, the protocol cannot prevent a malicious proposer from forcing his fork proposal through a regular transaction on Ethereum.

There are two possible solutions: 1) define the ledger held by the next-in-line proposer as canonical, which yields a leader selection protocol; 2) disable block proposals at the non-preconfirmed L1 slots, then fork proposals will likely be excluded by a rational next-in-line preconfirmer. The latter solution is sub-optimal because we still want to preserve the option of non-preconfirmed block proposals unless there are enough preconfirmers to achieve our desirable liveness.

Summary: How we Use Preconfirmations

Taiko started as a rollup with decentralized proposers, with a protocol that deterministically derives L2 state as long as the ledger is finalized on L1. We realized that based sequencing, which unites L1 and L2 proposers, transforms our framework into something more simple and powerfull. Based sequencing will work, naively, with finality and security inherited from L1.

Based sequencing may not work, in practice, considering builder profitability, bootstrapping liveness, and the configuration of fast blocktime. We discuss preconfirmations to tackle these challenges with some tweaks on timeliness and proposal mechanisms. However, having multiple validators who issue preconfirmations can cause the concurrent building of L2 forks. This introduces nondeterminism for the spectators of chains including builders, exchanges, and users, although fortunately, nondeterministic sequencing does not affect finality - most obstacles in based sequencing relate to essential UX properties for builders and users.

Despite some controversy, leader election could be a practical middle-ground solution. We anticipate a significant number of L1 proposers opting in as preconfirmations gain adoption. Consequently, proposer decentralization still remains close to the (at least theoretically) maximal achievable decentralization offered by a vanilla based rollup.

As the preconfirmation space evolves, Part 2 will provide an overview of the updated status across teams, including Nethermind, Chainbound, Limechain, Primev, and Espresso Systems. We appreciate their initial proposals for Taiko's preconfirmation design and will incorporate these insights and experiences into Gwyneth's development. Part 2 will also reflect on the origins of our collaboration at ZuBerlin and EthCC, and will elaborate on the Gwyneth protocol extending to synchronous composability.

In the meantime, you can follow Gwyneth updates on X @gwyneth_taiko and progress on Github.