A new version of the BTC L2 story: Rollup-centric design principles

Source: Zuoye Waiboshan

Bitcoin expansion route ≠ BTC L2.

At the beginning of the new year, I summarized the technical route of BTC L2, which is mainly divided into two parts: BTC's security and value upside, and L2 transaction execution and the downside of the results. With the development of time, in less than three months, BTC L2 has reached the order of magnitude of nearly 100, but there are still some basic issues to be clarified, and the definition issue is the first.

In the history of Bitcoin development, there have been three practices in the expansion route for a long time. The bottom layer is the main network upgrade, such as SegWit and Taproot, followed by off-chain expansion, such as client verification, lightning network and side chain and many other attempts, and finally direct forks, such as Dogecoin, BSV, BCH, etc.

From the inside out, it is complicated and confusing. 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 completely guaranteed by L1, the underlying value of L2 is supported by BTC, and L2 tokens cannot interfere with the function of BTC.

According to this standard, mainnet upgrades and forks have nothing to do with the concept of L2. The key point is how to classify the off-chain expansion route. 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. The security cannot be strictly equivalent to Bitcoin, but L2 should be hidden in it, so let's continue to divide it.

BTC L2 = Lightning Network + Side Chain.

Referring to the previous standards, BTC L2 should be a hybrid product of Lightning Network and Side Chain, that is, it is completely dependent on the Bitcoin mainnet like the Lightning Network, and it operates "independently" from Bitcoin like the side chain, taking the essence of both and removing the dross of both.

As a result, the existing BTC L2 solutions need to be further developed, 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 achieve the revocation of past transactions, and L2 needs to solve it by itself or introduce an off-chain update or indexing mechanism.

Secondly, L2 has the problem of being too independent, such as only storing the block header information of Bitcoin transactions as L2's synchronization proof of L1, and only storing the settlement information in the Bitcoin script as a DA solution, without considering the subsequent retrieval and confirmation issues.

The current situation of BTC L2 is very easy to be taken advantage of, leading to a security and trust crisis. I believe that it is necessary to transition from L2-centered to a new stage centered on Rollup, that is, to fully utilize the security of the Bitcoin mainnet while solving large-scale computing problems.

BTC L2 ≠ Rollup.

1. BTC builds a PoS system to provide security and uses a permissionless access and destruction mechanism, which is different from the existing package asset system.

2. BTC pledge income is completely denominated in BTC, and project tokens cannot have functional conflicts with BTC.

3. The Rollup computing layer needs to meet both large-scale and privacy requirements, using encryption technology to fight against centralization tendencies.

4. Rollup cannot build additional DA layers and strictly uses Bitcoin as a DA solution.

To summarize, the ideal Rollup should use BTC as the native Gas Fee and staking reward, use the 2WP dual-peg mechanism to achieve cross-chain circulation, and the 1:1 anchored mapping asset xBTC circulates 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 L2

First of all, we must liberate our minds. PoW bottom layer + PoS upper 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 worry too much about the centralized and decentralized mechanism design. No solution can be compared with Bitcoin. Even if it is ETH OP, the real fault proof and recovery mechanism are also "route" or "theoretically". At present or in the long run, it will still be controlled by the project party.

Therefore, a more reasonable mechanism design is how to reduce human intervention through technical means and ensure the long-term stable operation of the project. In ETH L2, it is called forced withdrawal and escape hatch design, which ensures that the user funds can be guaranteed 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 protect privacy during Rollup calculations, when it was not so decentralized in the early days.

First, let's discuss the first point. BTC's mapped assets, such as various decentralized versions of WBTC, must ensure security while circulating on Rollup. On the one hand, BTC can only support the value of Rollup when it enters, and on the other hand, Rollup BTC must be able to be transferred back to the mainnet in the event of a failure.

The existing solutions are basically all kinds of 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 is basically difficult to have new solutions. Bridging assets is the first step in building a PoS system.

However, there is still room for innovation in staking and staking income. For example, we can skip the development stage of Lido and directly use DVT technology to build a complete decentralized staking system, or build a hybrid staking system based on BTC, WBTC or BounceBit, and based on the re-staking BTC derived from the exchange system, so as to reduce the security impact on BTC during crises.

After bridging and DVT/hybrid staking, Rollup calculations have been neglected for a long time. The problem here is that Rollup itself must be able to bear the four stages or parts of the public chain's data throughput, state update and result storage, and data distribution. It can be discussed in two points, one is efficiency, and the other is privacy.

• Efficiency is easy to understand, such as using parallel mechanisms or concurrent mechanisms. After the early FOMO mood, Bitcoin Rollup will compete with ETH Rollup in terms of operating efficiency, and speed-up has been proven to be really useful by Solana.

• Privacy issues have long been ignored. Bitcoin's PoW mechanism makes it almost impossible to be censored. However, in the early stages, Rollup is extremely vulnerable to the dilemma after ETH PoS, that is, certain types of nodes are subject to and cater to the censorship mechanism. The solution here cannot be achieved through decentralized mechanism design. Any solution cannot be compared with BTC PoW, and privacy computing must be sought.

Finally, there is the DA problem, which refers to the criteria for judging the division between ETH L2 and Rollup. If the main network is not used as a DA solution, it cannot be called a Rollup. This involves the ultimate security commitment. If L2/Rollup actively abandons the security guarantee of L1, then it should naturally be eliminated. Due to the independent mechanism of BTC, additional supplementary design is required.

• The mixed use of optimistic verification and ZK has become the mainstream, which means that the transactions on Rollup are ultimately confirmed by the main network, and the 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, which 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, but on BTC Rollup, this confiscation must be done off-chain, because once the Bitcoin script is written, it cannot be changed again, and can only be updated by continuing to write information in the new block, that is, it can only be updated, not overwritten.
  

  The indexer network actually has to bear the heavy responsibility of transaction updates and must be decentralized.

Finally, we can complete the mechanism design of the entire BTC Rollup, which can be divided into four steps. Basically, the technical architecture will be built along the four steps of xBTC--->staking--->calculation---->DA. The difficulty here lies mainly in the design principles of the staking system and mapped assets, as well as the privacy issues of on-chain calculations and the final DA design.

In addition, following the principle that project tokens cannot conflict with BTC, 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 horizontal and vertical review

If the Rollup I defined is used as the standard, then obviously many project plans cannot be included in the discussion, so the scope will be broadened and all projects with the above characteristics can be commented on intuitively.

According to the order of the four steps, we can compare the current mainstream technical solutions. It should be noted that each step is closely linked, but the premise will be assumed to exist and will not be repeated. For example, if the next step of the bridge is staking, then when discussing staking, the implementation method of the bridge will not be emphasized, and it will be progressive.

From the perspective of bridged assets, ZetaChain and Zeus Network are the most in line with the standards, communicating with Bitcoin and EVM ecology and Solana ecology respectively. In terms of specific implementation, the two are slightly different.

ZetaChain has created a ZRC-20 standard similar to ERC-20. BTC can be mapped to zBTC tokens at a 1:1 ratio. 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 transmitted to the target chain, thereby turning zBTC into a so-called full-chain asset. However, this mapping 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 to achieve interaction with non-smart contract blockchains such as Bitcoin.

In theory, ZetaChain is a full-chain cross-chain bridge that can communicate more than just Bitcoin and EVM ecology, but the focus here is to explain how non-smart contract public chains such as Bitcoin can access EVM. It can be found 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, it is necessary to actually transfer BTC and perform smart contract operations on Solana to change the behavior on the Bitcoin network.

It can be found that this is more like a word game. In theory, there is no need to transfer assets between the two chains, but in fact, 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. The difference lies only in the depth of intervention.

After the assets are bridged, a pledge system will appear. 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, the fundamental logic is to pledge to ensure the security of the main network and issue equivalent certificates to participate in DeFi to earn income. The difference lies in the degree of "nesting".

In the practice of Bitcoin, Merlin Chain is the representative of the pledge system, and 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 simply to earn interest on deposits, but to try to expand the boundaries of the ecosystem while preserving security, and the era of usability is gradually coming.

In addition to violent pull-ups, Merlin Chain is committed to ecological development in terms of mechanism. Based on L1 BTC multi-signature and L2 smart contract system, it then builds usage scenarios on L2, such as Merlin Swap, Merlin Starter and many other ecosystems. It is currently the most trouble-making in Layer 2. It and ETH L2 ZKFair come from the same school, both are Lumoz products. 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.

And BounceBit goes a step further, or a step back.

The progress is that BounceBit produces re-pledged assets based on exchanges. Users can deposit BTC directly on Binance and exchange it for wrapped assets on 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 is that the locked BTC is re-issued for liquidity and invested 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 pledge network. The overall idea is to use more centralized measures to reduce the risk of BTC operation.

A step back is that this is a slightly improved version of WBTC, and even without long-term operation, its security may not be better than the old brand of WBTC.

The next step is the on-chain calculation link. There are two problems to be solved here. One is the decentralization of the sorter and the sorter, and the second is the compatibility and calculation 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, which will cause the project party to become a de facto operating entity.

B² Network attempts to use its own BSQ mainnet token to build a decentralized sorter network, which is actually equivalent to building an incentive network. It needs to combine more roles such as submitters, provers, and challengers to maintain operation, that is, to use the complexity of governance to reduce the degree of centralization.

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 the computing efficiency requires the large-scale introduction of parallel or concurrent means. There are currently no particularly obvious practical projects.

Another is the privacy protection of on-chain computing. Although there are currently solutions using ZK-Rollup, they are mainly used to compress data, and more often occur in DA data release. There is no obvious project specifically for privacy protection solutions for the computing process.

Finally, the data release method of DA needs to be discussed in combination with the ZK mechanism. Unlike ETH L2, BTC L2 mainly uses ZK 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 the transaction batch 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 found, participants can initiate challenges, trigger state rollbacks and punish malicious actors to ensure system security.

However, how to construct state rollbacks based on Bitcoin may not be that simple, and long-term exploration is still needed.

Conclusion

Starting from the Bitcoin expansion plan, we try to outline what the Bitcoin version of Rollup-centric should look like. The core is to ensure that the value and security performance of BTC are migrated to Rollup, and it needs to be distinguished from the existing package asset plan. In terms of specific implementation, the solution based on bridge assets and pledge system has become a common choice, but how to ensure decentralization and play the role of BTC and main network tokens is still in a gray area.

However, the Rollup-centric route is still the most complete at present. Compared with the UTXO mechanism or client verification solution, it is more mature. In the middle of the chain link, privacy computing and sorter decentralization are two key points. In the final DA, Inscription has provided a relatively mature reference idea. The only difficulty is the cost issue.