Ethereum L2 Based Rollups

Educational material to understand based rollups using Gateway-style preconfirmations.

Ethereum is the most credibly neutral and censorship-resistant shared consensus protocol humanity has ever created. It's the geographically, economically, and culturally diverse validator set that makes this possible. Rollups can be an extension of Ethereum, but currently, nearly all rollups use their own sequencer set, usually a single centralized sequencer. This limits composability and causes liquidity fragmentation, creating "island nations" rather than a unified Ethereum.

L2 based rollups solve this problem by giving the power to sequence transactions in a rollup to the Ethereum L1 validators. This arrangement enables coordinated and efficient sequencing between Ethereum L1 and based rollups, which in turn can enable synchronous composability and a unified developer experience.

How do based rollups actually work?

The design for based sequencing presented here applies to based Ethereum rollups that use a special type of preconfirmation model proposed by Ethereum researcher Justin Drake. As of now, this model is being explored by Gattaca and Class Lamda with based-op but not by Spire Labs. Spire's Based Stack is agnostic to preconfirmation model, and can use whatever Ethereum validators adopt. This education material is intended as a rough reference for those interested in understanding that design.

Let's break down what happens when you send a transaction:

1. A user sends a transaction to an RPC. They won't even know they're using a based rollup! But they will see an almost instant confirmation that their transaction has been accepted because of... preconfirmations ✅

2. The RPC forwards the user transaction and a preconfirmation request to an entity called a Gateway. A Gateway is an entity that can offer preconfirmations. So when it receives a transaction from a user, it can instantly say if a preconfirmation is available.

3. The Gateway returns the successful preconfirmation acceptance to the RPC.

4. And the RPC returns the success message to the user ✅ For the user, the response feels instant — a massive UX improvement!

5. The Gateway collects transactions from multiple users and shares them with the Ethereum L1 block builder pipeline.

6. The block returned to the gateway must include any preconfirmations that have been accepted.

   As the block builder pipeline isn't a single entity, many competing blocks with different values will be built, but they must all include the required preconfirmations.

7. The proposer (currently an Ethereum validator) asks the Gateway for the highest value block available, while following the preconfirmation constraints.

8. The proposer signs the selected block and submits it to the Ethereum network.

And that's the full journey of a transaction submitted on a based rollup!

But there's something missing 🤔

How did the Gateway know it could accept preconfirmations on behalf of the proposer?

A. The proposer must register as a preconfer and specify a gateway before that gateway will give out preconfirmations on their behalf. This requires a bond to incentivize the proposer to propose the block containing the accepted preconfirmations, rather than a different block.

B. The Gateway can use the preconfirmation registration smart contract to check the upcoming proposer is a preconfer, and is willing and able to accept preconfirmations.

How do based blocks get built?

It's time to break down the steps involved:

Ethereum is transactions. L1, L2, L3... it's all transactions and the ordering of those transactions is important because money can be made by controlling the execution order - known as MEV.

While many Ethereum rollups today have centralized sequencers which control the order of transactions, based rollups can be thought of as "permissionless blocks" that anyone can build.

In the simplest form, the Ethereum validator who is proposing the next block on the L1 could also choose to build blocks for Alice's and Bob's based L2s.

Why would the proposer do this? Well, the single transaction and blob they can build for those L2s might be offering a large tip!

This is great for the validator as they earn a higher return, though it's also a lot more effort. But don't despair!

L1 validators using MEV Boost today are already proposing L2 blocks without even realizing it. All the complexity is abstracted away to the builders.

Blob aggregation is critical to scaling.

Ethereum only has a small number of blobs available per block. If blobs become very expensive then only the largest rollups will be able to purchase them. Aggregating multiple smaller rollup blobs together offers a solution.

Even specialized appchains will be able to utilize all the benefits of based rollups without being shut out of the blob market!

Based appchains scale Ethereum.

The benefits of based rollups

• atomic synchronous composability

• improved developer experience

• more profits (MEV and fee retention)

• app specific customizations

• fast UX (with preconfirmations)

• credible neutrality

• censorship resistance