This article interviews Jolestar, the founder of Rooch Network, a project that provides infrastructure solutions for Web3 native applications, to discuss the definition, framework, and perspectives of Bitcoin Layer2.
Regarding Bitcoin Magazine’s previous “Bitcoin Layer2 Three Laws,” Jolestar from Rooch Network expressed his own views on Bitcoin Layer2 on Twitter.
With the attitude of thoroughly exploring the theory of Bitcoin Layer2, Geek Web3 invited Jolestar to discuss the definition and framework of Bitcoin Layer2 from different perspectives with Faust, aiming to reveal a multi-dimensional definition of Bitcoin Layer2 from the perspectives of decentralized applications (DA) and functional expansion. Although a consensus on the definition of Bitcoin Layer2 has not yet been reached, the discussion process is still of great reference value.
Defining Layer2 from a Technical or DA Perspective
Wuyue: Regarding the definition of Layer2, there are similar debates in the Ethereum community. According to Jolestar’s statement on Twitter, Layer2 can be divided into “technical or DA perspective definition” and “functional expansion perspective definition.” So, I would like to ask Jolestar, what is your view on the definition of Layer2 from a “DA” perspective?
Jolestar: Actually, the key is to make a clear distinction between Layer2 and Layer1, as well as centralized solutions. I believe there are two core points:
1. Layer2 does not create a new block space. The technical solutions that create new block space are essentially Layer1.
2. Layer2 needs to utilize Layer1 to achieve DA and security.
Wuyue: Jolestar, could you explain what “creating a new block space” means?
Jolestar: That’s a good question. Here, “block space” refers to the “data storage space” created through blockchain consensus mechanisms. The block space created by the blockchain has many characteristics, such as complete openness, immutability, and permanent/long-term storage, which contain great value.
As the most decentralized blockchain network, the value of Bitcoin’s block space has not been fully realized. The recent popularity of Ordinals can be understood as the value discovery of Bitcoin as a data availability layer (DA).
The Ordinals protocol defines a data format standard with extension capabilities, providing a unified solution for parsing, displaying, and exchanging data engraved on Bitcoin. How to fully utilize Bitcoin’s block space through extension protocols and Layer2 to support new asset types is an important exploration direction.
Wuyue: Regarding your previous statement about “Layer2 utilizing Layer1 to achieve DA and security,” I would like to ask, what does it mean to “achieve DA using Layer1”?
For example, some Ethereum Layer2 solutions (such as Redstone) only send DA commitments (data hashes) to the chain, with commitments associated with off-chain data. Although DA data is not fully published on Layer1, anyone can challenge the commitment and request the sequencer to put the complete data on-chain. Does this count as creating block space outside of Layer1? In other words, does this count as Layer2 if the complete DA data is not directly released on Layer1?
Jolestar: The meaning of “achieving DA” that I mentioned here is actually very inclusive. It does not mean that the release of DA data must rely entirely on Layer1. As long as the asset security of Layer2 can be associated with Layer1, it is considered achieving DA.
Different Layer2 solutions have different application scenarios and different paths for implementing DA. For example, the DA implementation method mentioned by Wuyue is worth exploring. Another example is when CEX submits reserve proofs to the chain, it has already taken a step towards this direction. Therefore, when I mention “achieving DA using Layer1,” it is broader than the method mentioned by the Ethereum Foundation.
Faust: In fact, fully publishing DA data on-chain is to allow anyone or any node to trustingly access new data, and more specifically, it is for asset security. If DA data is not fully published on-chain, it does not necessarily mean it is not secure. For example, in the RGB protocol, only the data commitment is released on the Bitcoin chain, and the associated transaction data is stored off-chain. This scheme still ensures asset security because users personally verify the transaction behavior related to themselves. If the verification fails, such transactions are not allowed. Obviously, this is very secure.
Therefore, in the context of the RGB protocol, even if the DA data is not released on the Bitcoin chain, users’ assets are still secure. If we do not consider the scenario of users losing their data, I would consider this client-side verification method more reliable than entrusting assets to any public chain. Even entrusting assets directly to the Ethereum network or the Bitcoin mainnet does not provide the same level of security as self-executed client-side verification because Ethereum and Bitcoin are third-party platforms.
Therefore, whether DA is on-chain or on Layer1 is not a necessary condition for Layer2, but there should be corresponding mechanisms designed to ensure the reliable release of DA data. At the very least, it should not “seriously threaten” the security of user assets.
Viewing Layer2 from an Ecological and Functional Expansion Perspective
Jolestar: When defining L2 from an ecological and functional expansion perspective, we focus on how L2 can utilize or inherit the capabilities provided by L1. Taking Bitcoin as an example, all Layer2 solutions are about empowering the asset properties of BTC and creating additional use cases for mega-scale BTC assets, whether it is trading or staking, there is great imagination.
To trade assets from one blockchain system to another, a bridge is required. The key issue here is how to make users trust the bridge and ensure the security of assets. From this perspective, all solutions that create use cases for BTC assets through bridges can be understood as a broad definition of Bitcoin L2. Even BTC ETF can be understood as Bitcoin’s L2, which is a fully centralized custodial bridge guaranteed by legal regulation.
So, the main concern is not decentralization but trust. Decentralized solutions can reduce the cost of user trust and bring opportunities to new projects. However, how L2 can utilize other features of Bitcoin to improve the security of the bridge is a key challenge. Additionally, with the development of extension protocols on Bitcoin, such as Ordinals, extension protocols above Ordinals (such as BRC20), Atomicals, RGB, Taprootassets, etc., there will be more and more new asset types on Bitcoin. How to make the bridge have extension capabilities and quickly support new asset types is a huge challenge.
Faust: Jolestar may prefer a more inclusive definition of Layer2. But in my personal opinion, Layer2, or even modular blockchains, gained popularity in the Ethereum community. Westerners tend to judge the current Bitcoin ecosystem based on the Ethereum-style Layer2 definition standards, which can be seen from many Western KOLs.
For example, Bob Bodily, the CEO of the Ordinaries trading platform Bioniq, once pointed out that the Bitcoin ecosystem needs organizations like L2BEAT to judge Layer2. The co-founder of Citrea even directly quoted some technical terms invented by L2BEAT, such as “Optimum,” to summarize certain special Bitcoin Layer2 solutions. The CEO of Bitcoin Magazine even declared that they would directly hire people from L2BEAT to review Bitcoin Layer2. [Note: “Optimum” refers to OP Rollup, which does not release complete DA data on Layer1]
If we view many “Bitcoin Layer2” solutions from the perspective of Ethereum/Celestia, we will find an important point in the current BTC ecosystem, which is that many project teams have not accurately positioned themselves, and their self-positioning often has problems. For example, is something like Celestia considered an Ethereum Layer2? Of course not, but it is an important DA layer module in the Layer2 ecosystem and has the greatest influence.
Similarly, many projects are not Layer2 themselves but are infrastructure or modules on which Layer2 relies.Quality is the kind of expansion layer mentioned by Jolestar. This is similar to the relationship between B^2 Network and B^Hub Network, where the former is a typical Layer2 solution and the latter is the infrastructure on which Layer2 solutions rely.
Currently, the positioning of many projects in the Bitcoin ecosystem is a bit confused. In order to reduce communication costs and facilitate understanding, they directly position themselves as Layer2. However, in reality, many projects are similar to Celestia and Avail, which are core modules in the Layer2 stack, rather than complete Layer2 solutions themselves.
The categorization of these projects is clear to the Western community, especially the modular blockchain community. It is believed that the Western OGs will thoroughly distinguish between “what is Layer2 itself” and “what are the functional expansion layers that Layer2 relies on,” so that everyone can have a clearer view of the entire Layer2 ecosystem, rather than the current confusion.
Jolestar: Here, I have a different opinion from Faust. If we abstractly understand Layer2 and other off-chain expansion solutions, we will find that it is a continuous spectrum, ranging from CEX on the left to Layer1 on the right, with various solutions in between.
The two ends of this spectrum also represent two different growth models. CEX is mainly a product and user-oriented growth model, while L1 has a longer construction cycle and focuses more on narratives and blueprints. L2 lies in between and represents a hybrid growth model.
From an inclusive perspective, we don’t need to overly focus on what is the “true Layer2.” Various technologies and solutions created by the industry, such as Validium, Plasma, sovereign rollup, OP/ZkRollup, modular execution layers, decentralized computing, sidechains, L2/L3, etc., should all be considered part of this spectrum. The industry explores new infrastructure needed for various applications through various combinations.
Different projects have different assumptions about new applications, which also determine their combination methods and growth models. They may be slightly to the left of Layer1 or slightly to the right of CEX. The future is uncertain, and it is difficult to assert which model will grow during this stage. However, one thing is certain: after years of exploration, the industry now has scaled Layer1 and scaled CEX, and it also needs a scaled intermediate layer to fill the gap.
Jolestar: Regarding this topic, let me briefly talk about the programmability of Bitcoin Script.
Bitcoin Script has limited programming capabilities. Its programming capabilities for assets mainly include three types of locks: time locks, hash locks, and private key locks. Taproot allows Bitcoin Script to be more complex by an order of magnitude, creating possibilities for solutions like bitvm. However, the more critical issue is that Bitcoin Script is stateless. As a programming language executed on the blockchain, it cannot read Bitcoin’s state, such as timestamps, nonces of past blocks, and additional parasitic asset information attached to UTXOs.
Bitcoin Script can only rely on information attached to transaction inputs. Whether we can use Bitcoin Script to achieve arbitration for off-chain malicious behavior is still an area that needs exploration.
Another aspect is cryptographic innovations, including using key exchange to construct game mechanisms for security guarantees, such as the Lightning Network and “extractable one-time signatures.”
Here, I want to talk about a concept called Stackable L2. If we use smart contracts to implement an Indexer for Bitcoin’s extension protocol, which parses all UTXOs and their associated states on Bitcoin, and allow developers to deploy applications to the Indexer through smart contracts, it is equivalent to providing Bitcoin with a new layer of smart contracts. This is the solution of our Rooch Network.
Previously, I called this pattern “Smart Indexer,” but the concept of Indexer gives the impression of being read-only, so I used a new term, “Stackable L2,” to refer to all extension protocol solutions in L2 that include the full state of L1. In this case, L2 applications can read all the states on L1 while also creating new states. Assets from L1 and L2 can be combined through stacking. The security of L2 can be ensured through modular solutions.
Wu Yue: Can you give an example to illustrate how assets from L1 and L2 can be combined through stacking?
Jolestar: For example, on Bitcoin, there is a plot of land represented by an inscription. Then, L2 can stack a house on it, and together they form an asset with a higher value than the original plot of land. Then, someone transforms this house into an exhibition hall, and the value changes again. In fact, this pattern is similar to the asset appreciation model in the real world. Real-world assets also appreciate through synthesis, combination, and stacking.
Wu Yue: The concept of stackable L2 is interesting. How did this idea come about, and are there any other similar projects doing similar things now?
Jolestar: We started thinking about how to inherit the existing state on Bitcoin, whether it’s UTXOs or inscriptions. Initially, we thought of using a Merkle proof to let Layer2 nodes only store the block headers of Bitcoin and not the “full state” of the Bitcoin network. However, during the implementation, we found that this solution had a poor user and developer experience and did not support new types of assets like inscriptions well. So, we evolved to storing the “full state.”
We have seen similar projects in the market. In the Ethereum community, there is a solution called Booster Rollup, and there is a project called Taiko that stores the full state of Layer1 in Layer2. The smart contracts in L2 can directly read all the states of L1. Of course, there are differences in the specific implementations. For example, it uses the EVM virtual machine, while Rooch uses the Move smart contract language, and there are differences in DA and security mechanisms.
Wu Yue: In the scenario mentioned above, what advantages does Rooch’s Move language have?
Jolestar: Assets in Move are expressed as resources or objects, and Bitcoin’s UTXOs and inscriptions can be directly reflected as Move objects. They belong to the object of the user owner. One key reason why Bitcoin’s programming capabilities are limited is that it is difficult to express shared states, while Move has the concept of shared objects, which, when combined with Layer2, can provide a good programming experience.
The RGB++ protocol and isomorphic reflection proposed by the CKB team are pioneers in this kind of thinking. However, their Cells are more thorough and purer UTXOs than the objects in the Move language, but the core concepts are similar.
Another advantage of Move is its composability, allowing one asset to be nested within another asset. For example, in the previous example, the house must be nested within the plot of land; otherwise, it would be difficult to achieve atomic transfer between the plot of land and the house.
Faust: Jolestar mentioned RGB++, which is indeed a typical solution that expands the functionality of Bitcoin’s UTXO. RGB++ is not only applicable to CKB itself but also to public chains like Cardano, Fuel, or Sui that are related to UTXO or similar state storage models.
From this perspective, CKB, Cardano, Sui, and Rooch can all serve as functional expansion layers for Bitcoin, which is reasonable. Currently, the Western community is overly focused on “security” while neglecting the expansion of Bitcoin’s UTXO functionality, which is something we should pay attention to.
Wu Yue: What is the current status of Rooch Network? What are the technical challenges with the proposed solutions?
Jolestar: We are preparing for the launch of the RoochBTC testnet and the operational activities after the launch. The RoochBTC testnet will include the full UTXO state and inscriptions on Bitcoin, and we are making final improvements in terms of data validation and upgrade mechanisms.
The full data on Bitcoin is approximately hundreds of gigabytes. If we parse all UTXOs and inscriptions and express them using the Move language, the data volume will increase several times. Currently, there are various inscription protocols, and the standardization implementation of inscription protocols is incomplete. It is difficult to support all of them at once. We need to provide a mechanism that dynamically supports new inscription protocols and gradually increase support for new protocols based on community feedback.
The testnet is already online, and we welcome developers and users interested in Bitcoin and Move to experience it and try to develop applications.