Recently, Citrea, the first Bitcoin Layer-2 project that claims to use the ZK-Rollup solution, has been questioned by the community as it is about to launch its testnet. Its promotion of Citrea uses some deceptive rhetoric and over-packages its project. At this cusp, it is undoubtedly the best time to study Citrea and BitVM.
The reason for everything is that ZKP has been very effective on Ethereum-based Layer2, making many projects hope that ZKP can also be used on Bitcoin Layer-2. Obviously, a large number of developers (especially the most picky ones) are very pessimistic about the development of Bitcoin Layer2, and their concerns are reasonable. Conventional Layer2, such as Ethereum-based optimisic and zkrollup, compress the data of a layer of the network and expand computing resources through off-chain calculation and on-chain verification. However, this solution is difficult to implement because the Bitcoin network does not support complex logic validation. Therefore, most Bitcoin Layer-2 projects that claim to use zero-knowledge proof technology have adopted a solution called Sovereign Rollup.
The Sovereign Rollup
To make a long story short, the key to Sovereign Rollup is that the Bitcoin network is only responsible for storing key commitment information in the Bitcoin Network in the form of inscriptions, and all verification is done off-chain (client verification). In short, the right to interpret the data in the Bitcoin network belongs to the Layer2 network. For a participant who does not know the rules, the data in the Bitcoin network is meaningless. But if the participants know how to use this data, then any user can build a node by themselves. From this perspective, Sovereign Rollup does have quite positive significance. It can meet some basic requirements of Layer2 network, that is, the finalization of data can be protected by Bitcoin consensus, and its Layer2 analysis can also be decentralized.
It sounds like the second solution is a compromise of the first solution, but there is actually a lot of controversy on this point. A large number of supporters of Solution 2 believe that Bitcoin does not have to be the same as Ethereum: supporters of Solution 1 actually still view Bitcoin from the perspective of Ethereum, that is, they believe that data storage and verification should occur in Layer-1. But in fact, this is not necessary, because data verification is a great waste of Layer-1 efficiency. Ideally, any smart contract should be executed by only one node, and other nodes only need to verify the execution results and the corresponding evidence. Forcing all Layer-1 nodes to verify is not necessarily the best answer.
Sovereign Rollup Principle: Store evidence on the chain, verify off the chain
This philosophy is the core of Sovereign Rollup, which is based on the idea of client-side verification. In short, whether it is compromise or innovation, just when everyone is ready to accept Bitcoin's unique Layer-2 technology route, BitVM was born.
BitVM
What exactly is BitVM is a mystery to most people in the community: BitVM seems to have proposed a solution that can perform ZKP verification on the first layer, but this solution ultimately needs to be implemented using the optimistic Rollup method. Early BitVM also proposed to simulate the CPU on Bitcoin to achieve all possible calculations - it sounds like using redstone to build a computer in Minecraft. These weird claims made most people sneer at them, and adopted more practical routes such as DLC or account custody to protect the asset security of Layer-2. However, there are also some projects that believe that BitVM is the future of Layer-2 and have invested a lot of research, such as today's protagonist Citrea. Obviously, it is very important to figure out what BitVM is.
In order to find out the truth about BitVM, we will take the most direct approach: analyzing BitVM's Github Repository. Overall, the core of the BitVM repository includes:
The current construction of BitVM is mainly to achieve more complex calculations by combining Bitcoin's Opcodes; instead of using OP_XOR to build calculation components as mentioned in the initial version. Obviously, this is a more practical route. Let's use a practical example to see how it works: by combining Opcodes, integer calculations of type uint32 are performed.
BitVM is actually like a building block: it is spliced together by basic OP_CODE
In this example, we can find two different elements: Opcode, and a series of new Opcodes that have been encapsulated. Among them, the ones with the OP_ prefix are native opcodes of Bitcoin scripts, while functions such as u8_add_carry represent new opcodes that have been encapsulated and customized by BitVM. Obviously, this function u32_add itself will also be used for other further opcode constructions.
This sounds a bit simple, but don't underestimate these functions. They are actually the basis for further construction of ZKP; through the calculation of u32, bigint can be gradually constructed, and even bn256 calculations can be constructed, and finally a proof construction system can be obtained. And from the warehouse, they have achieved many achievements worth mentioning: they have been able to build a verification function based on Groth16! It seems that they are not far away from finally building a usable ZKP.
Citrea and BitVM
After learning about the current status of BitVM, we are of course happy to see its success, which has extremely positive significance for the entire Bitcoin Layer-2 ecosystem. However, we also noticed that there is a certain asynchrony between the outbreak of Bitcoin Layer-2 and the development pace of BitVM. After all, time waits for no one. Projects that claim to have adopted BitVM should actually be understood as "will adopt BitVM". After all, despite the gratifying results, it is not yet commercially available. In this way, Citrea's claim to be the first zk-rollup on Bitcoin is bound to cause controversy.
Before BitVM was officially completed, Citrea was an autonomous Rollup
Our first and most important question is: What is the current relationship between Citrea and BitVM, and even ZKP? Obviously, the best way is still to go deep into the code of the Citrea project to observe their current progress. After analyzing the official repository of their test network, we found some interesting things:
(1) Sovereign Rollup
Citrea is still a typical Sovereign Rollup, and has not achieved a zk-rollup that is truly equivalent to Ethereum Layer-2. Regarding this point, in fact, Citrea also mentioned in their testnet announcement that BitVM and their core component, Clamentiane (https://www.blog.citrea.xyz/unveiling-clementine/), are not yet completed. The current situation is that they will save the account status in the Citrea network as a Merkle root, and record the changes of the Merkle root and its corresponding ZKPs on Bitcoin through Inscription. Obviously, there is no need for any restrictions on inscription on Bitcoin; therefore, these ZKPs and Merkle roots need to be actively verified by Citrea's nodes. At the same time, Bitcoin is only responsible for finalizing its status, but not for ensuring its correctness. Therefore, unfortunately, Citrea is still a typical Sovereign Rollup; its BitVM participation is only in the part where nodes actively verify ZKPs.
Limitations of autonomous verification: Unable to ensure the validity of on-chain evidence
(2) RISC0
Citrea uses the SDK provided by RISC0 as the basis for their ZKPs and zkEVM. RISC0 is a relatively new ZKPs solution born in 2022. RISC0 and Cairo have very similar visions - by building a zkVM, ZKPs can perform any general calculations; but compared to Cairo, RISC0 itself is not a language, it can be built directly through the SDK provided in Rust. After that, calculations are performed through its customized zkVM. In addition to RISC0, Cairo VM based on zk-STARK is also favored by Bitcoin Layer-2. We have noticed that many projects are adopting this general computing + zkVM model to replace the zk language + zk Prover + zk Verifier model. This is because zk Verifier is not available in Bitcoin for the time being, so for Sovereign Rollup, directly adopting zkVM is undoubtedly a more economical and efficient method.
Conclusion
First of all, regarding Citrea’s recent controversy, their team clearly pointed out that its compatibility with BitVM has not yet been completed; this conclusion represents that Rollup that can fully inherit Bitcoin’s security has not yet appeared. However, in the process of observing the entire project, we also saw continuous innovation based on Bitcoin Layer-2; at the same time, there are still a large number of projects that are challenging Bitcoin's zk-rollup, such as Bitlayer, Alpenlabs, BVM network, etc. These are driving us to continue tracking and analyzing the progress of Bitcoin's Rollup.