Some friends were discussing Based Rollup, mostly from a security perspective. Here, I’ll share my views on Based Booster Rollup from the perspective of L1 and L2 relationships and application building.

The idea behind Based Rollup is straightforward: users submit L2 transactions directly to L1, where L1 handles the sorting and packaging. However, L1 doesn’t verify transaction validity, only ensuring transaction order and availability. L2 is a purely execution layer, processing the L2 transactions packaged on L1. If this setup feels familiar, it’s because it resembles the Inscription model. In fact, you can think of Inscription’s Indexer as L2 in this context—a point I discussed in my article “Is Inscription a Bug or a Feature?”

Booster Rollup takes a different approach: how can L2 directly read L1’s state via contracts? Since Based Rollup is already executing L2 transactions on L1, why not have it process L1 transactions as well? This way, L1 and L2 states can exist within a unified state tree, allowing L2 contracts to directly access L1’s state.

This has led to projects merging Based Rollup and Booster Rollup, collectively referred to as Based Booster Rollup (BBR), as seen with projects like #Taiko .

Background of BBR

The growing interest in BBR stems largely from the current fragmentation in Ethereum’s mainstream L2 solutions. This fragmentation occurs between L1 and L2, and among L2s themselves. The current L2 solutions operate similarly to an Alt-L1, relying on oracles to access L1 data, bridging assets, and requiring network switching in wallets. Additionally, the bond between L1 and L2 isn’t always strong, and L2s could easily implement their own consensus mechanisms to become Alt-L1s, effectively operating independently.

Would replacing all current L2 solutions with Based Rollup fix this fragmentation? #Optimism and #Arbitrum might argue that it’s feasible since major L2 solutions have Force Inclusion mechanisms that remove the Sequencer, enabling users to send transactions to L1 directly and achieve Based Rollup.

However, while Arb and Op do submit transactions to L1 in real-time for sorting, they still remain fragmented, as they only recognize their transactions. The key to solving this fragmentation with Based Rollup lies in having a protocol that enables shared transactions or data across L2s, with data that:

1. Has a format independent of platform or implementation, defined at the L1 level, since different L2s vary in accounts and virtual machines.

2. Is accepted by multiple L2s.

Hence, protocol design must come first, creating a shared data format that L2s can agree on, and leaving only essential protocol data on-chain, with execution and verification occurring off-chain. This direction has proven challenging as Ethereum developers typically design protocols using smart contracts rather than data formats. The main attempt here was Ethscriptions during the previous Inscription craze.

From BBR to BBSR: Stackable L2

Once data-sharing issues are tackled, user experience becomes a concern. Directly submitting all transactions to L1 would resemble using L1 in terms of gas fees and confirmation time. To improve this, some have designed pre-confirmation protocols for Based Rollup, though implementing such protocols effectively reintroduces Sequencers, undoing some of the simplifications.

This contradiction arises from conflating three types of transactions:

1. L1 transactions directly submitted and executed by L1.

2. L1.5 transactions submitted to L1 but not immediately executed by L1, facilitating L2 data-sharing protocols.

3. L2-specific transactions submitted to L2 Sequencers for pre-confirmation and execution.

Based Rollup is only relevant to the first two types, whereas the third falls under the current Sequencer Rollup model. These can coexist. Imagine a Rollup model where:

1. The Sequencer automatically syncs and executes all L1 (including L1.5) transactions in the L1-defined order.

2. The Sequencer receives and mixes L2 transactions with L1 transactions for sorting and execution.

In this setup, 1 enables Based and Booster functionalities, while 2 achieves quick L2 transaction confirmation without sacrificing user experience. I’ll call this the Stackable L2 model, where L2s stack on L1 and incorporate all L1 transactions and states. This approach is being implemented by Rooch Network.

Ensuring Data Availability (DA) for L2 Transactions: Rollup or Rollout?

With this model, it becomes redundant for L2 to package its transactions for submission to L1, as they’d repeatedly execute the same data. Thus, Rooch’s solution uses Rollout instead of Rollup, conserving L1’s valuable block space by leaving it to L1 and L1.5 transactions, while L2 transactions expand onto alternative block spaces, benefiting the entire ecosystem.

Bitcoin Ecosystem’s BBSR/Stackable L2 Practice

This description so far is from an Ethereum viewpoint. However, as the first BBSR or Stackable L2 practice on Bitcoin, Rooch leverages some unique advantages.

Bitcoin L2 lacks Turing-complete smart contracts, making the Based Rollup model ideal, as it only requires permissionless DA. Bitcoin’s projects, such as Colored Coins, RGB, Taproot Assets, and Ordinals Inscription, have long adopted data-structure-based protocols, fitting well within the broad CSV (Client-Side Validation) framework and exemplifying typical L1.5 transactions. If Ethereum projects adopt Based L2, their protocols might look similar.

In Rooch’s Bitcoin-based BBSR model:

1. Users submit both L1 and L1.5 transactions to Bitcoin.

2. Rooch syncs all L1 transactions, processes UTXOs, identifies transactions with protocol data, and executes them with specific modules (e.g., ord module for Inscription transactions).

3. Users submit L2 transactions directly to Rooch’s Sequencer, with results combined into a complete state tree that application contracts can fully utilize.

This model supports two transaction types: public protocol transactions (Based, on L1) and application-specific transactions (Sequencer-sorted), combining Booster benefits with permissionless protocols and user experience improvements.

The public protocol design, requiring time and practice to validate and reach consensus, has a convenient test environment with Rooch, where designing a Bitcoin application protocol is as simple as defining the format and deploying the corresponding Move contract.

The Value of L1 as a Global Data Bus

Since DeFi Summer, the crypto industry has sought non-DeFi applications. The recent Inscription craze and Based Rollup discussions reveal a rediscovery of L1’s value as a data bus. In decentralized systems, data buses enable system decoupling—a key condition for permissionless operations. Applications only need to upgrade transaction protocols to application-specific transactions for minimal impact on existing systems.

This article has focused on BBR from an ecosystem and application perspective. Later, we’ll explore BBR security, L1-L1.5-L2 interoperability, and related topics in further detail.