#64 - Citrea: Scaling Bitcoin’s Future with ZK Rollups
A Deep Dive into Bitcoin's ZK Rollup Solution: Citrea's Clementine Bridge
Stanford Blockchain Review
Volume 7, Article No. 4
📚 Author: Ekrem Bal, Hakan, and Yusuf - Citrea
🌟 Technical Prerequisite: Intermediate
While Bitcoin core values lie in security and decentralization, these strengths create inherent limitations in scalability and programmability. Various scaling solutions like the Lightning Network and side chains tried to overcome these constraints, but none have successfully enabled complex applications without sacrificing Bitcoin's security or modifying its consensus rules.
Citrea introduces a new approach to Bitcoin scalability through a zero-knowledge (ZK) rollup architecture. Zero-knowledge proofs (ZKPs) use cryptography to allow one party to prove to another that a statement is true without revealing the statement. With ZK technology, Citrea enhances the capabilities of Bitcoin’s blockspace, transforming it into a fully programmable financial system while inheriting the network’s core values: security, decentralization, and censorship resistance.
Citrea also inherits validity from Bitcoin through its BitVM-based Bitcoin bridge, Clementine. By combining BitVM, zero-knowledge proofs, and Bitcoin as a data availability layer, Clementine enables the safest and most-trust minimized way to bridge BTC and extend its utility. This article focuses specifically on the workings of Citrea’s BitVM-based Bitcoin bridge, Clementine, discussing its peg-in and peg-out mechanisms and how it optimistically verifies ZKPs.
Clementine: Citrea’s BitVM-Based Bitcoin Bridge
Note that Clementine’s design is not final and is subject to change.
In the past, State Channels and Sidechains were seen by the Bitcoin community as the only viable scaling solutions. However, the lack of programmability in the State Channels and the insecurity of Sidechains led researchers to seek alternative ways to scale Bitcoin. In this search, Citrea emphasized that scaling Bitcoin blockspace is the only way to transact with Bitcoin security, therefore proposed rollups as the most secure and incentive-aligned way to scale Bitcoin blocks. Considering Bitcoin’s block-size limitations, Citrea chose to leverage ZKPs over fraud proofs since they are the most efficient way to verify the validity of execution inside Bitcoin within the block size limit.
ZK Rollups collect thousands of transactions, generate a ZKP to ensure their validity and inscribe the ZKP to Bitcoin alongside the data that can restore the rollups’ state. However, the verification of ZKPs on Bitcoin presents a significant challenge due to Bitcoin’s limited programmability.
An emerging solution to this challenge is BitVM, a computing paradigm for expressing Turing-Complete contracts on Bitcoin without changing its consensus rules. BitVM allows anyone to challenge the execution of a contract if the computation is incorrect, making it an optimistic scheme.
Clementine is a BitVM based trust-minimized two-way peg mechanism between Citrea and Bitcoin that optimistically verifies ZKPs to extend BTC’s utility in the most secure and efficient way. The following sections will cover how Clementine handles peg-in and peg-outs and how it optimistically verifies ZKPs.
Peg-in and Peg-outs
Traditional Bitcoin scaling solutions rely on trusted entities for peg-ins and peg-outs, risking fund loss and censorship. Clementine mitigates these risks through its BitVM-based two-way peg mechanism.
Clementine’s architecture relies on three distinct roles, consisting of signers, operators, and watchtowers. Each performs a different functionality. N entities, each one is called a signer, forms a federation by setting up an N-of-N multisig to collectively decide how funds are going to be spent. Operators are another set of entities that front-covers users’ withdrawals, and later get repaid with a reimbursement process. Watchtowers are responsible for challenging the operator in the case of a malicious act, and gets rewarded if challenge is valid.
Here is an example of how this works. To initiate the deposit process, Alice, the depositor, sends 10 BTC to a predefined Taproot address, shown in Image 1. The bridge signers accept, hence sign, the deposit only if it equals to a predefined fixed amount of 10 BTC. Once all signers approve the transaction, Alice’s deposit is transferred to the multisig, and her corresponding cBTC is minted on Citrea. If the signers reject, Alice gets her deposit back trustlessly using timelocks 200 Bitcoin blocks later.
Before accepting the deposit, each signer pre-signs a set of transactions which will be used to punish the operator in case of a malicious act. These pre-signed transactions include timeout transactions and disprove transactions. Timeout transactions will be used if the operator does not send the given transaction, namely kickoff transactions and assert transactions, within a predefined time period.
Peg-ins can be handled using an N-of-N multisig because signers are not incentived to reject a valid deposit. However, this is not the case when it comes to peg-outs because if multisig handles peg-outs, then any signer will be able to censor them and might have an incentive to censor the withdrawal request. To address this, Clementine uses multiple operators to compete with each other for front-covering withdrawals.
Bob, the person who wants to peg-out, initiates a cBTC burn transaction on Citrea, along with a Partially Signed Bitcoin Transaction. Partially Signed Bitcoin Transaction is initiated by Bob, for an operator to front-cover his peg-out. Bob gradually decreases the amount he will get on Bitcoin by initiating new Partially Signed Bitcoin transactions, incentivizing operators to front-cover his withdrawal. Once front-covering Bob’s withdrawal becomes profitable for an operator, Bob’s peg-out will be fulfilled. Bridge operators later get repaid for the peg-outs they front-covered through a reimbursement process.
To handle the reimbursement process, each operator manages a chain of transactions called Collateral Time Transactions, involving Time Transaction 1, Kickoff Transaction, Time2 Transaction and Timeout Transaction. These transactions allow an operator to reuse their collateral by restricting them to cover 1 withdrawal per 2 weeks. Time Transaction 1, shown in Image 2, is a requirement for the operator to initiate a Kickoff Transaction. A Kickoff Transaction involves the operator's commitment to the transaction ID of the deposit they intend to claim reimbursement for. The operator's commitment will be used in the reimbursement process.
The reimbursement process works optimistically, meaning that as long as watchtowers do not challenge, the operator can continue to cover 1 withdrawal per 2 weeks. If watchtowers do not challenge, the operator gets 10 BTC back by using the reimburse connector output in the Time2 Transaction. Later, the operator covers another withdrawal, initiates a new Time Transaction 2 and the cycle continues as long as the operator behaves honestly. Watchtowers challenge an operator if they’re convinced that an operator is malicious, i.e., tries to claim BTC from the bridge without paying for a user’s peg-out. To challenge an operator, each watchtower generates a succinct longest chain proof of Bitcoin, ensuring that they’re following the Bitcoin blockchain. Along with the longest chain proof, the challenging watchtower also provides 2 BTC to the operator to compensate for the Assert Transaction.
After the longest chain proof is submitted, the operator generates a zero-knowledge proof that asserts the validity of Citrea’s Light Client Proof, SPV proof the withdrawal operator has front-covered, see section 8 for SPV, and the validity of all longest chain proofs submitted by the watchtowers.
Operators’ proof is considered to be valid if not challenged by any watchtower for a week. If unchallenged, the operator is reimbursed with the 10 BTC they front-covered. Image 2 below illustrates the entire reimbursement process, which involves Collateral Time Transactions.
Optimistically Verifying ZKPs
Validity inheritance from Bitcoin is one of Citrea’s most crucial attributes, ensuring that the system maintains Bitcoin’s security guarantees. However, achieving validity inheritance is particularly challenging because it requires the verification of ZKPs on Bitcoin, a difficult task due to Bitcoin’s block size limitation.
What makes Bitcoin’s programmability limited is actually its limited blocksize. In theory, a ZKP can be verified directly via Bitcoin Script. However, the ZK verifier function requires around 1.2 GB of Script to execute, while Bitcoin blocks are capped at 4 MB.
Clementine addresses this challenge using BitVM2, an upgraded version of BitVM. BitVM2 enables optimistic verification of ZKPs, meaning a proof is assumed valid unless challenged. This approach relies on a 1-of-N trust assumption, where as long as at least one honest actor exists within the set of watchtowers, any invalid proof will be detected, and the rollup will remain secure.
Challengers are entities that can challenge the given ZKP and punish the prover. To give challengers the ability to challenge a ZKP, the ZK verifier is shredded into functions and each function is small enough to fit into a Bitcoin block. Each functions’ output is called an intermediate state and these functions are chained by their inputs and outputs, shown in the Image 3.
Watchtowers challenge the operator's withdrawal claim by providing the longest chain proof and paying 2 BTC directly to the operator as compensation for the assert transaction. In an assert transaction, the Prover reveals the intermediate states, which must be submitted whenever there is a challenge. If the Operator does not submit the assert transaction, it then gets punished with 2 BTC.
The Operator reveals the intermediate states by signing them with the Winternitz One-Time Signature Scheme and submits the signatures to Bitcoin. Later, the challenger provides the Script of the intermediate state that he believes is invalid. If the challenger’s claim is correct, then he’s rewarded.
Winternitz One-Time Signature Scheme
Winternitz is a hash-based signature scheme that is used in BitVM to ensure the authenticity of input(s) and output(s) of each function. The operator signs each function's input(s) and output(s) with the Winternitz One-Time Signature Scheme and commits to both the proof and the intermediate states which are the outputs of functions, namely Z0, Z1 … Zn.
Before signing, the message is split into 8 bit chunks, and a checksum is calculated to ensure that no other signature can be formed from a given signature. The operator generates a random secret key for each chunk and the checksum, which will later be used to sign them. The operator computes the corresponding public keys by hashing each secret key 256 times and distributes it amongst watchtowers.
To sign the message, each chunk is represented as a digit, which is a value between 0 and 255(let that be equal to N), and the secret key is hashed 256 - N times. To verify the signature, the watchtower hashes the data N times more. If the output is equal to the public key, then the signature is valid. A more detailed explanation of Winternitz One-Time Signature Scheme is represented in the Image 4 below.
The prover splits the intermediate states into 8 bit chunks and signs each chunk using the Winternitz Signature Scheme. These signatures are then submitted to Bitcoin. Watchtowers use these signatures to authenticate the intermediate states. If the signatures are valid, the watchtower moves the signed values to an alt stack to re-execute that function.
If the output of the re-executed function does not match the signed value, the proof is invalid. In this case, anyone can disprove the prover with a single transaction by revealing the script of that function and Bitcoin checks whether the challenge is valid or not. If the challenger is correct, prover is slashed, and the challenger receives a reward. An example disproving is shown in the Image 5 below.
Conclusion
Citrea demonstrates that Bitcoin blockspace can be scaled without compromising the network’s core values of security and decentralization. Its trust-minimized, BitVM-based bridge, Clementine, inherits Bitcoin’s validity and provides one of the most secure ways to use BTC in decentralized finance, without altering Bitcoin’s consensus rules.
Clementine’s design continues to evolve, with ongoing improvements to enhance both efficiency and security. This article features the current design which reduces the complexity around the zero-knowledge proof verifier and improves security. The challenge process is reduced to 2 weeks which was 40 weeks in the old Clementine design. The new version also allows extending the signer and watchtower set and introduces multiple operators to compete.
About the Authors
Ekrem Bal is the Co-founder and Chief Scientist at Chainway Labs,1 where he focuses on privacy and zero-knowledge research. He spearheaded the development of Proof of Innocence and is currently leading efforts to build Bitcoin's first trust-minimized bridge using BitVM on Citrea.
Hakan Karakus is a Software Engineer at Chainway Labs and a recent graduate from Bogazici University with a double major in Computer Engineering and Mathematics. He is a ZK enthusiast and loves the mathematical aspects of important protocols. As a part of the BitVM Alliance, he leads the efforts for BitVM development in Chainway Labs.
Yusuf Ozmiş is an undergraduate student at Yıldız Technical University, majoring in Mathematical Engineering. He works as a Researcher at Chainway Labs, where his research primarily focuses on rollups and their applications in emerging technologies.
Chainway Labs is the initial contributor company to Citrea.