Make Ethereum Whole Again

We would like to personally thank Justin Drake, Jason Vranek, Amir Forouzani, Jünger, Murat Akdeniz, Harry Gao, Kaito Yanai, mteam, Francesco Mosterts, Josh Bowen, and Raghav Agarwal for their valuable insights and review of this report.

Ethereum’s shift to the rollup-centric roadmap has allowed for faster transactions by processing them off the main chain, increased aggregate throughput, reduced costs, and enabled new applications (e.g., in SocialFi and GameFi) that require low latency. 

However, it has also created fragmentation and centralization concerns at L2, while also raising doubts about value accrual to the L1. For instance, following March’s Dencun (EIP-4844) upgrade and the introduction of blobs, Optimism’s margins have skyrocketed into the range of 98-99% while Arbitrum’s have reached 70-99%. In contrast, the margins in the months before rarely reached 50%.

The value flow out of Ethereum L1, due to blobs reducing data availability costs, is good for making rollups cheaper, but it also has contributed to a dramatic loss in network demand and revenue accrued at Ethereum L1. Under EIP-1559, this leads to more Ether being issued than burned, threatening long-term economic security. However, with network demand increasing, blob supply saturation should happen in the coming months, with revenue at Ethereum L1 recovering.

Regarding fragmentation, each rollup operates independently, lacking seamless value transfer between them. Rollup funds are locked in a bridge on Ethereum, so moving assets can be cumbersome and inefficient (e.g., hours to move between ZK rollups and days for optimistic rollups). The lack of interoperability limits the potential for a cohesive and integrated blockchain ecosystem. 

Each L2 has its own pool of liquidity, creating difficulties in accessing sufficient liquidity for efficient trading and application development across the Ethereum ecosystem. Because some L2s have a lot more liquidity than others, they attract more users (and thus even more liquidity), leading to winner-takes-most dynamics. Larger L2s benefit at the expense of smaller or newer ones.

And it’s potentially not a zero-sum game but a negative-sum game, according to Metcalfe’s law. When liquidity is fragmented across L2s, it could prevent some L2s from realizing their full potential value in meeting their specific trading and application demands. Economies of scale driven by network effects would be diluted across different L2s, with newer and smaller networks more likely to face liquidity challenges due to limited connectivity with the bigger established networks.

This fragmentation creates friction for developers and users alike. Developers must carefully choose which rollup to build on, considering user profiles and existing ecosystems. Meanwhile, users face decisions about where to park their assets, with transfers between rollups being slow, costly, and incurring security risks due to bridge dependencies. This lack of composability results in a poor UX when it comes to interacting with contracts across different rollups.

Then there’s the issue of rent extraction. L2s today are all run by centralized sequencers who order and process the transactions, with full decision-making authority over how L2 transactions are handled. Users are rightfully concerned about what they are doing – are they extracting rent by frontrunning your transactions? Users have to trust that the reputation at stake of single sequencers is enough to continue preventing such practices. There are also the common centralization risks of censorship and liveness to consider. 

While Ethereum also deals with rent extraction, it works very differently because there is leader rotation among a huge number of validators, reducing the likelihood of a single entity exploiting users. However, in practice, Ethereum validators collectively still engage in frontrunning through MEV-Boost and searcher priority gas auctions (PGA) in the public mempool. This implementation of proposer-builder separation (PBS) allows validators to outsource block building to specialized builders who optimize transaction ordering for profit. As such, even if you tip enough for a transaction and one builder is willing to include it, it is difficult in practice to not be frontrun through other builders as a group through MEV-Boost. This dynamic underscores the complexity of achieving true decentralization and fairness in transaction processing on Ethereum as well.

To solve the centralized sequencer and fragmentation problems, shared sequencing layers have emerged. Projects like Astria, Espresso, Nodekit, and Radius aim to create a unified sequencing layer that can coordinate transactions across multiple rollups. They work by connecting multiple rollups into a single network using a consensus protocol (e.g., BFT), then electing a single sequencer to order transactions. This allows for a common mechanism to determine the order of transactions and provides fast L2 finality and composability between rollups. 

Alternatively, rollups-as-a-service (RaaS) providers (e.g., Stackr, Presto by Gateway, Conduit, and others) are also well-positioned to provide shared sequencing as they already manage multiple rollups on multiple frameworks – something to pay attention to if this direction gains traction.

The addition of a shared sequencing layer is potentially beneficial in terms of decentralization, finality, fast transactions, cross-chain atomicity, and MEV distribution among participating rollups. By adopting a shared sequencing layer, existing rollups can achieve these benefits without the extensive engineering effort typically required to decentralize them independently, as it streamlines the process and leverages collective infrastructure. 

Another potential benefit is that some institutions may prefer to utilize a shared sequencing layer using their own permissioned/KYC’d validator set over a random subset of open validators at the base layer, since those sequencers need to inspect the transaction payload and decide what to do with it.

However, introducing a new shared sequencing layer also introduces new trust assumptions. Unlike individual rollups, which rely on their own security mechanisms and the Ethereum mainnet, a shared sequencer layer needs its own clearly defined security setup. Users and developers must trust that this new layer is secure and reliable as it becomes a critical component in transaction ordering and value transfer between rollups.

Additional concerns include:

• Revenue sharing: To incentivize a decentralized set of entities to sequence transactions, rollups will have to share a percentage of their current revenue.

• Network effects: The effectiveness of shared sequencing depends on the participation of many rollups. If a rollup leaves, it reduces the quantity of transactions and diversity of dapps that can be composed with.

• Decentralization risks: Without robust decentralization, shared sequencer networks themselves can become a single point of failure. However, it’s equally important to ensure that nodes within a decentralized network maintain high quality to uphold fast transaction commitments, security, and reliability.

• Liveness risks: BFT consensus assumes that at least half of the validators are online and honest – if this assumption fails, the shared sequencing layer’s liveness is compromised.

But what if instead of introducing a new layer for shared sequencing, we use the Ethereum base chain for shared sequencing – aka “based rollups”? The key distinction being who is sequencing – instead of a centralized sequencer or shared layer, re-using Ethereum builders (with searchers and proposers) to pick up pending transactions in L2 mempools and order them. As these builders sequence both the L1 and L2 blocks, there is no need to rely on the L2 single sequencer to manage transaction sequencing. Instead, the design leverages Ethereum’s existing builders and proposers, providing arguably the most reliable and credibly neutral transport layer for transactions.

To draw a comparison, consider the blockchain stack, including execution, settlement, consensus, and data availability in a traditional rollup (optimistic, ZK) vs. based rollup:

Here, “consensus”  is loosely defined – in the case of traditional rollups, there is only a single sequencer determining transaction order: (1,1) consensus. In the based case, the rollup is re-using Ethereum as it exists today to sequence transactions. So, we could also label this box as “sequencing.” 

Note that there can also be based sovereign rollups (e.g., a social app chain) that rely on a base layer (e.g., Ethereum, Celestia) to order blobs, and then the validity of blobs is checked by client-side software (i.e., they do their own settlement; there is no canonical chain). Since transaction validity is checked by client-side software instead of a validating bridge, they (a) don’t need to know the L2 state on L1 (e.g., for withdrawals) and (b) don’t need fast trustless syncing against a verified state root as they standalone without needing to interact outside their own ecosystem.

Based rollups address three key challenges highlighted above that are facing Ethereum’s current L2 landscape:

1. Security: Based rollups leverage Ethereum’s validator set, inheriting some security properties of the main chain. This approach reduces certain risks associated with centralized sequencers, such as single points of failure, censorship, and liveness risks. However, it could introduce new challenges. For example, if the system lacks support for private RPCs (fka Preconfirmation Gateway), searchers have maximal opportunity to exploit transactions and their associated MEV. However, the existence or lack of private RPCs ultimately boils down to choices made by wallets and builders – it is not an inherent feature or limitation of based rollups themselves. Spire is working on a solution here.

2. Composability: Based rollups aim to improve composability by facilitating interactions between smart contracts across different rollups and between rollups and the base layer.  By utilizing Ethereum’s validator set for sequencing, based sequencing is a special type of shared sequencing. This design allows any rollup using based sequencing to leverage Ethereum’s decentralized infrastructure, thereby facilitating composability and reducing fragmentation. The shared approach helps integrate various rollups and the base layer more seamlessly, improving UX and enabling more efficient cross-chain interactions.
   
   Taiko’s Gwyneth is an example of a based rollup with horizontal scaling architecture designed to achieve atomic composability in both L2-L2 and L2-L1 scenarios. However, achieving true synchronous composability – where contracts can interact at the same slot height – is a hard problem. It depends on whether the bridge will allow L2 to L1 message passing in real-time (either using TEEs or using real-time SNARKs), and whether another bridge will accept those messages very fast. If these conditions are met, at least partial synchronicity is possible, which will bring us closer to synchronous composability and a single-chain-like UX. Until then, perhaps the best solution to cross-rollup composability are fast bridges (e.g., Across Protocol, Orbiter Finance, deBridge), but these work essentially by swapping assets across chains rather than actually “moving” assets, requiring sufficient liquidity on each side of the bridge.

3. Economic alignment: While based rollups have the potential to allow MEV generated by rollups to flow back to Ethereum L1 validators participating in sequencing (e.g., in Puffer UniFi and Taiko’s design), this is not a hard and fast rule. In practice, applications and wallets may retain most of MEV for themselves, reducing MEV flow to sequencers. Furthermore, many L2s would prefer to capture MEV for themselves, viewing “L1 alignment” as a disadvantage. With that said, the use of execution tickets (a la Spire and Espresso) would allow L2s to capture MEV even in the context of based sequencing, by effectively decoupling the right to capture MEV from L1 validators. Also, with better composability, based rollups can still economically benefit Ethereum by growing the network effects of its blockspace, increasing traffic and congestion fees, even if MEV revenue is not directly increased for L1 proposers.

The main challenge to implementing based rollups has to do with how fast transactions can be confirmed by based-decentralized sequencing vs. L2-centralized sequencing. While based rollups offer numerous advantages in terms of decentralization, security, and economic alignment, they simply cannot provide fast transaction confirmations like centralized sequencers due to block time constraints.

Ethereum’s block time is approximately 12 seconds, which means that any rollup that is “based” on Ethereum inherits this constraint. The long block time can slow down transaction confirmations and diminish user experience. It creates a bottleneck for applications requiring rapid response times (e.g., GameFi, high-frequency trading).

With centralized sequencers, users can get a weak form of transaction preconfirmation known as “soft confirmations” which are immediate promises that a transaction will be included in a future block before that block is confirmed onchain. Despite the possibility of those promises falling through, users trust in them because there is only one sequencer making the promise, and that sequencer fully controls the transaction ordering and processing.

Things are different in a decentralized setting, where there is no single entity to offer such assurances, so it’s difficult for users to have the same confidence in the promise of inclusion of their transactions in a specific block – maybe one validator makes a promise but another is selected for proposing the next block. At the same time, it is essential for based rollups to be able to offer a similar credible promise of transaction inclusion and execution to offer a comparable (or better UX) than current centralized rollups. So what is the solution?

In November 2023, Ethereum Foundation researcher Justin Drake proposed based preconfirmations to make based rollups as performant as traditional rollups while preserving decentralization benefits. While preconfirmations have roots dating back to 2012, in discussions on early transaction assurances on Bitcoin known as “0conf,” Justin’s proposal is fresh and timely amidst currently hot debates around L2 centralization, fragmentation, and L2-L1 economics.

Preconfirmations (“preconfs”) can offer enhanced transaction processing for based rollups. They provide robust mechanisms for offering early assurances about transaction inclusion. Users get stronger assurances from validators that a transaction will be included.

With based preconfs, Ethereum can capture not only L2 tips for transaction ordering and blob fees, but also preconf tips when they arrive. The assumption is that these fees will motivate Ethereum proposers to offer preconfs-as-a-service (PaaS) – becoming more sophisticated actors in the process. Basically, the approach would involve a standardized protocol where users can pay tips to receive an immediate guarantee that their L2 transaction will be included in the next L1 block, potentially with a claim about the results of executing that transaction. If a proposer fails to fulfill that promise, they risk being slashed.

By providing early assurances, preconfs can reduce execution risk related to blockspace contention and transaction ordering. This is particularly important in environments where MEV-seeking can lead to transaction delays or reordering.

Another benefit of using preconfs is that they allow pricing signals to naturally flow to the sequencer or gateway. This can lead to a more efficient auction, resulting in more valuable blocks compared to PBS, where price signals are fragmented across builder auctions. By consolidating price signals, preconfs can improve the efficiency and value of block production.

There are two main types of preconfs: inclusion preconfs and execution preconfs. The former is simpler in that the focus is only guaranteeing that the L2 transaction will be included in the next L1 block. The latter provides this guarantee plus a claim about the results of executing that transaction, which is more complex as it requires simulating the transaction and full synchronicity – meaning that the sequencer needs full control over ordering. Currently, most of the development is focused on either L1 inclusion preconfs (e.g., Bolt) or L2 execution preconfs for based rollups (e.g., Puffer, Taiko).

Up to here, we’ve covered the evolution from traditional rollups to shared sequencer networks to based rollups to based rollups with preconfs. The figure below visualizes the transaction lifecycle between these approaches and highlights their differences:

Now, let’s focus on how based rollups with preconfs could improve Ethereum’s UX, which is currently facing a serious fragmentation issue.

• Stronger assurances: Preconfs promised by Ethereum proposers are designed to enhance the reliability and efficiency of transaction processing within based rollups. They provide stronger assurances than the soft confirmations of centralized sequencers because users can enforce them via programmatic slashing and arbitration. This ensures a high degree of reliability in the decentralized base environment. A caveat here is that technically any rollup can adopt programmatic slashing and arbitration – so preconfs don’t have any special capacity to offer these stronger assurances, they simply choose to do so.

• Fast confirmations: Based preconfs can achieve nearly instantaneous confirmation like centralized sequencers. In test environments, Taiko achieved based preconfs in ~20 ms. This speed is crucial for applications requiring rapid response times, such as in high-frequency trading and gaming.

• Gasless transactions: The yield generated by preconfers can be shared with stakers supporting the protocol to subsidize gas fees. For example, Puffer UniFi’s architecture enables gasless transactions by leveraging the native yield generated through its liquid restaking token (LRT), pufETH. Users who stake pufETH to join UniFi share yield with the Puffer preconfers, enabling gasless transactions that set it apart from traditional rollups. Even if the savings per transaction is just a few cents, a few cents a thousand times becomes substantial.

• Decentralization: Unlike centralized sequencers that introduce single points of failure, liveness risks, and censorship risks, preconfs leverage Ethereum’s decentralized validator set, aligning with goals for credible neutrality and censorship resistance. A caveat here, however, is that with based preconfs, you don’t inherit all of Ethereum’s liveness and security because only a subset of Ethereum proposers have accepted the responsibility of providing preconfirmations-as-a-service (PaaS).

• Ecosystem integration: Preconfs can facilitate smoother interactions across L2 and L1 by eventually achieving synchronous composability between the two. This allows smart contracts across all based rollups to interact seamlessly within a single transaction, reducing fragmentation and providing a more unified network. With the L1 proposer also acting as the L2 proposer, you can get atomic inclusion guarantees like those achieved by multiple rollups using an out-of-protocol shared sequencer. Atomic inclusion means that “super builders” operating across chains can extract MEV more efficiently as they don’t need to price in the risk of one leg of the cross-chain bundle failing.

  

• Social alignment and credible neutrality: Last but not least, being aligned with Ethereum provides a significant advantage in terms of credible neutrality. Based rollups can leverage this alignment to attract cross-ecosystem users and developers who prioritize decentralization and neutrality.

We could be witnessing a transformative moment like the development of the Fedwire system among regional banks, which allowed funds to be transferred rapidly and efficiently across different institutions. While Fedwire operates by settling cross-bank transactions using centralized bank money, based rollups with preconfs offer a decentralized version where a network of sophisticated MEV-seeking Ethereum proposers working with searchers and builders provide seamless and rapid asset transfers between distinct entities. 

While the incentive-alignment approach is leading in the based preconfs space, where Ethereum proposers can opt in to join a PaaS network, it is only one of three ways to achieve unification:

1. Uniformity: This approach involves standardizing operations across sequencers to prioritize a seamless UX over individual MEV profit maximization (the sequencer state today). By enforcing uniform behavior among sequencers, this approach can achieve hard guarantees of commitments. While this is good for sequencers who are not sophisticated MEV actors, it is restrictive for sophisticated sequencers seeking to optimize orders for their own economic benefit. That said, it can lead to more optimal outcomes across the network by offering hard guarantees of commitments. Examples: Astria, Espresso, Nodekit SEQ.

2. Incentive alignment: This approach focuses on aligning incentives for sequencers without imposing strict uniformity. Proposers can opt-in to join a PaaS network based on bids they receive on how to order transactions. This method offers flexibility and potential for increased MEV extraction while proposers retain optionality. However, it lacks the hard guarantees provided by the uniformity approach, as proposers can opt out of commitments if it’s not economically favorable for them. Examples: Puffer UniFi, Taiko, Primev.

3. Appchains: Another alternative is to have all chains based on the same framework, sharing properties to have seamless interoperability built in. While this approach works well for those built using the same framework, it doesn’t work well for interoperability with chains based on different frameworks due to different technical standards, consensus, and governance. Unless everyone agrees on the framework, you end up with federations of rollups that aren’t synchronously composable. Examples: Spire, Polygon CDK, OP Stack, Arbitrum Orbit, Cosmos SDK; see also RaaS.

All of these approaches have the same goal of unification, and they could potentially exist all together. In terms of Ethereum alignment, unification has the net benefit of shifting from the negative-sum game of fragmented rollups to the positive-sum game of socially and technically aligned rollups.

The introduction of blobs through EIP-4844 which went live on March 13, 2024 has significantly lowered operating costs on L2 and led to decreased Ethereum revenue and ETH burn rates. Nevertheless, there is already a proposal in place to increase blob count per block. 

Compared to calldata, blobs are a much cheaper way for rollups to store data on Ethereum mainnet, as can be seen in the sudden drop in L2 operating expenses calculated as (Call Data + Blob/ Type-3 Transaction + ZKP Costs) shown below.

Likewise, there was a dramatic decrease in revenue following EIP-4844. The chart below compares the 150-day rolling sum of total revenue before EIP-4844 to total revenue 150 days after EIP-4844. Total revenue from blobs is calculated as (Blob Base Fee Blob Gas Used) + (Base Fee Calldata Gas Used) + (Priority Fee Calldata Gas Used­) while the total revenue calculated from calldata batch commits is (Base Fee Calldata Gas Used) + (Priority Fee * Calldata Gas Used­).

Based rollups with preconfirmations could help balance economic benefits between L1 and L2.

One of the hardest challenges facing based rollups is competing against the current throne of centralized rollups that lack obvious incentives to adopt a based approach or decentralize sequencing. The ongoing debate around this is complex and full of nuances.

Many claim that L2s are disincentivized to decentralize because they would lose “sequencer fees” which accrue entirely to each rollup’s single sequencer. However, “sequencer fees” can be seen as a misnomer in the context of current L2s if the revenue that L2s (like Base) generate comes primarily from execution congestion fees (similar to EIP-1559 base fees) due to high demand for blockspace, and is not directly tied to sequencing itself.

But, further data suggest that’s not the case (see this post too). Most of Base’s revenue is derived from priority fees, not the EIP-1559 base fees, which would be hard for a decentralized sequencer network to capture without strong censorship-resistance mechanisms. In addition to rent extraction through MEV, centralized sequencers can lead to issues such as censorship, which runs counter to Ethereum’s ethos of decentralization and trustlessness. With MEV and sequencer priority fees intertwined because both affect the order of transactions, MEV opportunities could influence how sequencers order transactions, affecting the fees users are willing to pay for ordered transaction inclusion.

In short, the data and bundling of priority fees and MEV opportunities suggest strong disincentivization for L2s to decentralize sequencing. L2s benefit from capturing MEV internally and, on top of that, applications and wallets are incentivized to retain MEV for themselves, further reducing MEV flow to shared sequencers. 

One potential balancing mechanism is the use of execution tickets (a la Spire and Espresso), which effectively decouples MEV from validator rewards by allowing validators to auction off their slot to execution proposers who can be L2 entities. So L2s could still capture MEV even in the context of based sequencing.

But perhaps the strongest argument for L2s to decentralize is to maximize composability to “grow the pie” for all L2s in terms of traffic and congestion fees. One argument is that L2s are disincentivized to exploit MEV as it degrades cross-chain composability and execution quality for their users. Instead, for L2s to maximize their revenue, they would want to maximize the congestion (base) fees, which means maximizing composability and execution quality across the board.

This brings us back to based rollups with preconfirmations for sequencing. Ethereum is arguably the best candidate here as a credibly neutral, decentralized, and permissionless shared sequencer to maximize composability without introducing new out-of-protocol layers and security assumptions. Furthermore, decentralizing sequencing on Ethereum L1 could be the safest bet against regulatory risk facing centralized sequencers. 

There’s also the other possibility that going based just doesn’t happen for most established L2s if they can keep their activity. Instead, the based approach is more attractive for new L2s, where the economics are less favorable starting day one with a centralized sequencer. And, if going based or using decentralized shared sequencing becomes more normalized, it can be a hard ideological argument to make for new L2s to launch with a single sequencer.

It is much easier to see how going based can benefit Ethereum L1 than the current L2 landscape, with based sequencing creating MEV opportunities at L1 – this is where “sequencer fees” make more sense.

New incentive structures. Based preconfirmations introduce a new layer of economic incentives for Ethereum node operators. By offering PaaS, these actors can charge additional fees (preconf tips) for guaranteeing transaction inclusion in upcoming blocks, potentially with a claim of the results of that transaction. 

This is especially important in the context of Ethereum economics following the Dencun upgrade, where blobs have made L2 transactions much cheaper by reducing the cost of data availability at L1. As Ethereum’s roadmap increasingly focuses on rollups for scalability, the demand for L1 blockspace may continue diminishing, reducing priority fees – and thus, economic security – yet further.

Improved MEV dynamics. Granting the ability for Ethereum nodes to strategically position transactions within a block allows the opted-in subset of node operators to prioritize transactions that offer higher fees or have strategic value, such as in frontrunning or backrunning opportunities. The new base layer of economic activity effectively creates a new revenue stream that complements existing transaction fees and MEV opportunities. 

However, preconfirmations could also make some traditional forms of MEV extraction more challenging by locking in transaction ordering in advance. If the transaction order is locked in (e.g., with Primev’s mev-commit or Commit-Boost), traders can strategize around predictions of what that locked-in order is. Furthermore, with execution preconfs that guarantee transaction outcomes, it’s possible to mitigate toxic MEV (e.g., frontrunning, sandwich attacks) – mev-commit also does this for preconfs at L1 and future developments could implement it for based preconfs as well.

Preconfirmations allow more efficient MEV extraction because they reduce the risk involved in building the transaction for extracting MEV. With pre-execution privacy via end-to-end encryption, competing bidders and providers can’t observe and adjust their strategies based on visible bids, preventing them from outbidding or undercutting others, and preserving fairness in a competitive and decentralized environment.

Privacy is going to be an important feature here because current PaaS providers are asking MEV seekers to send them their transactions and trust what they are going to do with it. But without privacy baked in, those services can do things like Robinhood, selling MEV orderflow to other parties (e.g., HF traders) and facilitating unfair bidding practices.

While real-time ZK proving could secure private transaction processing, even in leader-based designs where the selected sequencer needs to see transactions to verify their validity and adherence to network rules, we are years away in both software and hardware to get to actual implementation. Until then, we must trust PaaS providers who might engage in such nefarious activity with our transactions. MEV-commit is building an alternative solution that combines a new encryption primitive based on anonymous broadcast encryption and dual-phase commitments that commit the provider to a bid without revealing the details until they need to be revealed.

Fee stability and predictability. Preconfirmation mechanisms can lead to more stable and predictable transaction fees by allowing users to lock in fee rates for future blocks, helping to mitigate fee volatility during network congestion and distribute transaction load more evenly across blocks.

Sequencer differentiation. Another possibility is that the PaaS providers can differentiate themselves and potentially charge premium fees based on their reputation for reliable preconfirmation guarantees, leading to a competitive market among sequencing providers.

Based rollups with preconfirmations can enhance the Ethereum L1 UX by reducing fragmentation and offering faster transaction confirmations, which can draw activity back to L1 and offset revenue declines caused by L2s operating independently. Paired with other potential Ethereum L1 improvements – such as faster block times or single-slot finality (or “secure-speedy finality”) where the Ethereum-native slot-and-epoch architecture can achieve sub-second preconf slots – this leaves little room for continuing with the single-sequencer rollup approach.

Suppose Ethereum L1 achieves sufficient improvement in these ways, it will likely attract less fee-sensitive users who prioritize its lindyness, security, and provenance. At the same time, L2s remain attractive to their existing ecosystem of fee-sensitive users who weigh fees over those considerations – or the L2s develop into sidechains, taking a vertical integration or modular approach to operating settlement and data availability. 

If this pans out, the space for a “compromise approach” of a hundred-node fast chain with Ethereum providing extra interoperability and security becomes smaller and smaller. If Ethereum fees are in the <$1 range at scale, the bigger ticket transactions and value accrual from priority fees returns to Ethereum, and compromise-approach L2s are left mostly with long-tail, low-value, small-ticket transactions.

Now, we can see that if a rollup is based, they are using L1 as their settlement and sequencing layer. Existing rollups only use L1 for settlement while sequencing has been centralized at L2. With preconfs, you can get rapid decentralized sequencing at L1 using a shared mechanism that can be used by any L2. L2 blocks as L1 transactions. In-protocol unified sequencing.

However, it’s worth noting that while preconfs appear to be a promising solution for performant Ethereum-based sequencing, there is ongoing debate about whether preconfs introduce complexities that undermine the simplicity and real-time security that initially made based rollups appealing. It’s a question of the tradeoffs between encapsulated vs. systemic complexity. The critical question is whether based rollups + preconfs are actually better than the current solution of traditional rollups + fallback – the mechanism by which traditional rollup transactions are quickly confirmed by the rollup’s own sequencer but eventually rely on Ethereum’s L1 for finality and security. Fallback ensures that even if a rollup’s sequencer fails, users can still achieve delayed transaction inclusion through Ethereum L1.

Furthermore, there are good reasons for rollups to prefer using a separate shared sequencer layer over based shared sequencing. Although out-of-protocol shared sequencing introduces new trust assumptions, these designs could yield better UX and commitment guarantees to users by enforcing uniform sequencer behavior. With the right rules in place, these systems can optimize MEV distribution across the network more effectively than allowing for selfish MEV extraction.

In support of both based rollups and shared sequencing, the systemic complexity of potentially hundreds (or thousands) of individual L2 sequencers is not reasonable when there is an alternative to encapsulate and minimize complexity within a standardized shared protocol. Specifically, for based rollups with preconfirmations, the resulting benefits outweigh the costs, as you get (a) social alignment and credible neutrality, (b) atomic composability between L2 and L1 states, and (c) Ethereum’s liveness and decentralization.

First, fully aligning with Ethereum by being based means that based rollups offer a compelling proposition for developers and users who prioritize credible neutrality, decentralization, and growing the pie vs. competing for individual slices. The credible neutrality of leveraging Ethereum proposers for shared sequencing acts as a Schelling point for attracting cross-ecosystem users and developers back to Ethereum. Additionally, social alignment serves as a unifying force, uniting various L2s under a common framework without introducing new tokens, brands, or consensus mechanisms.

Second, based rollups provide credible commitments regarding transaction inclusion and ordering within both L1 and L2 blocks. When the L1 block proposer also acts as the L2 block proposer, atomic inclusion guarantees – similar to those achieved by standardized rules in shared sequencers – are possible.

Third, Ethereum’s robust block production network means that as long as Ethereum is producing blocks, any based L2 on it is also producing blocks. Whereas, if the single sequencer for a traditional rollup goes down, so does the chain.

Despite these advantages, there is a serious challenge that exists today beyond the theoretical. The introduction of PBS during The Merge was intended to promote decentralizing by separating block proposers from builders. However, the current oligopoly of the most-resourced block builders (Beaver and Titan currently build nearly 90% of the total block market) poses risks. This builder concentration is driven by the network effects of PBS: as a builder gains market share, they attract more private order flow, enabling them to construct more profitable blocks and further increase their market share (but see this proposed balancing mechanism). If applications on based rollups choose to share their order flow privately with Beaver and Titan, this situation may only get worse, potentially leading to the entire ecosystem of based rollups and Ethereum depending on just these two builders. This could deter rollups from embracing going based and counting on these builders to build blocks in their best interest.

Moreover, based rollups haven’t achieved product-market fit like traditional rollups. It’s an important consideration for founders deciding whether to allocate resources in this direction.

If you’re building in these spaces or this post resonates with you, let’s chat!

Disclaimer

This article is prepared for general information purposes only. This post reflects the current views of its authors only and is not made on behalf of Lemniscap or its affiliates and does not necessarily reflect the opinions of Lemniscap, its affiliates or individuals The opinions herein may be subject to change without this article being updated.

This article does not constitute investment advice, legal or regulatory advice, investment recommendation, or any solicitation to buy, sell or make any investment. This post should not be used to evaluate the making of any investment decision, and should not be relied upon for legal, compliance, regulatory or other advice, investment recommendations, tax advice or any other similar matters.

All liability in connection with this article, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement is disclaimed. No warranty, endorsement, guarantee, assumption of responsibility or similar is made in respect of any product, service, protocol described herein.