Bitcoin expansion route ≠ BTC L2.
At the beginning of the new year, I summarized the technical route of BTC L2. It is mainly divided into two parts: BTC's security and value increase, and L2 transaction execution and result downside. As time goes by, in less than three months, BTC L2 has reached nearly a hundred orders of magnitude. However, there are still some basic problems to be solved, the first of which is the definition problem.
In the history of Bitcoin development, there have long been three practical ways to expand capacity. The lowest level is the main network upgrade, such as SegWit and Taproot. The second is off-chain expansion, such as client verification, lightning network and side chain. The last is direct fork, such as Dogecoin, BSV and BCH.
From the inside to the outside, there are many different opinions on what BTC L2 is. Referring to the development history of Ethereum, I would like to put forward two key points for judgment:
1. L2 must first be a chain itself, able to independently complete each link of calculation and transaction, and finally submit Bitcoin for settlement;
2. The security of L2 is fully guaranteed by L1, the underlying value of L2 is supported by BTC, and L2 tokens cannot interfere with the functionality of BTC.
According to this standard, mainnet upgrades and forks have nothing to do with the L2 concept. The key point is how to classify off-chain expansion routes. For example, the Lightning Network is a special "channel" and it is difficult to say that it is a public chain. The side chain has its own security consensus and operation mode, and its security cannot be strictly equivalent to Bitcoin. But L2 should be hidden in it. Then we continue to divide.
BTC L2 = Lightning Network + Sidechain.
According to the previous standards, BTC L2 should be a hybrid product of Lightning Network and Sidechain. It is completely dependent on Bitcoin Mainnet like Lightning Network, and operates “independently” from Bitcoin like Sidechain. We should take the essence of both and remove the dross of both.
As a result, the existing BTC L2 solutions need further development. Especially considering the fact that BTC's UTXO mechanism and the smart contract mechanism that Layer 2 relies on cannot strictly work together. That is, Bitcoin cannot cancel past transactions, and L2 needs to solve it by itself or introduce an off-chain update or index mechanism.
Secondly, L2 has the problem of being too independent. For example, only storing the block header information of Bitcoin transactions as L2's synchronization proof of L1, or only storing settlement information in Bitcoin scripts as a DA solution, without considering the subsequent retrieval and confirmation issues.
The current status of BTC L2 is easily misunderstood, leading to a security and trust crisis. I believe that we must transition from L2-centric to a new stage centered on Rollup. That is, fully utilizing the security of the Bitcoin mainnet while solving large-scale computing problems.
BTC L2 ≠ Rollup。
BTC builds a PoS system to provide security and uses a permissionless access and destruction mechanism, which is different from the existing asset system. BTC staking income is completely denominated in BTC, and project tokens cannot have functional conflicts with BTC. The Rollup computing layer needs to meet both large-scale and privacy requirements, using encryption technology to combat centralization tendencies. Rollup cannot build additional DA layers and strictly uses Bitcoin as a DA solution.
To sum up, the ideal Rollup should use BTC as the native Gas Fee and staking reward, utilize the 2WP dual-peg mechanism to achieve cross-chain circulation, and the 1:1 anchored mapped asset xBTC should circulate in BTC L2 and cross-L2 bridges. Privacy computing + ZK proof can ensure the complete anonymity and privacy of Bitcoin users from the source and process. Project tokens participate in Rollup operations to avoid role conflicts with BTC.
Rollup is like a bridge, a chain, and an L2
First of all, we need to free our minds. PoW bottom layer + PoS top layer is the optimal solution at present. The source of staking income depends on the underlying value support. Engineering combination replaces technological innovation. It doesn’t make much sense to worry about ZK or OP. Result storage is not DA. In addition, there is no need to over-worry about the mechanism design of centralization and decentralization. No solution can be compared with Bitcoin. Even for ETH OP, the real fault proof and recovery mechanism are "route" or "theoretical". At present or in the long run, it will still be controlled by the project party.
Therefore, a more reasonable mechanism design lies in how to reduce human intervention through technical means and ensure the long-term sustainability of the project.
In ETH L2, it is called the forced withdrawal and escape hatch design. It ensures that the user funds are safe even if the project is shut down in extreme cases. For BTC Rollup, the difficulty here is how to return the mapped assets to the Bitcoin mainnet in the event of a failure, and how to ensure privacy during Rollup calculations, when it was not so decentralized in the early days.
Let’s first discuss the first point. BTC’s mapped assets, such as various decentralized versions of WBTC, must be secure while circulating on Rollup. On the one hand, the entry of BTC can support the value of Rollup. On the other hand, Rollup BTC must be able to be transferred back to the main network in the event of a failure.
Existing solutions are basically all variants of cross-chain bridges. The only difference is whether it is a communication bridge, an asset bridge, or a centralized bridge. At present, it seems that it is basically difficult to come up with new solutions. Bridging assets is the first step in building a PoS system.
However, there is still room for innovation in staking and staking returns. For example, we can skip the development stage of Lido and directly use DVT technology to build a complete decentralized staking system. Or we can build a hybrid staking system based on BTC, WBTC or BounceBit, which is derived from the exchange system and re-staked BTC, to reduce the security impact on BTC during crises.
After bridging and DVT/hybrid staking, Rollup computing has long been neglected. The problem is that Rollup itself must be able to undertake the four stages or parts of the public chain's data throughput, status update and result storage, and data distribution. This can be discussed in two points: one is efficiency, and the other is privacy.
Efficiency is easy to understand. For example, using parallel or concurrent mechanisms. After the early FOMO sentiment, Bitcoin Rollup will compete with ETH Rollup in terms of operating efficiency. And speed-up has been proven to be effective by Solana.
Privacy issues have long been ignored. Bitcoin's PoW mechanism makes it almost impossible to be censored. However, Rollup is extremely vulnerable to censorship pressure after ETH PoS in its early stages. The solution here cannot be achieved through decentralized mechanism design. No solution can be compared with BTC PoW. Privacy computing must be sought.
Finally, there is the DA issue. This is the criterion for judging the difference between ETH L2 and Rollup. If the mainnet is not used as a DA solution, it cannot be called a Rollup. This involves the ultimate security commitment. If L2/Rollup voluntarily abandons the security guarantee of L1, then it should naturally be eliminated. Due to the independent mechanism of BTC, additional supplementary design is required.
Optimistic verification and ZK mixed use has become the mainstream. It means that the transactions on Rollup are finally confirmed by the main network. Fraud proof uses an optimistic mechanism, that is, confirmation first, then troubleshooting, and it will take effect when the time is up. In proof generation, ZK can be used to greatly compress data. This is especially important on BTC Rollup. The reason is that Bitcoin space is too expensive.
The inscription mechanism can play a greater role in the transaction mechanism. On ETH Rollup, once the fraud proof is challenged and accepted by Ethereum, the main network will confiscate the submitter's staked assets. However, on BTC Rollup, this confiscation must be done off-chain. Because once the Bitcoin script is written, it cannot be changed again. The update can only be completed by continuing to write information in the new block, that is, it can only be updated, not overwritten.
The Indexer network actually bears the heavy responsibility of updating transactions. It must be decentralized.
Finally, we can complete the mechanism design of the entire BTC Rollup. It can be divided into four steps, and basically the technical architecture will be built along the four steps of xBTC---> pledge---> calculation---->DA. The difficulty here mainly lies in the design principles of the pledge system and mapped assets, as well as the privacy issues of on-chain calculations and the final DA design.
In addition, the principle that project tokens cannot conflict with BTC must be followed. Project tokens should play a role within Rollup, such as the construction of the DVT system, the decentralized maintenance of the indexer, and the circulation of the ecological development and governance system.
The Big Picture: BTC L2 Review
If we use the Rollup I defined as the standard, then obviously many project proposals cannot be included in the discussion. Therefore, the scope is relaxed. Any project with the above characteristics can be
Be intuitively commented.
According to the order of the four steps, we can compare the current mainstream technical solutions. It should be noted that each step is linked to each other, but the premise will be assumed to exist and will not be repeated. For example, the next step of the bridge is staking, so when discussing staking, the implementation method of the bridge will not be emphasized, and it will be progressive.
From the perspective of bridging assets, ZetaChain and Zeus Network are the most suitable. They bridge the Bitcoin and EVM ecosystems and the Solana ecosystem respectively. In terms of specific implementation, the two are slightly different.
ZetaChain has created the ZRC-20 standard, which is similar to ERC-20. BTC can be mapped 1:1 to issue zBTC tokens. At the same time, in order to highlight the concept of full-chain Omni, zBTC actually has an internal exchange mechanism and will not be actually transferred to the target chain, thereby turning zBTC into a so-called full-chain asset. However, this kind of mapped asset requires a strong mechanism design. ZetaChian uses observers and signers to monitor transactions and events on the Bitcoin chain and reach consensus on ZetaChain, thereby achieving interaction with non-smart contract blockchains such as Bitcoin.
Theoretically, ZetaChain is a full-chain cross-chain bridge that can communicate more than just Bitcoin and EVM ecosystems. However, the focus here is to explain how non-smart contract public chains such as Bitcoin can access EVM. It can be seen that ZetaChain is not only a message bridge, but also an asset bridge.
Zeus Network emphasizes that it is a communication layer rather than a cross-chain bridge. In terms of its mechanism design, it provides a standardized interface through which different blockchains can exchange information and value.
For example, BTC can be locked in a specific Bitcoin address and released on Solana. However, the actual transfer of BTC and the operation of smart contracts on Solana can change the behavior on the Bitcoin network.
It can be seen that this is more like a word game. In theory, there is no need to transfer assets between the two chains, but in reality, you cannot really transfer BTC to the Solana network. Bridging assets or information essentially requires the introduction of a third party to call and communicate with each other, and the only difference is the degree of involvement.
After the assets are bridged, a pledge system will emerge. The significance of pledge is to imitate the security commitment of the ETH network. For example, the four mechanisms of Stake, LSDFI, Restake and LRTFi all have the fundamental logic of staking to ensure the security of the main network and issuing equivalent certificates to participate in DeFi to earn income. The difference lies in the degree of "nesting dolls".
In the practice of Bitcoin, Merlin Chain is the representative of the pledge system. BounceBit is the representative of LRTfi, but the core of both is to attract users to keep their assets in their own systems. It is not just about depositing coins to earn interest, but it hopes to expand the boundaries of the ecosystem while maintaining security, and the era of usability is gradually coming.
In addition to violently pumping the market, Merlin Chain is committed to ecological development in terms of mechanism. Based on the L1 BTC multi-signature and L2 smart contract system, it has built many use scenarios on L2, such as Merlin Swap, Merlin Starter and many other ecosystems. It is currently the most capable of doing things in Layer 2. It and ETH L2 ZKFair are from the same school and are both products of Lumoz. It cooperates with Cobo to build an L2 asset management system, and its current TVL is 3.6 billion US dollars, which is basically the highest level.
BounceBit goes one step further, or one step back.
The progress is that BounceBit produces re-pledged assets based on exchanges. Users can directly deposit BTC in Binance and exchange it for wrapped assets in BNB Chain, and can participate in CeFi and DeFi trading activities. Furthermore, using custody technology, BounceBit can issue LRTfi assets while keeping Bitcoin, and the EVM-compatible system built can connect to the on-chain world.
In the operation of the entire network, CEX and custody are the basis of operation, and the uniqueness of BounceBit lies in the re-issuance of liquidity of the locked BTC and the investment in the logic of asset appreciation. The current TVL is 700 million US dollars, and BTC or its own tokens can be deposited in the staking network. The overall idea is to use more centralized measures to reduce the risk of BTC operation.
A step further is that this is a slightly improved version of WBTC, and it has not even been running for a long time, so its security level may not be comparable to the old WBTC.
Next is the on-chain computing link, which requires solving two problems: one is the decentralization of the sorter and the sorter, and the second is compatibility and computing efficiency.
The centralization of the sorter is a chronic disease on ETH L2. Fundamentally, the use of a centralized sorter can greatly improve the operating efficiency of L2 and prevent MEV attacks to a considerable extent. It also helps to improve the user's trading experience. In addition to these benefits, there is a serious centralization problem that will cause the project party to become the de facto operating entity.
In terms of compatibility, the compatibility of EVM or SVM is easy to solve, but the cross-chain between L2 will be more complicated, and computing efficiency requires the large-scale introduction of parallel or concurrent means. There are currently no particularly obvious practical projects.
Another issue is privacy protection for on-chain computing. Although there are currently solutions using ZK-Rollup, they are mainly used to compress data and occur more frequently in DA data release. There are no obvious projects specifically for privacy protection solutions for the computing process.
Finally, the data publishing method of DA needs to be discussed in combination with the ZK mechanism. Unlike ETH L2, BTC L2 uses ZK mainly to compress data, such as Bitlayer.
Bitlayer uses an optimistic verification mechanism to reduce complexity in execution, uses ZK to compress data, and writes data in a form similar to an inscription. Specifically, it assumes that a batch of transactions is valid by default unless there is evidence to prove it is invalid. In this way, transactions can be processed quickly off-chain and submitted to the Bitcoin network in a compressed format, reducing data load and cost. If fraud is discovered, participants can initiate challenges to trigger state rollbacks and punish malicious actors to ensure system security.
However, how to construct a state rollback based on Bitcoin may not be that simple and still requires long-term exploration.
Conclusion
Starting from the Bitcoin expansion plan, we try to outline what the Bitcoin version centered on Rollup should look like. The core is to ensure that the value and security of BTC are migrated to Rollup, and it needs to be distinguished from the existing package asset solution. In terms of specific implementation, solutions based on bridging assets and pledge systems have become a common choice, but how to ensure decentralization and give full play to the role of BTC and mainnet tokens is still in a gray area.
However, the Rollup-centric route is still the most complete and more mature than the UTXO-based mechanism or client-side verification scheme. In the middle on-chain link, privacy computing and sequencer decentralization are two key points. In the final DA, inscriptions have provided a relatively mature reference idea. The only difficulty is the cost issue.
