1. The uniqueness of Bitcoin L2
Under the overwhelming attack of Btc L2, maybe we need to think carefully about what is the significance of Btc L2? Only by solving this problem can we know whether what we are doing now is right.
For ETH's L2, we mainly consider it from the perspective of TPS and gas fee, because the ETH main chain itself has complete smart contracts, asset issuance, DEFI operations and other capabilities. However, in view of cost issues and confirmation speed issues, L2 is used to better adapt to the needs of different projects. The design of L1 as the computing layer and security layer is very reasonable.
It is easy for us to think of BTC L2 according to the definition of ETH L2. At the same time, given the limited scripting capabilities of the BTC mainnet, scalability is also a focus of attention. According to this idea, we can conclude that the problems that BTC L2 needs to solve are:
1️⃣ Improve scalability
2️⃣ Improve transaction speed
3️⃣ Reduce transaction fees
Therefore, we can see the ideas of some current projects. For example, EVM-compatible projects can achieve these three points. RGB can achieve these three points more natively after connecting to the Lightning Network, and so on.
But is this really what is needed today? Are we missing something?
After I took a closer look at ETH holders and BTC holders, I noticed a huge difference:
[ETH holders are used to their assets entering the liquid market, while BTC holders trust themselves to have control]
You can easily see this situation in the market: ETH holders often bet their assets on some projects, whether they are multi-signature or contractual. Everyone is used to having assets out of their control but being able to participate in various projects; but BTC holders are different. They only trust themselves to keep their assets and have all control over their assets.
The result of these two differences is that although the market value of ETH is much lower than that of BTC, ETH is widely used in staking, restaking, defi, and derivative projects; although the market value of BTC is over one trillion US dollars, most of it is dormant in users' cold wallets and exchanges around the world, and is not active in the market.
Therefore, I think there is still a prerequisite problem that needs to be solved in the current development of BTC L2 ecosystem:
How to activate BTC assets?
2. Bitcoin Locking Methods
If you want to activate BTC assets, you will inevitably encounter a problem: how to lock BTC? Because it is very difficult to perform various operations on the main network, if you want to be active (participate in various projects), you have to have the problem of locking and conversion.
In fact, there are not many technical routes for BTC locking due to the extremely limited script capabilities of the main network. There are five common ones:
2.1 Multi-Signature Bridge
This is the most common method we see, and it is also the method with the lowest technical threshold (please forgive my blunt language). Users transfer their BTC assets to a multi-signature account, and then a "shadow asset" is generated for the user on the target chain. Users use the shadow asset to participate in various scenarios. When you want to exit, you can use the shadow asset to exchange for BTC.
The most common form of multi-signature is m of n, that is, n signatures, at least m are required to unlock. The most criticized aspect is the transfer of ownership. The security of user assets depends entirely on the security of multi-signature accounts. Since the BTC mainnet does not have the ability of smart contracts, the security of multi-signature accounts is completely subject to the "moral level" of the multi-signers.
Of course, there are many derivative solutions for this situation, such as increasing the number of multi-signers, MPC solutions, etc. However, they still cannot solve the problem of centralized custody in essence.
2.2 Optimistic Bridge/ZK Bridge
The ZK bridge confirms the validity of the cross-chain message through zero-knowledge proof, and the optimistic/OP bridge challenges the invalid cross-chain message on-chain through fraud proof. Only one honest challenger is needed to ensure the security of the cross-chain bridge.
Due to technical limitations, the Bitcoin mainnet cannot directly deploy the ZK bridge, but an optimistic bridge can be implemented through BitVM and fraud proofs.
However, the BitVM-based solution is unlikely to be implemented in a short period of time due to its complexity. It also has activity/availability issues and cannot meet the need for fund transparency.
2.3 DLC Solution
DLC (Discreet Log Contracts) is called a prudent log contract, which was proposed by MIT's Digital Currency Initiative. The technology was first used to implement a lightweight smart contract on Bitcoin. There is no need to put the content of the contract on the chain. Through off-chain interactive communication and pre-signature methods, the smart contract function of protecting privacy can be implemented on the Bitcoin chain.
The DLC solution predicts and writes various possible situations into the conditions, and then executes according to the assertion of the assertion machine. Therefore, DLC transforms the security of the multi-signature participants into the security of the assertion machine. Relatively speaking, we cannot control the multi-signature people, but we can use certain means to improve the assertion machine to prevent evil. For example, the introduction of OP+DLC can enhance the security trust of DLC.
2.4 Time Lock
Time lock is a more native solution that is an extension of the capabilities of BTC's existing scripts.
The Bitcoin system can implement two types of time locks: one is called an "absolute time lock", which is unlocked after a "specific" time point (such as a certain date or a certain block height); the other is called a "relative time lock", which is unlocked after a certain delay (such as the number of blocks), and the starting point of the delay is the time when the script (output) containing the time lock is confirmed.
Through time locks, BTC can be pledged and pledge certificates can be generated, and pledge certificates can be used in certain scenarios, such as the security economic layer of some POS chains. This is what Babylon and Chakra are doing.
2.5 Script Extension
Another possible way is to expand the script. Since this is not possible, if we add more opcodes to the BTC mainnet, will there be more possible solutions? The answer is obviously yes.
The recent OP_CAT proposal is an attempt in this regard, although I think the chances of it being passed are slim; Liquid is developing a new scripting language called "Simplicity", which may be more worth looking forward to.
However, the difficulty with this type of solution is how to convince the core team to accept this upgrade and get miners to support such an upgrade. Because for the core team, maintaining the extreme stability of the BTC network is obviously much more important than improving scalability to a certain extent. This does not mean rejecting innovation, but requires a lot of inspections and tests to minimize the huge potential risks that this may bring to the future.
3. Chakra Project Introduction
Now let's look at a project like Chakra. I will explain it from a few basic points:
3.1 Objectives
Build a secure Bitcoin Proof-of-Stake system, activate the liquidity of long-term held Bitcoin assets, and provide decentralized services maintained by asset holders.
3.2 Technical Process
BTC is locked by time lock, and the pledge event generates proof through ZK-STARK technology. The proof (or certificate) is used to verify interest.
In principle, an L2 can be built on top of this, and proof of stake can be verified on L2 to allow stakers to participate in the consensus and governance of L2. These L2s share the security of Bitcoin, providing data availability services and execution environments maintained by stakeholders.
3.3 Technical features
1️⃣ Self-custody: This has been introduced before. It uses a time-lock script method, and assets do not need to be transferred from your own wallet.
2️⃣ ZK-based proof of stake: In Chakra, the declaration of stake events is implemented through ZK-STARK technology, which has the advantage that it does not need to be connected to the BTC network and can be verified off-chain to access relevant verification information. Moreover, because STARK technology does not require trusted settings, it is relatively secure.
3️⃣Multiple staking services: Generated ZK Proofs can be used in multiple scenarios to meet specific needs, such as artificial intelligence, decentralized finance, games, etc. Users only need to stake once, and then they can expand to multiple aspects through authorization, thereby obtaining multiple staking benefits.
3.4 Investment institutions
On April 26, the project announced the investment institutions
Mainly STARKWARE, ABCDE appeared again (it is indeed the master of BTC ecosystem), and Asian miners
3.5 Project Progress
The current devnet will be shut down immediately to prepare for the public testnet
4. Chakra Project Analysis
4.1 Advantages
1️⃣ Like Babylon, Chakra can activate users’ BTC assets in a native way, allowing them to have more usage scenarios without losing control;
2️⃣The adoption of STARK technology allows for better expansion of proof of stake;
3️⃣Multiple pledges can give it the opportunity to become the "Lido" of this track.
4.2 Points to note
1️⃣Regarding the generation and implementation logic of zk-proof, since it involves zk circuits, the implementation details need to be verified;
2️⃣ Regarding the Slash mechanism. Babylon's slash will expose the private key of the malicious user's BTC address and send it to a black hole address. Currently, Chakra does not have a slash mechanism, so the only punishment for malicious behavior is likely to be no block reward. Although this is more friendly to the pledger, whether the security will be affected due to insufficient punishment; however, whether this measure can attract more BTC pledges still needs to wait for market performance.
3️⃣Another point worth explaining is that this type of project cannot allow locked assets to directly participate in DEFI through proof of pledge, because we cannot perform operations such as "liquidation" on the first-layer assets. What we can participate in scenarios such as DEFI is the interest or points generated by staking, which requires the participation of LST (Liquid Staking Token) and LRT (Liquid Restaking Token) mechanisms.
