Geek Dialogue: Why Layer2 Should Expand the Functionality of BTC
Interviewees: @jolestar & @faustliu1997
Geek Web3 invited Teacher Jolestar and Faust to discuss the definition framework of Bitcoin Layer2 from different perspectives, aiming to reveal a multi-angle 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.
How to Define Layer2 from a Technical or DA Perspective
Wuyue: Regarding how to define Layer2, there are similar debates in the Ethereum community. According to Teacher 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 Teacher Jolestar, how do you view the "DA" perspective definition of Layer2?
Jolestar: Actually, the key is to make everyone clearly feel the difference between Layer2 and Layer1, as well as centralized solutions. I think there are two key points:
Layer2 does not create new block space. Technical solutions that create new block space are essentially Layer1.
Layer2 should use Layer1 to achieve DA and security.
Wuyue: Teacher Jolestar, could you explain what "creating new block space" means here?
Jolestar: That's a good question. The block space mentioned here refers to the "data storage space" created through 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 significant value.
As the most decentralized blockchain network, Bitcoin's block space value has not been fully realized. The current Ordinals inscription craze 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 with extension protocols and Layer2 is an important exploration direction.
Wuyue: 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 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?
(Reference: The article can be read on the Geek Web3 official account)
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. Even if DA data is not completely on chain, as long as the security of Layer2 assets can be associated with Layer1, it is acceptable.
Different Layer2 solutions target different application scenarios and may have different paths for DA implementation. For example, the DA implementation method mentioned by Wuyue is worth exploring. For example, CEX submitting proof of reserves to the chain is already a step in this direction. Therefore, when I mention "using Layer1 to achieve DA," it 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 not secure. For example, in the RGB protocol, only the data commitment is published to 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 scenarios 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 the Bitcoin mainnet is not as secure as running client-side verification, as 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 posing a "serious threat" to user asset security.
(Reference: The article can be read on the Geek Web3 official account)
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, creating additional usage scenarios for the trillion-level scale of BTC assets, whether it is trading or staking, there is a lot of room for imagination.
To facilitate the trading of assets from one blockchain system to another, a bridge is needed. 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 focus is not on decentralization but on trust. Decentralized solutions can reduce the trust cost for users and bring opportunities to new projects, but the key challenge is how L2 can use other features of Bitcoin to enhance the security of this bridge.
In addition, with the development of extension protocols on Bitcoin, whether it is Ordinals, extension protocols on top of Ordinals (such as BRC20), Atomicals, or RGB, Taproot assets, the new types of assets on Bitcoin will increase. How to make this bridge scalable and quickly support new asset types is a huge challenge.
Faust: Teacher Jolestar may favor a more broad definition of Layer2. But in my personal opinion, Layer2 and even modular blockchains have become popular in the Ethereum community, and Westerners mostly adhere to the Ethereum-style Layer2 definition standards to evaluate the current Bitcoin ecosystem, which is evident in many Western KOLs.
For example, Bob Bodily, the 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 directly quotes some of the technical terms invented by L2BEAT, such as Optimium, to summarize certain special Bitcoin Layer2 solutions.
The CEO of Bitcoin Magazine even declared the intention to directly hire people from L2BEAT to review Bitcoin Layer2.
If we look at many "Bitcoin Layer2" solutions from the perspective of Ethereum/Celestia, we will find that an important point in the current BTC ecosystem is that many projects have not accurately positioned themselves, and their self-positioning often has issues.
For example, something like Celestia, do you think it is considered an Ethereum Layer2? Of course not, but it is an important DA layer module in the Layer2 ecosystem, and it has the most significant influence.
Similar principles apply to many projects that are not Layer2 themselves, but rather the foundational infrastructure or modules on which Layer2 depends, essentially the kind of functional expansion layer that Jolestar mentioned. This is similar to the relationship between the B^2 Network and the B^Hub network, where the former is a typical Layer2 solution, and the latter is the infrastructure on which Layer2 solutions depend.
Currently, the positioning of many projects in the Bitcoin ecosystem is a bit confusing. To reduce communication costs and make it easier for everyone to understand, they directly position themselves as Layer2. However, in reality, many projects are similar to Celestia and Avail, core modules in the Layer2 component stack, rather than complete Layer2 solutions themselves.
How to categorize these specifically is something that the Western community, especially the modular blockchain-related community, is certainly clear about. I believe that the Western OGs will thoroughly distinguish between "what is Layer2 itself and what is the functional expansion layer on which Layer2 depends," so that everyone can have a clearer view of the entire Layer2 ecosystem, rather than the current confusion.
Jolestar: Here, I have some different views 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 the most left end, CEX, to the most right end, Layer1, with solutions in the middle band falling within 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 Layer1 is relatively long, prioritizing narrative and blueprints. Layer2 falls in the middle and represents a mixed growth pattern.
From an inclusive perspective, we do not need to overly focus on what is "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 all be considered part of this spectrum. The industry is exploring new infrastructure needed for various applications through various combinations.
Different projects have different assumptions about new applications, which also determine their combination and growth patterns. It may be a little to the left of Layer1 or a little 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 Different Ways
Jolestar: Regarding this topic, I would like to briefly talk about the programmable capabilities of Bitcoin Script.
Bitcoin Script has limited programming capabilities, mainly manifesting in three types of locks for assets: time lock, hash lock, and private key lock. Taproot allows Bitcoin Script's complexity 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 for on-chain execution, it cannot read the state of Bitcoin, such as timestamps, nonces of past blocks, and additional parasitic asset information attached to UTXOs.
Bitcoin script can only rely on the 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 innovation in cryptography, 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 Stackable L2. If we use smart contracts to implement an Indexer for Bitcoin's extension protocols, the Indexer can parse all UTXOs and additional states on Bitcoin and allow developers to deploy applications to the Indexer through smart contracts, essentially providing Bitcoin with a new smart contract layer. This is the solution proposed by our 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 extension solutions that include the full state of L1 within L2, 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 be combined through stacking to form new assets. The security of L2 can be ensured through modular solutions.
Wuyue: Can you give an example to illustrate how assets from L1 and L2 can be combined to form new assets?
Jolestar: For example, there is an inscription on Bitcoin representing a piece of land. Then, L2 can stack a house on top of it, and together they form a new asset, the value of which is 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 asset appreciation model in the real world. In the real world, assets 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 inscription. We initially wanted to use a Merkle proof approach, where Layer2 nodes only store the block headers of Bitcoin and not the "full state" of the Bitcoin network. However, during implementation, we found that this approach had a poor user and developer experience and could not support new types of assets like inscriptions. So, we evolved to the form of storing the "full state."
We see similar projects in the market with similar concepts. In the Ethereum community, there is a solution called Booster Rollup, and there is a project called Taiko, which stores the full state of Layer1 in Layer2, and smart contracts in L2 can directly read all the states of L1. Of course, there are differences in specific implementations, such as it being an EVM virtual machine, while Rooch uses the Move smart contract, 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 UTXOs and inscriptions can be directly mapped to objects in Move. They belong to the user's Owner object. A key reason for the limited programming capabilities of Bitcoin is the difficulty in 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 mapping proposed by the CKB team 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 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++, which is indeed a typical solution for expanding Bitcoin UTXO from a functional perspective. RGB++ is not only applicable to CKB itself but also to public chains related to UTXO or similar state storage models, such as Cardano, Fuel, or Sui.
From this perspective, CKB, Cardano, Sui, and Rooch can all serve as functional expansion layers for Bitcoin, and there is nothing wrong with this. Currently, the Western community is overly focused on "security" and overlooks 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 solutions?
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 in data verification and upgrade mechanisms.
The full data on Bitcoin is approximately several hundred gigabytes. If we were to fully parse the UTXO and inscriptions and express them in Move language, the data volume would increase several times. Currently, there are various inscription protocols, and the standardized implementation of inscription protocols is not complete. 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 now live, and developers and users interested in Bitcoin and Move are welcome to experience it and try developing applications.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
