The Road To Based Applications

There’s been much discussion and excitement around based rollups. The reason for this is quite simple, based rollups are based. Specifically, they allow applications to stick to their underlying layer (+ retain synchronicity) - while gaining several superpowers that are usually reserved for rollups and app-chains (while deriving security). These are things like customisation, MEV internalisation and specialisation. The reason why we generally haven’t spoken about based rollups much in the past is that the implementation ideas in the past were generally centred around overloading the proposers and turning everything into singular chains - something that isn’t scalable in these hyper-decentralised systems. Furthermore, the UX of these setups (in the absence of preconfirmations or soft guarantees) just weren’t up to par for what applications would want.

In our view, the current dogma around based rollups has changed for the better. However, significant assumptions, what-ifs, and centralisation concerns remain. Underneath, we’ll give a simple overview of how based rollups were planned to work in the past, how current implementations work, and how an eventual ideal out-of-protocol implementation would look (and the in-protocol end-game).

In the past, the way based rollups were generally thought to be implemented in a way that was likely to either be cost-heavy, put significant pressure on existing proposers (and provide terrible UX) or be dependent on actors and middlemen that were outside the realm of usual Ethereum participants. This was because there were a lot of discussions specifically around having L1 validators also actively sequence and execute based rollup transactions (essentially turning it into a single chain, although with compression happening off-chain). Other ideas have centred around opt-in/opt-out but outside MEV-Boost, which, as we know, is responsible for most of the built Ethereum blocks - making an active integration out-of-protocol much more difficult to manage and gain traction for. As you’ll see later, we believe at least a first implementation of “efficient” based rollups is likely to happen within the MEV-Boost sphere of influence, as it makes integrations and conformity much easier.  

In any of the below examples and mentions of rollups keep in mind that compressions happen off-chains (and data posted to the L1 is done so in compressed form). We’re pretty used to this from existing L2s with their sequencers handling this work (and full nodes keeping the full state). In a based rollup, the compression work is a larger question since, in the below Taiko example, anyone can do this compression. In a MEV-Boost example this is likely done by searchers and builders that are also running full nodes on the based rollups. One caveat to make here is that similar to any other blockchain, the incentive to run a full node has to be created by there being significant traction on the based rollup. Either the amount of activity on the rollup has to be significant enough so that someone does the compression work or that searchers and builders become active there. Or in the initial bootstrapping phases they have to be additionally incentivised.

In terms of live implementations of based rollups on Ethereum to date, the most obvious example of this is Taiko, which functions quite a bit differently than described above. It also operates in a manner quite different from what a more integrated (pre-endgame) solution might look like. We give an overview of how Taiko operates below:

Taiko employs a separate L2 mempool where searchers participate in a just-in-time (JIT) auction to construct the most valuable L2 batch, similar to how Proposer-Builder Separation (PBS) operates on L1. These searchers bid to have their batch included by an L1 block builder, who selects the most valuable batch. This model can lead to L2 block builders competing to extract maximum MEV, mirroring L1 PBS.

In this setup, to get Ethereum synchronicity and composability, you would need the leading proposers and the known look-ahead subcommittee to be participants in the based rollup scheme. This is not the case at the moment, and blocks/transactions are, in theory, just forced in - which is very akin to centralised sequencers of today’s rollups.

An eventual out-of-protocol implementation of based rollups that fits into the current block-building pipeline (MEV-Boost sidecar) with full participation would likely be the next step in achieving the properties that most application developers wanting to build a based rollup are looking for. These properties are generally:

Properties:

• Composability
  - Atomic Inclusion; guarantees from one or more actors that a set of transactions will be included on domain(s) or none of them will
  - Atomic Execution guarantees a set order of execution (for example, via pre/post state commitments). It is needed for composability between applications.
  - Synchronous Composability; cross-chain contract calls.

  • L2 txs conditional on L1 state are possible today; in the other direction (L1-L2), you either need to prove state is correct at sequencing time (real-time validity proving) or the L1 sequencer set needs to be the same as L2 (hence integrations and collateralisation)

• Cross-Rollup Interoperability 

• MEV Retention/Internalisation

• Derive Ethereum security

• Customisation/Specialisation

• Fork Choices
  - Fair Ordering
  - Validity Conditions (oracle, gas token etc)

• Fast UX (with Preconfirmations)

A noteworthy mention of the MEV retention/internalisation aspect is that in most of the proposed setups, the Ethereum validators (inclusion powers) still hold quite some power, as they ultimately decide what gets into the block (and what doesn’t). As such, they will want to be paid some amount. You can almost picture rollups as searchers in the current paradigm (and as such, can derive some value from an auction).

What is very clear from the current state of Ethereum (and other monolithic chains) is that there’s a large number of applications yearning for customisation, specialisation and MEV retention while deriving Ethereum security (and synchronicity). We’ve previously covered the reasons for a modular setup quite in-depth in the articles here, and here as well as two recent presentations we did on why app developers will build modular here and here.

A MEV-Boost sidecar integration would likely end up looking somewhat like this, keep in mind that this requires that builders integrate with the supported rollups (unless we go straight to a MEV-Boost relay-esque setup, although this loses many of the above powers). The builders would likely end up as increasingly powerful entities, something we’ll get into later. The proposers are also required to opt-in (as they currently do with MEV-Boost), although if profits are higher for proposers running such a based rollup side-car, then others are likely to participate too (as most profit-seek).

Keep in mind that the L2 ticket auction is likely to be done in advance (in terms of which L1 proposer is supposed to include what L2 block). This is because the based rollup gateway protocol needs to ensure that the proposer has opted into the based rollup scheme. The gateway will know this since we also have the look-ahead of future proposers in the current/upcoming validator subcommittee (and can see who has opted in)

There are already a few proposals for how such an implementation might end up looking on Ethereum (both on the preconfirmation level but also with how based rollups would fit in):

For based rollups:

• Spire

• Taiko/Gwyneth

• Init4

For preconfirmations:

• Chainbound

• Primev

• Nethermind

• Commit-Boost

• Luban

However, there's no clear view on how this is going to be implemented fully (as in all MEV-Boost validators and builders participating), but it's very clear that these things are coming, and they're coming outside of the core protocol first.

There's also a clear desire to better support based rollups from within the core Ethereum community. Here we are specifically referring to wanting single slot finality but also faster block times - which lends itself much better to based rollups. These things are, as with most upgrades on Ethereum - quite far out. Preconfirmations/proposer commitments, on the other hand, are already in production both on mainnet and testnets - although they're seeing some considerable backlash from members of the community (again, centralisation concerns - we'll get into these more as we continue).

There are also some other interesting ideas (to provide preconfirmations) that make use of partial block building within a single MEV-Boost auction, by running several auctions within the usual timespan of one. In Based Preconfirmations with Multi-round MEV-Boost by Linoscope (Nethermind), the idea is that you have a fixed number of faster rounds in the MEV-Boost auction, where you build (and sign) a partial payload (of a block), this signing (from the proposer) acts as a preconfirmation. The full block (with the partial payload(s)) is then propagated as normal at the end of the normal slot. XGA above also makes use of similar ideas. However, instead of splitting up one auction into more, they split blockspace into two lanes - priority and non-priority. This is done to provide the ability (without enabling too much MEV) of selling future blockspace that is less leaky - meaning validators would be selling access to the non-priority blockspace (for preconfirmations). 

Keep in mind that things such as slashing, registry, and pricing are kept out for simplicity's sake

A preconfirmation protocol, as outlined in the diagram above, could be similar to what the Spire team proposed in their Preconfirmation Gateway; see here. The proposer/preconfer (likely having delegated the sequencer role) is known in advance via the Ethereum proposer lookahead. In the case of no active sidecar participants in the lookahead, a based rollup could likely use a fallback mechanism to elect a sequencer. Other use cases for the fallback mechanism (h/t mteam) could also be if a participant in the preconf sidecar has been slashed (or is out of collateral) 

While much of the above has focused on the intricacies of Ethereum and its road towards providing a platform for based rollups to shine, there are also other networks that can support them. Below, we will cover some of the places where based rollups can be built and networks specifically built to support them.

In terms of networks that could support (and are built to support based rollups) there are quite a few. Here is especially worth noting shared sequencers, which are essentially networks for sequencing (based) rollups:

• Shared Sequencers

  • Astria

  • Espresso

  • Radius

  • Nodekit

• Data Availability Layers (w/ Consensus)

  • Celestia

  • Avail

• Fast Monoliths

  • Solana (large ecosystem + properties that allow for efficient based rollups)

To summarize, based rollups are:

An off-chain state machine that delegates the sequencing of its blocks to the underlying layer (and its proposers). The sequencer is generally the winner of an auction or leader election (such as Ethereum's subcommittees and their subsequent slots). This sequencer is, in most cases (to avoid overloading), likely to be a proposer (that’s a part of the underlying layer’s set) tasked with inclusion; while it delegates/outsources the execution, constraints and building of the rollup block to more sophisticated actors (builders) - ala MEV-Boost.

Now that we’ve covered the whats of based rollups, it’s worth spending some time on the hows. There’s obviously nothing wrong with launching a based rollup right now, but quite a few changes have to be made around or on the baselayer to really support them in a way that makes them comparable to non-based rollups.

Obviously, it would make a ton of sense to have based rollups on a chain that is more suited to it (such as one with faster block times). However, since we're obviously interested in leveraging the decentralisation, censorship resistance and users alongside the liquidity of Ethereum, there are quite some changes needed here.

Although based rollups would also make a ton of sense on a Solana because of the faster/continuous slots, changes would need to be made (ie. sidecar) for sync functions to handle synchronous composability. Some interaction with Jito here (ala MEV-Boost) probably makes a lot of sense as well for the auctions and delegation. 

We've already mentioned a few of the requirements above, but let's cover all of them (to the best of our abilities) that we see as key to based rollups on Ethereum, Solana and Celestia.

For Ethereum, the requirements (for proper UX and the gaining of the properties outlined further up):

• Preconfirmations

  • Inclusion guarantee

  • Execution guarantee

  • In/out of protocol 

• Integration into the block building pipeline (MEV-Boost) via sidecar for based rollups with preconfirmations

  • Custom block validity rules

  • Super-builders

  • Spectrum of guarantees (sequencing/validation) 

  • Sidecar for synchronization

• Not overloading Ethereum consensus (hence the spectrums above)

• Non-builder+relay full node runners

• Faster block times (Vitalik was recently pushing for 2-4s, however; this is probably quite far out as we'd need significant changes to the protocol specs and consensus) - faster block times would also make preconfs less important, although integrations within schemes help improve synchronization.

• Keep in mind that the 12s block time is worst case scenario, most users aren't sending transactions at the beginning of a slot (median inclusion time likely to be 7 seconds when accounting for latency and end-of-slot non-acceptance of txs within MEV-Boost)

For Solana, the chain actually lends itself extremely well to support-based rollups. It has "fast" (in this case, continuous) block times, which provides fast deterministic consensus (a wanted property in the absence of preconfirmations for based rollups). There are, however, still issues that remain here, for example:

• Integration into the growing block-building pipeline in Jito

• Side-car for sync functions and synchronicity 

• Not overloading Solana validators (already heavy requirements)

  • Super-builders?

• Decentralisation of block building pipeline 

On a side note, we're already seeing based-like structures (ZK Compression) come to market on Solana, alongside renewed interest and funding in projects enabling/building rollups on Solana. ZK Compression, in some ways, works a lot like a based ZK-validium. This is generally because even though Solana is obviously an extremely efficient single state machine, it is becoming rather bloated - and apps don’t have customisation control nor mev internalisation.

For Celestia, there are actually a lot of properties that lend themselves very well to based rollups. There's the ease of verifiability with light clients, plenty of blockspace and a "lazy" base layer that provides consensus. There are a few changes that would make it even better for based rollups:

• Faster block times for better UX in the absence of preconfirmations

• Standards for cross-based-rollup interoperability (preferably atomic)

• ZK accounts for base layer asset velocity (preferably coupled with real-time proving)

As mentioned above, there's quite a spectrum of how based sequencing can be implemented natively (or out of protocol) to allow synchronization. This spectrum is quite relevant in the current (and older) discourse since it very much fits into the "don't overload Ethereum consensus" and the grace of homestakers. Many of the implementations that would allow for execution and sequencing guarantees (from the entire or a subcommittee) of validators would very much overload Ethereum consensus. As such, we find it vital to cover this topic a little bit more:

• Based Sequencing

  • Sequencing is done by a subset (or the entire) underlying layer's proposers - meaning that they'll need to run execution full nodes and actively build blocks

  • Overloads validators with state bloat, hardware requirements and vertical scaling

  • Likely to be delegated to specialised actors - the rise of super-builders

• Based Validation 

  • Sequencing is done by sophisticated actors specialised in block building, constraints and pricing

  • Inclusion guarantees are provided by proposers initially, and proposers might validate the execution validity later on (this is likely still an overload of current proposer specs, and we're likely to only get inclusion guarantees as outlined below)

    • In a perfect world, the L1 proposers would be sophisticated enough to handle all load (network/compute) and run L2 nodes. However, this is unlikely, and it is reinforced by their likely unavailability to price pre-confs/based roll-up blocks themselves. Hence, delegation.

Furthermore, as we've also seen, there are, at least pre-faster blocks, a need for preconfirmations. There's still much debate about how this will get implemented, but it's certainly worth considering already. As a refresher, preconfirmations are commitments about future inclusion or execution provided by proposers or delegated actors that have the ability to lock or provide access to state at designated times. In based rollups, this is significant because proposers can provide guarantees that a rollup block will eventually be executed/included. There is obviously likely to be a significant slashing of bonds imposed onto actors in such schemes to ensure that commitments are honoured. This is in an ideal world in-protocol since out-of-protocol reverts to social slashing by a small subset of people rather than the entire protocol's social consensus.

• Inclusion Guarantees 

  • Delegation of execution, block building and sequencing

  • Guarantees that blocks/txs will be included in a block (but not that they'll be executed by execution clients) or put in a specific order

  • Inability to ensure composability between applications 

  • Easier to price

  • Collaboration by the outsourced sequencer (builder) and proposer (relays likely play the usual role, although strain here is likely too)

• Execution Guarantees

  • Real-time validity proving or collateralisation.

  • Puts a heavy strain on proposers

  • Harder to price

  • Important if we consider that based rollups might synchronously touch the Ethereum L1 state - wherein app composability requires execution guarantees

While preconfirmations are quite limited in use at the moment, the wider scope is extremely broad and can provide a rather flexible baselayer for proposer commitments. The current properties of proposer commitments (outside of preconfirmation/commitment sidecars) are limited to state confirmations at block construction (meaning every 12 seconds). However, there are already a few out-of-protocol commitment schemes (such as Chainbound) that can enable the proposer to issue commitments to others about their specific block while supporting a key based rollup property in inclusion preconfirmations. Which, as outlined above, is something we're extremely keen to have. If you're interested in out-of-protocol preconfirmations, we highly recommend this talk by the Chainbound team.

Beyond just faster blocks for better UX, there are also other key points that preconfirmations would bring to the table (beyond being used for based rollups). Here are things such as: 

• Solvers/Chain Abstraction UX

• MEV mitigation/capture

The endgame of proposer commitments is extremely broad, and the general idea is that they'll be able to support even more use cases, such as:

• Partial block building (multiple concurrent proposers)

• State preconfirmations (synchronicity/sync functions) + cancellations

• L1 blockspace auctions and claims

In terms of in-protocol commitments and block proposal rights, there are several proposals and implementations being discussed, such as Protocol Enforced Proposer Commitments (PEPC) and Execution tickets (ET) (+ attester-proposer-separation (APS)). ET is seeing significant focus as they would allow for an in-protocol market (lottery) for block proposal purchasing rights. The idea around APS is that you split L1 validator roles into two separate ones - an Execution and a Beacon (consensus) proposer. The former would be tasked with proposing the block payload (the building of this is likely outsourced to builders, or we get builders to play this part). The latter (beacon, or attesters) would be tasked with voting on set block validity rules (especially important with based rollup blocks as more rules are likely outlined) and constrain execution powers through inclusion lists. This is likely (especially in a world of super-builders and centralisation concerns around preconfirmations and based rollup) to provide higher censorship resistance. If you're interested in preconf history (check this out).

As you might have noticed over the course of this article, there's a lot of delegation and outsourcing of work to more specialised actors either in the name of avoiding overloading or to ensure better market efficiency. What this means is that, and what it leads to has been happening for a while on Ethereum - a clear road towards putting most of the hefty work in the hands of the builders (highly sophisticated entities). This is leading to what has been coined as "super-builders".  The group of current builders within the MEV-Boost pipeline will likely also play key roles both in protocol (and out) for based rollups, preconfirmations and commitments.

The reason for why is quite clear, we don't want to overload Ethereum's consensus. We can't require every proposer to be as specialised, nor are they able to. It's general market forces, but it does lead to centralisation, and with that comes many risks. This is already in effect today, with 3 builders building the vast majority of Ethereum blocks today (with two of them, Titan and Beaverbuild, building almost 80%!). Proposers today also have an extremely trusted relationship with relays (which is hoped to be lessened by the advance of ePBS, although this is still not clear yet)

The builders are likely (in a based rollup case) going to be running full nodes on the rollups for sequencing, execution guarantees and block-building reasons. At the same time, they need to be able (in the preconfer case) to price these blocks/bundles correctly (some builders might outsource this preconf pricing to searchers). Inclusion guarantee preconfirmations are much easier to price, while execution guarantees require significant sophistication, and are still an open question.

On the subject of based rollups, a super-builder can generally be thought of as a specialised actor that isn’t building for a single chain (Ethereum) but a group of them (Ethereum+Rollups). This is needed, especially if we want intra-block synchronicity and cross-domain rollup interoperability. To some extent, you could also view Optimism's Superchain sequencer/builder as a super-builder of OP-Stack chains. As well as the decentralised sequencer networks of Astria/Espresso (but more multi concurrent, if no single leader). An interesting aspect of the delegation to builders is that a ticket holder of multiple rollups can provide inclusion guarantees for synchronous composability across these domains.

The term super-builders could also be used to refer to the extracurricular activities that they might take on outside of their original duties (building blocks!), such as commitments, and preconfirmations.

In all of these cases, we likely need significant bonds (stakes) for builders, especially with the growing work delegated to them. Preferably, a lot of these functions outsourced to them should also be provable on-chain (in-protocol) to ensure fair, robust and correct slashing. This signals an increase in horizontal scaling on the builder side (which Justin Drake offhandedly said they were fine with?). There are quite some worries here, such as multi-block MEV, a builder building for way more rollups than all others (or better at extracting MEV), and possibly out-bidding all other builders consistently. This further sophistication and optimisation are also, as with everything, going to lead to further centralisation and a higher barrier to entrance for new participants (unless they're Citadel). One thing that does seem quite clear is that at least Inclusion Lists (IL) are sorely needed in a world where builders are empowered even more.

This is all on top of the fact that the flow is increasingly moving off-chain/towards private order flow. Builders with exclusive providers (and ones that are integrated) do much better than the ones without, and these few are also the ones likely to profit the most of any based rollup integrations. This could also be worrying in the case where some applications (or Telegram bots) might have a rollup and also have exclusive flow towards a builder. Burak Öz, Danning Sui, Thomas Thiery, Florian Matthes highlight these issues well in their recent paper Who Wins Ethereum Block Building Auctions and Why?, especially around the high barrier to entry issues presented above.

An interesting caveat to this heightening of work put on the builders is that in terms of profit distribution, they're (at least on-chain) the ones receiving the least. Although since two of the three key builders are also prop shops the searcher profits are obviously much in their camp as well. Even the non-trading builders are likely to have agreements with searchers for revenue share since they don't trade on their flow. Currently, as pointed out by Yuki (Sorella/Fenbushi), the MEV to non-MEV profits are split roughly equally there's a large amount of profits kept on the table for applications, which often end up in the hands of proposers.  

One thing that it does make extremely clear is that there's a huge opportunity for applications (or projects) that allow/can capture (meaning internalising) their own/others' MEV. Clearly, in this day and age, with the amount of economic activity on-chain, it will likely mean they can outcompete those that cannot. These margins left on the table are opportunities for protocols that allow applications to become better and more efficient.

As mentioned much earlier, there are quite a few reasons why you'd build an application as a based rollup—especially if you're already entrenched and deployed on the underlying layer. Let's take an example of how an application might launch as a based rollup while keeping its existing contracts on the L1. 

In the case of Uniswap, you could have the Uniswap Router live in the based rollup, and have applications make calls through the rollup (meaning Uniswap would get to hopefully internalise part of the flow that runs through them via an auction). For example, an intent protocol that would want to touch L1 Uniswap liquidity would have to make the call through the router on the based rollup. 

This would likely also play alongside synchronicity to have functions created as a result of based rollup actions that could be executed on the L1. This would be interesting since applications would have access (at least read) to Ethereum and in the future, possibly make calls to and from its smart contracts. This is something that especially Uniswap would want since many applications are making calls to its routers/contracts every single block (think most of the intent protocols, and many others). The same goes for Aave, Maker and so on.

In the case of how a Uniswap (and all other applications that would want to internalise their MEV revenue) might pick a sequencer, it would likely be one that is willing to pay to sequence a block - which would mean returning some value to the application. In a world of a few of these types of actors, the likelihood of it reaching the exact total amount of possible returnable value is quite low, unless all actors have complete information symmetry between them and are able to all bid to the upper limit (although at this point you'd expect some collusion to start happening). 

• As is probably clear throughout the entire article, there are significant assumptions around how this is all going to end up and how it affects certain aspects of the protocols we use today. The timeline is also unclear, especially when its related to things in protocol. 

• However, what is clear is that there’s a large ecosystem of applications on very well-developed monolithic chains that yearn for the ability to customise, internalise, and derive security while being composable. 

• Order agnostic sequencing for specific applications (ie. see our ordering article) - not just MEV internalisation, but also verifiable sequencing rules, frequent batch auctions, fair ordering etc.

• Rollup specific fork choice rules (eg. valid blocks only if oracle pricing update)

• Optimal block validity (beyond highest fee), can be quite arbitrary (something different than => maximise value for example)

• Block builder sophistication and horizontal scaling needs more research around the danger (+ multiblock mev, block bids); how does this change with opcodes/gas limits/VMs/fork choice rules specialisation. 

• Partial block building + Multi concurrent proposers

• Constraining block builders with in and out-of-protocol Inclusion Lists

• Pricing for non integrated builders if delegated to (out delegate to searchers?)

• Rollup payment for orderflow

• Continuous block building (ala Shreds on Solana)

• Timing games and effects (+ attester wrong head votes)

If you're an application currently living on a monolithic singular chain and you're interested in exploring how you might be able to start taking advantage of aspects of modularity (as we've touched upon many times over the past year) while staying composable and aligned with the underlying layer, feel free to reach out to us. 

Further Reading: 

• https://research.chainbound.io/examining-the-based-sequencing-spectrum

• https://ethresear.ch/t/based-preconfirmations/17353

• https://mteam.space/eth-sequencing-preconfs-resources/based_rollups.html

• https://github.com/spire-labs/poc-monorepo

• https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

• https://scalability.guide/posts/forced_vs_based/ 

• https://blog.20squares.xyz/preconfirmations-splitting-the-block/

• https://mirror.xyz/preconf.eth/3SXageNPpcQMz8L2YfW5ipvthNl-InPzaPAfb3LxwqA

• https://vitalik.eth.limo/general/2024/06/30/epochslot.html 

Thanks to Mathijs van Esch (Maven11) and mteam (Spire) for review.