Deep Dive into Citrea's Batch Proofs
Building a ZK rollup on Bitcoin demands a different perspective towards designing a proving architecture due to the limited nature of Bitcoin script. Citrea includes blockspace proving in the circuit to overcome some of these challenges. Therefore, when building a ZK rollup on Bitcoin, computational demands come not only from execution proving but also from Bitcoin blockspace proving. Consequently, Citrea’s proof generation mechanism is customized for Bitcoin and BitVM. We were able to build this custom proving environment fast and effectively with RISC Zero.
Inscribing the zero-knowledge proofs alongside the data that can restore the Citrea’s state on Bitcoin is the only way to inherit Bitcoin’s safety guarantees at the fraction of the cost. In this piece we’ll be exploring Citrea’s proving mechanism that allows for Bitcoin’s safety guarantees.
Where it begins: Execution proving
Execution Proving proves the state root’s change through zero-knowledge proofs. To inherit Bitcoin’s data availability guarantees, Citrea inscribes the state differences to Bitcoin along with the zero-knowledge proofs.
Let’s break down some of the terminologies to fully dive into how things work out.
Citrea’s state consists of the set of all account balances, contract codes and account nonces. Storing it in the most efficient way lies in the Merkle trees.
Merkle trees consist of hashes. Hash functions are functions that take arbitrary length of data and return a fixed length output, called a hash. Citrea utilizes a cryptographic hash function called SHA256 in the state tree for its collision-free property, meaning that no two different inputs should generate the same output, ensuring each account is unique.
A Citrea account is an entity with some cBTC balance that can interact with Citrea. They’re represented as hashes and stored in the leaf nodes of the state tree, pointing to the nonce, balance, storageRoot and codeHash data of that address.
Non-leaf nodes on the state tree are called branches. They store the hash of its leaves and this constant hashing generates the State Root. State Root summarizes the entire state of Citrea with a single hash. Each interaction with Citrea changes its state, hence the root itself. Citrea utilizes batch proofs to prove these interactions’ state changes are done completely and correctly.
Citrea utilizes RISC Zero STARK Prover to generate the batch proof. To generate the proof, Prover takes a large number of Citrea blocks, called a batch, as an input and outputs the state difference resulting from the batch, initial and latest state root.
Instead of inscribing the raw transaction data, Citrea inscribes the difference of state resulting from the transactions in the batch which is called state differences (state diffs in short). Meaning when multiple transactions alter the same account’s nonce, balance, storageRoot or codeHash, only the delta is published, lowering data availability cost.Therefore, collecting a large batch is more rational because the cost of the data is splitted amongst each transaction.
The batch proof alongside the state difference, initial and latest state root, is inscribed to Bitcoin.
However, batch proof production is not instant since each batch contains thousands of transactions. Sequencer commits a hash to Bitcoin to ensure that the ordering of transactions will not be altered while the batch proof is generated. The commitment hash is the Merkle root of the tree that consists of Citrea soft blocks' hashes. This commitment is inscribed in Bitcoin. Since changing the ordering of any transaction will cause a different block hash, hence a different commitment, it can assure that the ordering hasn't changed.
Where it becomes unique: Blockspace Proving
Blockspace proving is one of the key attributes of Citrea, invented by and used from Sovereign SDK. Blockspace proving is necessary for ensuring that forced transactions are completely and correctly included into state transition and generating batch proofs according to the sequencer commitment. Blockspace proving circuit also allows users and the validating bridge, Clementine, to confirm Citrea’s state without the need to set-up a full node by aggregating batch proofs and distributing it.
Forced transactions are transactions that users want to inscribe to Bitcoin. If forced transactions are not included into a Citrea block for a predetermined time period, proof generation, thus rollup itself halts and sequencer gets slashed. This architecture gives Citrea the same level of censorship-resistance as Bitcoin.
To ensure that these attributes work the way intended, blockspace proving circuit scans Bitcoin blocks and extracts certain information such as sequencer commitments, state roots, batch proofs and forced transactions. The prover also checks whether the Citrea transactions are completely and correctly included in the batch by utilizing inclusion and soundness proofs.
In batch proofs, the Prover asserts the validity of the state root. Attesting to the accuracy of batch proofs is sufficient for verifying the validity of state roots. Thanks to blockspace proving, batch proof circuit extracts sequencer commitments from Bitcoin block trustlessly and asserts ordering of the input batch is unaltered.
Conclusion
Citrea fully relies on Bitcoin for batch sequencing and liveness. Citrea’s distinctive proving mechanism is configured to scan every single Bitcoin block, without skipping, and verifies the proofs in the circuit. This architecture is carefully designed to inherit Bitcoin’s censorship resistance, data availability guarantees and validity via BitVM, making Citrea the only scalability solution that is strictly tied to Bitcoin.
Our vision is to make Bitcoin the foundation for the world’s finance!
Join our community to helps us realize our vision.
- Join Discord
- Follow Twitter | X