Original author: jolestar (X: @jolestar)
Seeing several friends discussing Based Rollup, most are discussing it from a security perspective. I would like to talk about Based Booster Rollup from the perspective of the relationship between L1 and L2, as well as application construction.
The idea of Based Rollup is actually quite simple: users directly submit L2 transactions to L1, which sorts and packages them, but L1 does not verify the validity of the transactions, only ensuring their order and availability, while L2 is purely an executor, executing L2 transactions packaged on L1. At this point, doesn’t this sound familiar? Isn’t this the Inscription model? Yes, the Indexer for inscriptions can be understood as L2 here. I've mentioned this viewpoint in my article (Is Inscription a bug or a feature).
Booster Rollup takes a different perspective, exploring how to directly read L1's state through contracts on L2. The idea is not complicated; since Based Rollup is already executing L2 transactions on L1, why not also execute L1’s transactions? This way, the states of L1 and L2 can exist in a single large state tree, allowing L2 contracts to read L1's states directly.
Thus, some projects have combined Based Rollup and Booster Rollup, calling it Based Booster Rollup (BBR), like taiko.
The background of BBR
From its proposal to now, BBR has attracted market attention, primarily due to the current fragmentation issues brought by mainstream L2 solutions in Ethereum, the fragmentation between L1 and L2, as well as between L2s. The current L2 solutions offer functionality that, from both developer and user perspectives, does not differ significantly from an Alt-L1; reading L1 data still relies on Oracles, assets still need bridges, and wallets must switch networks. This fragmentation has also brought another problem: the binding between L1 and L2 is not that tight, and L2 can anytime introduce its own consensus mechanism and become an Alt-L1, “independent and self-reigning,” allowing developers and users to experience this change with minimal awareness. The primary binding relationship comes from the EF's constraints on legitimacy: L2 must treat L1 as DA, but evidently, this constraint is not robust.
So if we replace the current L2 solutions with Based Rollup solutions, would the problem be solved? I suspect Optimism and Arbitrum would argue that switching to Based Rollup isn’t very easy? The main current L2 solutions all have Force Inclusion mechanisms; L2 could simply remove the Sequencer and allow users to send transactions to L1 through Force Inclusion, thereby achieving Based Rollup.
But can this solve the fragmentation problem? No. Although Arb and Op submit transactions to L1 in real time and have them packaged and sorted by L1, they are still fragmented because each only recognizes its own transactions. By now, everyone should understand that the key to solving the fragmentation problem with Based Rollup is to have transactions or data that can be shared between L2s, and the requirements for this data format are:
It must be independent of the platform and implementation, defined in a format on L1. Different L2 accounts have differences in virtual machines, and their transactions cannot be directly shared.
It needs to reach consensus between L2s, with multiple L2s supporting it.
Thus, it must prioritize the protocol, first designing public protocols and data formats, with only essential data saved on-chain; execution and verification occur off-chain, with different L2s implementing support solutions independently. However, achieving these two points is quite challenging. First, developers in the Ethereum ecosystem generally design protocols through smart contracts and do not have the habit of designing protocols directly based on data formats. The main attempts in this direction have been during the last inscription craze, known as Ethscriptions. The second point is even more challenging and requires practice and time for validation.
From BBR to BBSR, Stackable L2
Having discussed the issue of data sharing, let's talk about user experience. Obviously, if all transactions are sent directly by users to L1, the experience would be similar to using L1, whether in terms of Gas or confirmation time. Thus, someone started designing a pre-confirmation protocol for Based Rollup, but if the pre-confirmation protocol is to work properly, it requires all transactions to first go through the pre-confirmation protocol, which essentially makes it a Sequencer, doesn’t it? Is this just going around in circles?
The reason for this contradiction is that people confuse several types of transactions:
Transactions submitted directly to L1 and executed and verified by L1 are called L1 transactions.
Transactions submitted directly to L1, but not directly verified and executed by L1, are data transactions shared between L2 protocols, which can be called L1.5 transactions.
Transactions submitted directly to L2 Sequencer, pre-confirmed and executed by the Sequencer, are dedicated transactions for a specific L2.
While Based Rollup only relates to 1 and 2, 3 is the current way of Sequencer Rollup, and the two can be completely combined.
If there is such a Rollup solution:
The Sequencer automatically synchronizes all L1 (including L1.5) transactions and executes them in the order given by L1.
The Sequencer receives L2 transactions and sorts and executes them mixed with L1 transactions.
Through 1, it realizes Based and Booster, and through 2, it achieves fast confirmation of L2 transactions without sacrificing user experience. According to the previous naming scheme, this should be called BBSR (Based Booster Sequencer Rollup), but it's a bit long and not easy to understand, so I call it Stackable L2, which means stacking L2 on L1, where L2 contains all transactions and states of L1. This is the solution of @RoochNetwork.
How to ensure the DA of L2 transactions? Rollup or Rollout?
If the above scheme is adopted, L2 packaging its transactions to submit to L1 would be a bit strange, as L2 would again read and re-execute the L1 transactions that package its own transactions, somewhat like its own output becoming its own input. Therefore, Rooch's solution is Rollout instead of Rollup. Because in the long run, L1's block space is very precious, and multiple L2 transactions competing for L1's space is a form of 'involution'; L1's space should be reserved for L1 and L1.5 transactions, while L2 application-level transactions should seek cheaper block space by expanding new block space through 'external expansion,' which is also beneficial for the development of the entire industry ecosystem.
BBSR/Stackable L2 practice in the Bitcoin ecosystem
The previous descriptions are from the Ethereum perspective, while Rooch, as the first BBSR or Stackable L2 practice for Bitcoin, discusses the differences in the Bitcoin ecosystem.
Bitcoin L2 does not have Turing-complete smart contracts, which actually becomes an advantage under the Based Rollup model. Because Based Rollup does not require L1 to execute and verify transactions; it only needs to ensure Permissionless and DA. This also pressures projects in the Bitcoin ecosystem to design structure-based protocols from very early on, whether colored coins or later RGB, Taproot Assets, Ordinals Inscription, Atomicals, Runs, etc., are all attempts in this category, which can be included under the broad concept of CSV (Client-side Validation) protocols, where their transactions are typical L1.5 transactions. If projects in the Ethereum ecosystem want to practice Based L2, designing shared protocols between multiple L2s will largely resemble the protocols mentioned above.
Taking Rooch as an example, let’s explain the working mode of BBSR on Bitcoin:
Users will directly submit both L1 and L1.5 transactions to Bitcoin, as the protocol is public, so the entry can be any application.
Rooch will synchronize all L1 transactions, process the UTXOs among them, and check if they carry additional protocol information, then process them using the corresponding Move module. For example, transactions identified as Inscription will be processed by the ord module, while transactions for Babylon Staking will be handled by the bbn module.
Users directly submit L2 transactions to Rooch's Sequencer nodes for processing. The outcomes of the execution of the three types of transactions above will generate a complete state tree, and application contracts can fully leverage the states generated by L1 and L1.5 transactions.
Applications in this model can design two types of transactions: one is public protocol transactions (Based part, on L1), and the other is application transactions (sorted by Sequencer). The two can complement each other through the Booster model, ensuring Permissionless while also guaranteeing user experience.
As mentioned earlier, the design of public protocols requires time and practice to validate and reach consensus, and what Rooch can provide is such a convenient experimental environment: If you want to design a new application or asset protocol on Bitcoin, you only need to define the protocol format and then deploy a corresponding Move contract module to handle it, allowing you to experiment by constructing application scenarios.
Of course, there are some challenges in the Bitcoin ecosystem along this route:
At the beginning of Bitcoin's design, there wasn't enough room for expansion for such DA scenarios, so exploring ways to write data onto Bitcoin has been one of the directions various protocols have tried, such as embedding data through OP_RETURN, using Witness, or even through signatures; currently, there is still a lack of standardized solutions.
The Bitcoin ecosystem has not reached a broad consensus on the value of on-chain embedded data, which is also a direction I have been continuously advocating since the last inscription boom; the Bitcoin ecosystem should recognize Bitcoin's value as a global public data bus.
The value of L1 as a global public data bus
Since the DeFi summer, the entire Crypto field has been exploring new applications beyond DeFi. Whether it’s the inscription boom of Bitcoin or the recent heated discussions on Based Rollup, both can be seen as a rediscovery of L1's value as a data bus. From the perspective of distributed systems, data buses can achieve decoupling between systems, and decoupling between systems is one of the key prerequisites for achieving Permissionless. For example, decentralized exchanges in the Crypto ecosystem fully utilize the blockchain as a Data Bus to achieve 'decentralized' connections, which are challenging to implement directly in traditional financial systems. If more complex applications are to be supported, all that is needed is to upgrade simple transfer transactions to application protocol transactions, thus achieving application-level Permissionless with minimal intrusiveness to existing applications.
This article mainly discusses BBR from the perspective of ecology and applications, the security of the BBR model, and the interoperability issues of L1, L1.5, and L2 states under the BBR model, which will be explored in detail in later articles. Additional relevant links are included, featuring my historical articles and discussions from Twitter friends on Based Rollup from different perspectives.
Related links: 1. Stackable L2 — A new blockchain scaling solution https://rooch.network/zh-CN/blog/stackable-l2
2. How should Bitcoin's Layer 2 be done? https://x.com/jolestar/status/1717358817992995120 I initially designed a scheme on how L2 could utilize states and data on Bitcoin L1, where a friend in the comments mentioned Booster's scheme, which was ultimately adopted in practice.
3. Is Inscription a Bug or a Feature? https://x.com/jolestar/status/1732711942563959185 Discussing the value of inscriptions from the perspective of L2's construction, including the incentive compatibility issues between L1 and L2.
4. Discussing Based Rollup from the perspective of subtraction theory @kerne l1 983 https://web3 caff.com/zh/archives/108241
5. @jason_chen 998 Article on Based Rollup https://x.com/jason_chen998/status/1799692331635048697
6. Research report on the Based Rollup track https://research.web3 caff.com/zh/archives/22719
Original link
