Recently, Citrea, which claims to be the first Bitcoin Layer 2 project utilizing the zk-Rollup scheme, has come under scrutiny from the community just as it is about to launch on the devnet. The community members have accused Citrea of employing deceptive rhetoric to excessively hype their project. In this controversy, it is undoubtedly the best time to examine Citrea and BitVM.

The origin of all this lies in the success of Zero-Knowledge Proofs (ZKP) on Ethereum-based Layer 2 solutions, prompting many to wonder if ZKP could be similarly utilized for Bitcoin Layer 2. Many developers, particularly the most critical ones, are pessimistic about the development of Bitcoin Layer 2, and their concerns are quite justified. Traditional Layer 2 solutions, such as Ethereum’s optimistic and zk-rollup, operate by off-chain computation and on-chain verification, which compresses data of the first layer and expands computational resources. However, since the Bitcoin network does not support complex logic validation, this approach is difficult to implement. Therefore, most Bitcoin Layer 2 projects claiming to utilize zero-knowledge proof have adopted a model known as Sovereign Rollup.

The Sovereign Rollup

In essence, the key to Sovereign Rollup is that the Bitcoin network is solely responsible for storing crucial commitment data as inscriptions within the Bitcoin Network, while all verifications are conducted off-chain (client verification). In a nutshell, data in the Bitcoin network is meaningless to a participant who is unaware of the rules. However, if participants understand how this data is used, any user can set up their node. From this perspective, Sovereign Rollup indeed holds significant positive implications—it meets some basic requirements of a Layer 2 network, such as the finality of data being protected by Bitcoin consensus, while also allowing for decentralized interpretation of Layer 2 data.

How sovereign rollup works: save proof on-chain, verified off-chain.

This approach might seem like a compromise compared to the first, but it is a subject of considerable debate. Many proponents of this approach believe that Bitcoin does not need to mimic Ethereum: supporters of the first approach are still viewing Bitcoin through an Ethereum lens, that is, they believe that both data storage and verification should occur on Layer 1. However, this is not necessary since data verification can significantly waste the efficiency of Layer 1. Ideally, any smart contract should be executed by only one node, and other nodes would only need to verify the result and its corresponding proof. There are better answers than requiring all Layer 1 nodes to perform verification. As far as we know, several projects have already implemented the concept of sovereignty, including Stacks, Bison, etc.

This philosophy is at the core of Sovereign Rollup, based on the concept of client-side verification. Whether seen as a compromise or an innovation, just as the community was preparing to embrace a Bitcoin-specific Layer 2 technological path, BitVM was born.

BitVM

BitVM remains a mystery to most of the community: it seems to propose a solution for conducting ZKP verification on Layer 1, yet this solution eventually requires execution via an optimistic rollup method. Early iterations of BitVM even suggested simulating a CPU on Bitcoin to facilitate any conceivable computation, akin to building a computer using Redstone in Minecraft. These peculiar claims were scoffed at by many, who opted for more practical approaches like DLC or custodial accounts to ensure the security of Layer 2 assets. However, some projects believe that BitVM represents the future of Layer 2 and have invested heavily in research, including today’s focal point, Citrea. Understanding exactly what BitVM is, becomes crucial.

To unravel the truth about BitVM, we will adopt the most direct approach: analyzing the BitVM Github Repository. At its core, the BitVM repository includes:

• A virtual environment for running Bitcoin Script.
• Auxiliary functions for assembling Bitcoin Script scripts.

The current construction of BitVM primarily involves combining Bitcoin’s opcodes to facilitate more complex computations, rather than using OP_XOR to build computational components as mentioned in its initial versions. This is a more pragmatic approach. Let’s examine a relatively simple example to see how BitVM works: performing uint32-type integer calculations by combining opcodes.

BitVM is kinda like a Lego: formed by basic opcode.

In this example, we can identify two distinct elements: Opcodes and a series of new, encapsulated Opcodes. The ones prefixed with OP_ are native Bitcoin script Opcodes, while functions like u8_add_carry represent new Opcodes customized by BitVM. Clearly, the function u32_add itself is also used in the construction of further Opcodes.

This may sound somewhat simplistic, but these functionalities should not be underestimated. They actually form the foundation for further constructing Zero-Knowledge Proofs (ZKP); through calculations with u32, one can progressively build up to BN254 computations, eventually leading to a proof construction system. From what can be seen in the repository, they have achieved many noteworthy accomplishments: they have managed to build verification functions based on Groth16, indicating they are close to ultimately constructing a usable ZKP system.

Citrea Devnet And BitVM

After gaining insight into the current status of BitVM, we naturally rejoice at its progress, which has significant positive implications for the entire Bitcoin Layer 2 ecosystem. However, we also notice a certain asynchrony between the explosive growth of Bitcoin Layer 2 and the development pace of BitVM. In a nutshell, projects claiming to utilize BitVM should more accurately be understood as “intending to use BitVM,” since, despite encouraging results, it is not yet ready for commercial deployment. In this context, Citrea’s claim to be the first Bitcoin-based zk-rollup inevitably sparks controversy.

When BitVM is incomplete, Citrea is a typical sovereign rollup

Our primary concern is the current relationship between Citrea, BitVM, and ZKP. The best approach remains to delve into the Citrea project’s code to observe their progress. After analyzing their devnet repository, we discovered some interesting findings:

Sovereign, not BitVM

Currently, Citrea remains a typical Sovereign Rollup and has not achieved equivalence to Ethereum’s Layer 2 zk-rollup. In their recent devnet announcement, also mentioned that BitVM and their core component, Clementine, are not yet complete. The present state is such that Citrea’s network maintains the account states as a Merkle tree root, and on Bitcoin, this Merkle root change along with its corresponding ZKPs are recorded through Inscriptions. Importantly, inscribing on the Bitcoin network is unrestricted; hence, these ZKPs and the Merkle tree root need to be proactively verified by Citrea’s nodes. Meanwhile, Bitcoin only finalizes its state but does not ensure its correctness. Unfortunately, Citrea is still a typical Sovereign Rollup; its integration of BitVM is limited to the off-chain verification of ZKPs. Their bridge is in the traditional multisig-based manner.

Sovereign approach: inscription in Bitcoin does not ensure the correctness of proof

RISC ZERO

Besides the argument in BitVM, we also care about how ZKP is adopted in Cirtea devnet, and if there is anything new. For their ZKPs and zkEVM segment, Citrea utilizes an SDK provided by RISC ZERO as their construction foundation. RISC ZERO, a newer ZKP solution that emerged in 2022, shares a vision very similar to Cairo, to enable any generic computation with ZKPs through the creation of a zkVM. However, unlike Cairo, RISC ZERO is not a language in itself; it can be directly built using an SDK available in Rust, then computed through its custom zkVM. Apart from RISC ZERO, the Cairo VM based on zk-STARKs is also favored by Bitcoin Layer 2 projects like Bison. We have noticed this trending situation that projects adopting this model of general computation + zkVM, replacing the older model of zk language + zk Prover + zk Verifier. This shift is because Bitcoin currently cannot provide a zk Verifier, making the direct use of a zkVM undoubtedly a more economical and efficient approach for Sovereign Rollups.

Conclusion

Regarding the recent controversy surrounding Citrea devnet, their team has clearly indicated that their compatibility with BitVM is not yet complete; this conclusion implies that a rollup fully inheriting Bitcoin’s security has not yet emerged. However, in observing the entire project, we have also witnessed ongoing innovation based on Bitcoin Layer 2, while the new projects still attempting the BitVM approach like Alpenlabs and Bitlayer. These developments continue to drive us to track and analyze the progress of Rollups within Bitcoin persistently.

About ScaleBit

ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.

Requests a quote

• Website
• Twitter
• Telegram