Interviewer: Fuyue, Geek web3

Interviewees: Jolestar, Founder of Rooch Network & Faust, Founder of Geek web3

Regarding the ideological "Bitcoin Layer2 Three Laws" previously published by Bitcoin Magazine, Jolestar, a teacher at Rooch Network, expressed his views on Bitcoin Layer2 on Twitter.

In this context, it is reminiscent of Jan, the co-founder of Nervos public chain, who stated on Twitter that "Bitcoin Layer2 should not only consider security issues, but also consider functional expansion and empowerment of BTC's monetary attributes." These remarks are particularly thought-provoking.

With the attitude of thoroughly exploring the theoretical aspects of Bitcoin Layer2, Geek web3 specially invited Jolestar and Faust to discuss the definition framework of Bitcoin Layer2 from different value perspectives, aiming to reveal a multi-dimensional definition path for Bitcoin Layer2 from the perspectives of DA and functional expansion. Although there is currently no consensus on how to define Bitcoin Layer2, the discussion process is still of significant reference value.

Defining Layer2 from a Technical or DA Perspective

Fuyue: Regarding the definition of Layer2 from a technical perspective or DA perspective, 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, how do you view the definition of Layer2 from the "DA" perspective?

Jolestar: Actually, the key is to make everyone clearly feel the difference between Layer2 and Layer1, as well as centralized solutions. I think the core points are:

Layer2 does not create new block space. The technical solutions that create new block space are essentially Layer1.

Layer2 should use Layer1 to achieve DA and security.

Fuyue: Jolestar, could you explain what "creating new block space" means here?

Jolestar: That's a good question. Here, the "block space" refers to the "data storage space" created by the blockchain consensus mechanism. The block space created by the blockchain has many characteristics, such as complete openness, immutability, and permanent/long-term storage, embodying tremendous value.

As the most decentralized blockchain network, the value of Bitcoin's block space has not been fully realized. This wave of Ordinals inscriptions can be understood as the discovery of the value of Bitcoin as a data availability layer (DA).

The Ordinals protocol defines a scalable data format standard, providing a unified solution for parsing, displaying, and exchanging data inscribed on Bitcoin. How to fully and effectively utilize Bitcoin's block space through extension protocols and Layer2 is an important exploration direction.

Fuyue: Regarding your previous statement "Layer2 should use Layer1 to achieve DA and security," I would like to ask, what does it mean to use Layer1 to achieve DA?

For example, some Ethereum Layer2 solutions (such as Redstone) only send DA commitment (datahash) to the chain, with the commitment associated with off-chain data. Although the DA data has not been fully published on Layer1, it allows anyone to 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 not directly publishing complete DA data to Layer1 count as Layer2?

Jolestar: The meaning of "achieving DA" that I mentioned here is actually very tolerant. It does not mean that the publication of DA data must rely entirely on Layer1. As long as the security of Layer2 assets can be associated with Layer1, even if the DA data is not completely on chain, it is acceptable.

Different Layer2 solutions target different application scenarios and may have different paths for DA implementation, such as the DA implementation method mentioned by Fuyue earlier, which is worth exploring. For example, CEX submitting proof of reserves to the chain has already taken a step in this direction. Therefore, what I mentioned as "using Layer1 to achieve DA" is broader than the way the Ethereum Foundation describes it.

Faust: In fact, publishing DA data completely on chain is to allow anyone or any node to trustingly obtain new data, and further, to ensure asset security. If DA data is not completely on chain, it does not necessarily mean it is insecure. For example, in the RGB protocol, only the data commitment is published on the Bitcoin chain, and the associated transaction data is stored off-chain. This approach still ensures asset security because users will personally verify the transactions related to themselves. If the verification fails, such transactions will not be allowed to take effect. Clearly, this is very secure.

Therefore, in the context of the RGB protocol, even if DA data is not published on the Bitcoin chain, users' assets are still secure. If we do not consider the scenario where users lose the data, I would consider this client-side verification method to be more reliable than entrusting assets to any public chain. Even entrusting assets directly to the Ethereum network or Bitcoin mainnet is not as secure as running client-side verification, because Ethereum and Bitcoin are both third-party platforms.

Therefore, whether DA is On Chain/On Layer1 is not a necessary condition for Layer2, but there should be corresponding mechanism designs to ensure the reliable publication of DA data, at least not "seriously threatening" 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 discussing how to empower the asset attributes of BTC, and how to create additional usage scenarios for the trillion-level scale of BTC assets, whether it is for transactions or staking, there is a great deal of imagination space.

To facilitate the trading of assets from one blockchain system to another, a bridge is needed, and the key issue here is how to make users trust this bridge and ensure the security of assets. From this perspective, all solutions that create usage scenarios 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, as it is a completely centralized custodial bridge that ensures security through legal regulation.

So the issue everyone is concerned about is not decentralization, but trust. Decentralized solutions can reduce the trust cost for users and bring opportunities for new projects, but constructing a secure trustless bridge on Bitcoin is a key challenge. Whether Layer2 can use other features of Bitcoin to enhance the security of this bridge is another important consideration. Additionally, with the development of expansion protocols on Bitcoin, such as Ordinals and the protocols built on top of Ordinals (such as BRC20), Atomicals, RGB, Taprootassets, etc., new types of assets on Bitcoin will continue to increase. It is a huge challenge to make this bridge scalable and quickly support new asset types.

Faust: Jolestar may prefer a more broad definition of Layer2 solutions. However, in my personal opinion, Layer2 and even modular blockchains have gained popularity in the Ethereum community, and people in the West tend to adhere more to the Ethereum-style Layer2 definition standards when evaluating the current Bitcoin ecosystem, as seen in many Western KOLs.

For example, Bob Bodily, CEO of the Oridnals trading platform Bioniq, has pointed out that the Bitcoin ecosystem needs organizations like L2BEAT to evaluate Layer2; the co-founder of Citrea even directly references some technical terms invented by L2BEAT, such as Optimium, to summarize certain specific Bitcoin Layer2 solutions. The CEO of Bitcoin Magazine even declared the intention to directly hire people from L2BEAT to review Bitcoin Layer2. [Note: Optimium refers to OP Rollup, which does not publish complete DA data on Layer1]

Looking at many "Bitcoin Layer2" solutions from the perspective of Ethereum/Celestia, it is important to note that many projects in the BTC ecosystem have not accurately positioned themselves, and their self-positioning often has issues. For example, something like Celestia, do you think it can be considered an Ethereum Layer2? Of course not, but it is an important DA layer module in the Layer2 ecosystem, and it has the most influence.

Similarly, many projects are not Layer2 themselves, but rather the underlying infrastructure or modules that Layer2 depends on, essentially the 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 depend.

The positioning of many projects in the Bitcoin ecosystem is currently somewhat confused. To reduce communication costs and facilitate understanding, they directly position themselves as Layer2. But in fact, many projects are similar to Celestia and Avail, core modules in the Layer2 component stack, rather than complete Layer2 solutions themselves.

The specific categorization of these projects is certainly clear to people in the Western community, especially those in the modular blockchain-related community. I believe that Western OGs will thoroughly distinguish between "what is Layer2 itself and what is the functional expansion layer that Layer2 depends 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 view from Faust. If we abstractly understand Layer2 and other off-chain expansion solutions, regardless of specific implementation methods, we will find that it is a continuous spectrum, encompassing solutions from CEX on the far left to Layer1 on the far right, with solutions in the middle covering 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 the construction cycle of L1 is relatively long, prioritizing narrative and blueprints. Layer2 is in the middle and represents a mixed growth pattern.

Taking an inclusive perspective, we do not 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 layer, decentralized computing, sidechains, L2/L3, etc., should be considered as part of this spectrum. The industry explores new infrastructure needed for various applications through various combinations of these solutions.

Different projects have different assumptions about new applications, which also determine their combination 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 at this stage. However, one thing is certain: after many years of exploration, the industry has achieved large-scale Layer1 and large-scale CEX, and now needs a large-scale intermediate layer to fill this gap.

Expanding the Bitcoin Network in What Ways

Jolestar: On this topic, I would like to briefly discuss the programmable capabilities of Bitcoin scripts.

BitcoinScript has limited programming capabilities, mainly manifested in three types of locks for assets: time locks, hash locks, and private key locks. Taproot allows the complexity of BitcoinScript to increase by an order of magnitude, creating 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 the state of Bitcoin, such as timestamps, nonce 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 a direction to be explored.

Another angle is cryptographic innovation, including constructing game mechanisms to ensure security based on key exchange, such as the Lightning Network, "extractable one-time signatures," etc.

Here I want to talk about a concept called StackableL2. If we use smart contracts to implement an Indexer for Bitcoin's expansion protocol, the Indexer parses all UTXOs and attached states on Bitcoin, allowing developers to deploy applications to the Indexer through smart contracts. This essentially provides Bitcoin with a new smart contract layer, which is our solution at Rooch Network.

I previously called this pattern an intelligent Indexer, but the concept of an Indexer gives the impression of being read-only, so I used a new term "Stackable L2," referring to all extension solutions in L2 that include the full state of L1, fully inheriting all the states of L1. In this case, L2 applications can read all the states on L1 and also create new states. Assets on L1 and L2 can form new assets through stacking combinations, and the security of L2 can be ensured through modular solutions.

Wuyue: Can you give an example to illustrate how L1 and L2 assets can form new assets through stacking combinations?

Jolestar: For example, on Bitcoin, there is an inscription representing a piece of land. Then, L2 can stack a house on top of it, forming a new asset together, with a value higher than the original land. Then, someone turns this house into an exhibition hall, and the value changes again. In fact, this pattern is similar to the appreciation model of assets in the real world. Assets in the real world also appreciate through synthesis, combination, and stacking.

Wuyue: The concept of Stackable L2 is interesting. How did this idea come about, and are there other similar projects doing this kind of thing now?

Jolestar: We started thinking about how to inherit the existing state on Bitcoin, whether it's UTXO or inscriptions. We initially thought of using a Merkle proof approach, where Layer2 nodes only store the block headers of Bitcoin and not the "full state" of the Bitcoin network. But when we tried to implement it, we found that this approach provided a poor user and developer experience and did not support new types of assets like inscriptions very well. So, it evolved into a form of storing the "full state."

We see similar projects in the market. In the Ethereum community, there is a solution called Booster Rollup. There's a project called Taiko that stores the full state of Layer1 in Layer2, and smart contracts in L2 can directly access 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 also differences in DA and security mechanisms.

Wuyue: 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 UTXO and inscriptions can be directly mapped to objects in Move. They belong to the user's owner object. One key reason for the limited programming capabilities on Bitcoin is the difficulty in expressing shared states, while Move has the concept of Shared Objects, which, when combined with Layer2, can provide a good programming experience.

The RGB++ protocol proposed by the CKB team and isomorphic mapping are pioneers of this kind of thinking. Their Cell is more thorough and pure UTXO than the Object in the Move language, but the core concept is similar.

Another advantage of Move is its composability, allowing one type of asset to be nested within another. For example, in the previous example, the house must be nested within the land to achieve atomic transfer of the land and the house.

Faust: Here, Jolestar mentioned RGB++. Indeed, RGB++ is a typical solution for expanding the functionality of Bitcoin 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, and there is nothing wrong with that. The Western community is currently overly focused on "security" and is neglecting the expansion of Bitcoin UTXO functionality, which is something we should pay attention to.

Wuyue: What is the current status of Rooch Network? What are the technical challenges of the proposed solution?

Jolestar: We are preparing for the launch of the RoochBTC testnet and the operational activities after the launch. The RoochBTC testnet will contain the full UTXO state and inscriptions on Bitcoin, and we are making final improvements to the data verification and upgrade mechanisms.

The full data on Bitcoin is about several hundred gigabytes, and if we parse the full UTXO and inscriptions and express them in Move language, the data volume will increase several times. There are currently many inscription protocols, and the standardized implementation of inscription protocols is not complete, making it difficult to support all of them at once. We need to provide a mechanism to dynamically support new inscription protocols and gradually increase support for new protocols based on community feedback.

The testnet is now live, and we welcome developers and users interested in Bitcoin and Move to experience it and try developing applications.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。