This article interviewed Jolestar, the founder of Rooch Network, a project that provides infrastructure solutions for Web3 native applications, to discuss the definition, framework, and views of Bitcoin Layer2.
In response to Bitcoin Magazine’s ideological “Bitcoin Layer2 Three Laws,” Jolestar from Rooch Network shared his own views on Bitcoin Layer2 on Twitter.
In this context, it is reminiscent of Jan, the co-founder of Nervos, who previously mentioned on Twitter that Bitcoin Layer2 should not only consider security issues but also consider scalability and the empowerment of BTC currency attributes. These remarks are particularly thought-provoking.
With the attitude of digging deep into the theory of Bitcoin Layer2, Geek Web3 invited Jolestar to discuss the definition and framework of Bitcoin Layer2 from different perspectives with Faust. The aim is to reveal a path for defining Bitcoin Layer2 from the perspectives of decentralized applications (DA) and functional expansion. Although there is no consensus on how to define Bitcoin Layer2, the discussion process is still of significant reference value.
How to Define Layer2 from a Technical or DA Perspective
Fog Yue: Regarding the definition of Layer2, there is a similar debate in the Ethereum community. According to Jolestar’s comments on Twitter, Layer2 can be divided into “technical or DA perspective” and “functional expansion perspective.” So, first, I would like to ask Jolestar, how do you view Layer2 defined from the “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 key points:
1. Layer2 does not create new block space. The technical solutions that create new block space are fundamentally Layer1.
2. Layer2 should utilize Layer1 to achieve decentralized applications (DA) and security.
Fog Yue: Jolestar, could you explain what “creating 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 long-term storage, which carry great value.
Bitcoin, as the most decentralized blockchain network, has not fully utilized the value of its block space. The current popularity of Ordinals can be understood as the discovery of the value of Bitcoin as a data availability layer (DA).
The Ordinals protocol defines a data formatting standard with extensibility, providing a unified solution for parsing, displaying, and exchanging data engraved on Bitcoin. How to fully and effectively utilize the block space of Bitcoin through extension protocols and Layer2 is an important exploration direction.
Fog Yue: Regarding your previous statement that “Layer2 should utilize Layer1 to achieve DA and security,” I would like to ask, what does it mean to utilize Layer1 to achieve DA?
For example, some Ethereum Layer2 solutions (such as Redstone) only send DA commitments (data hashes) to the chain, and the commitment is associated with off-chain data. Although the 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, is it considered Layer2 if the complete DA data is not directly released on Layer1?
Jolestar: The meaning of “utilizing Layer1 to achieve 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 sufficient.
Different Layer2 solutions have different target application scenarios and may have different paths for implementing DA, as mentioned earlier. For example, the DA implementation method mentioned by Fog Yue is worth exploring. Another example is how CEX submits proof of reserves to the chain, which is already a step in that direction. Therefore, when I mentioned “utilizing Layer1 to achieve DA,” it is broader than the method mentioned by the Ethereum Foundation.
Faust: In fact, completely publishing DA data on-chain is to allow anyone or node to trustingly obtain new data, and more specifically, it is for asset security. If the DA data is not completely on-chain, it does not necessarily mean it is unsafe. 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 solution still ensures asset security because users personally verify the transaction behavior related to themselves. If the verification fails, such transactions are not allowed to take effect. 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. Unless we consider the scenario where users lose their own data, I would consider this client-side verification method more reliable than entrusting assets to any public chain. Even if assets are directly entrusted to the Ethereum network or the Bitcoin mainnet, they are not as secure as self-executing 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 mechanism designs to ensure the reliable release of DA data. At the very least, it should not “seriously threaten” the security of users’ 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 how to empower the asset attributes of BTC and create additional use cases for the massive-scale BTC. There are great possibilities for transactions and pledging.
To trade assets from one blockchain system to another, a bridge is needed. 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 a Bitcoin L2; it is a completely centralized custodial bridge that ensures security through legal regulation.
So, the issue people are concerned about is not decentralization but trust. Decentralized solutions can reduce the trust cost for users and bring opportunities to new projects. However, how L2 can utilize other characteristics of Bitcoin to enhance the security of bridges is a crucial challenge. Additionally, with the development of extension protocols on Bitcoin, whether it is Ordinals, extension protocols above Ordinals (such as BRC20), Atomicals, or RGB, Taprootassets, there will be more and more new types of assets on Bitcoin. It is a huge challenge to make the bridge have extensibility and quickly support new asset types.
Faust: Jolestar may be more inclined to a broad definition of Layer2. However, in my personal opinion, Layer2 and even modular blockchains gained popularity in the Ethereum community. Western perspectives mainly rely on Ethereum-style Layer2 definition standards to assess the current Bitcoin ecosystem, which can be seen from many Western KOLs.
For example, Bob Bodily, the CEO of Oridnals trading platform Bioniq, pointed out that the Bitcoin ecosystem needs organizations like L2BEAT to assess Layer2. The co-founder of Citrea even directly quoted technical terms invented by L2BEAT, such as Optimium, to summarize certain special Bitcoin Layer2 solutions. The CEO of Bitcoin Magazine even vowed to directly hire people from L2BEAT to review Bitcoin Layer2. (Note: Optimium refers to OP Rollup, which does not release complete DA data on Layer1.)
If we view many “Bitcoin Layer2” from the perspective of Ethereum/Celestia, we will find that an important point in the current BTC ecosystem is that many project parties have not accurately positioned themselves, and self-positioning often has problems. For example, is Celestia considered an Ethereum Layer2? Of course not, but it is an important DA layer module in the Layer2 ecosystem and has the most influence.
Similarly, many projects are not Layer2 themselves but the infrastructure or modules that Layer2 relies on.Quality is the kind of functional expansion layer that Jolestar mentioned. 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 confusing. In order to reduce communication costs and facilitate understanding, many projects directly position themselves as Layer2. However, in fact, many projects are similar to Celestia and Avail, which are core modules in the Layer2 component stack, rather than complete Layer2 solutions themselves.
How to classify them specifically 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.” Only then can everyone have a clearer understanding of the entire Layer2 ecosystem, rather than the current confusion.
Jolestar: Here, I have a different view 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 far left to Layer1 on the far right. The solutions in the middle can all be included in this spectrum.
The two ends of this spectrum also represent two different growth patterns. CEX is basically a growth pattern that is completely product and user-oriented, while L1 has a longer construction cycle and prioritizes narratives and blueprints. L2, on the other hand, is in the middle and represents a hybrid growth pattern.
Taking an inclusive perspective, there is no need to overly focus on what is the “true Layer2”. Various technologies and solutions created by the industry, such as Validium, Plasma, sovereign rollups, OP/ZkRollups, modular execution layers, decentralized computing, sidechains, L2/L3, etc., should all be considered as part of this spectrum. The industry explores new infrastructure for various application needs through various combinations.
Different projects have different assumptions about new applications, which also determine their combination methods and growth patterns. It 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 pattern will grow in this stage. However, one thing is certain: after so many years of exploration, the industry has achieved scaled Layer1 and scaled CEX, and now it needs a scaled intermediate layer to fill this gap.
Jolestar: Speaking of this topic, I would like to briefly talk about the programmability of Bitcoin Script.
The programming capability of Bitcoin Script is limited. Its programming capability for assets is mainly reflected in three types of locks: time locks, hash locks, and private key locks. Taproot allows Bitcoin Script to increase its complexity by an order of magnitude, which creates possibilities for solutions like bitvm. But the more critical issue is that Bitcoin Script is stateless. As a programming language executed on the chain, 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 arbitrate off-chain malicious behavior is still an unexplored direction.
Another perspective is innovation in cryptography, including using key exchange to construct game mechanisms to ensure security. For example, the Lightning Network, “extractable one-time signatures,” and so on.
Here, I want to talk about a concept called Stackable L2. If we implement the Bitcoin extension protocol indexer through smart contracts, and the indexer can parse all UTXOs and attached states on Bitcoin, allowing developers to deploy applications in 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.
I used to call this model smart indexer, but the concept of indexer gives the impression of being read-only, so I used a new term “Stackable L2,” which refers to extension protocol solutions that include the full state of L1 in L2. It fully inherits all the states of L1. In this case, the applications on L2 can read all the states on L1 and also establish new states. The assets of L1 and L2 can be combined through stacking to form new assets. The security of L2 can be ensured through modular solutions.
霧月: Can you give an example to illustrate how assets from L1 and L2 can be combined through stacking to form new assets?
Jolestar: For example, on Bitcoin, there is a piece of land expressed by an inscription. Then, L2 can stack a house on top of it, and together they form an asset whose value is higher than the original land. Then, someone turns this house into an exhibition hall, and the value changes again. In fact, this model is similar to the asset appreciation model in the real world. Real-world assets also appreciate through synthesis, combination, and stacking.
霧月: The concept of Stackable L2 is interesting. How did you come up with this idea, and are there any other similar projects doing this kind of thing now?
Jolestar: We started thinking about how to inherit the existing state on Bitcoin, whether it is UTXOs or inscriptions. We initially thought of using a Merkle proof to have Layer2 nodes only store the block headers of Bitcoin and not the “full state” of the Bitcoin network. However, we found that this solution had poor user and developer experience and did not support new types of assets like inscriptions well. So we evolved to store the “full state” in the form of Layer2.
We have seen similar projects on 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, allowing smart contracts in L2 to directly read all the states in L1. Of course, there are differences in specific implementations. For example, it uses the EVM virtual machine, while Rooch uses the Move smart contract language, and there are differences in DAO and security mechanisms.
霧月: In the scenario mentioned above, what are the advantages of Rooch’s Move language?
Jolestar: Assets in Move are expressed as resources or objects, and Bitcoin’s UTXOs and inscriptions can be directly reflected as objects in Move. They belong to the Object of the user owner. One key reason for the limited programming capability of Bitcoin is the difficulty of expressing shared states, while Move has the concept of Shared Object, which, when combined with Layer2, can provide a good programming experience.
The RGB++ protocol and isomorphic reflection proposed by the CKB team are the pioneers of this kind of thinking. They have a Cell that is more thorough and pure UTXO than the Object in the Move language, but the core idea is similar.
Another advantage of Move is its composition ability, which allows nesting one asset within another asset. For example, in the previous example, the house must be nested within the land in order to achieve atomic transfer of the land and the house.
Faust: Jolestar mentioned RGB++. Indeed, RGB++ is a typical solution that expands the functionality of Bitcoin’s UTXO from a functional perspective. 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 justifiable. The current Western community overly focuses on “security” and neglects the expansion of Bitcoin’s UTXO functionality, which is something we should pay attention to.
霧月: What is the current status of Rooch Network? What are the technical challenges in the proposed solutions?
Jolestar: We are preparing for the launch of the RoochBTC testnet and its subsequent operation. The RoochBTC testnet will include the full UTXO state and inscriptions from Bitcoin, and we are making final improvements to the data verification and upgrade mechanisms.
The full data on Bitcoin is about hundreds of gigabytes, and if we express the UTXOs and inscriptions in Move language, the data volume will increase several times. Currently, there are various inscription protocols, and the standard implementation of inscription protocols is not complete, making it 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 developing applications.