# ZeroSync—Zero-Knowledge Proofs in the BTC Ecosystem By [WEB3CN_Global](https://paragraph.com/@web3cn-global) · 2023-08-03 --- **1.Background** ---------------- Zero-Knowledge Proofs (ZKPs) bring a rapid transformation to the scalability and privacy of blockchain. So far, the Ethereum community has widely adopted this technology and made significant progress. According to official data from L2beat, two Ethereum Layer 2 chains, zksync and starknet, both based on zk rollup technology, have a combined Total Value Locked (TVL) of 538 million. Additionally, it is worth noting that the decentralized exchange dYdX, which also utilizes zk-rollup technology from starknet, has a TVL of 338 million. ![](https://storage.googleapis.com/papyrus_images/4aa6f8f86e4ee6ff74f01cb5a84405a195f2135085a0ad415a16a88ba7209340.png) As of now, BTC holds a market dominance of 46.69%, while ETH's market dominance is 18.39%. Surprisingly, despite Bitcoin's prominence, Zero-Knowledge Proofs (ZKPs) are yet to be integrated into its ecosystem. Additionally, data shows that the overall size of the BTC blockchain is 500.16GB, making the computational power required to prove hundreds of GBs of memory extremely costly. Therefore, Starkware's ZeroSync was created to address this market gap and bring ZKPs to Bitcoin. By offering a compact and efficient proof system, ZeroSync aims to expand the BTC ecosystem. With its incredible growth potential in terms of commercial value, market demand, and technical aspects, ZeroSync holds promising prospects. ![](https://storage.googleapis.com/papyrus_images/8b96a14100920179574a0876df55fa40799c489067ecf5b249257705cfa98b18.png) **2.Introduction** ------------------ ZeroSync aims to address scalability, accessibility, and privacy issues in the Bitcoin ecosystem through the use of Zero-Knowledge Proofs (ZKPs). The official team is working on creating a proof system that synchronizes the Bitcoin blockchain state instantly and providing a toolkit for developers in the BTC ecosystem to enhance protocols, applications, and services using ZKPs. Notably, team member Andrew Milson successfully generated the first open-source proof on the StarkNet network using Sandstorm and miniSTARK, contributing to the development of open-source technologies in the blockchain and cryptography field. As is known, setting up a Bitcoin node can be simple, but it requires downloading a significant amount of block data from other nodes in the network, often taking days. However, this time-consuming process is necessary to ensure that a newly launched node holds the correct state of the Bitcoin chain. The computational power required to prove the 500GB memory of the BTC blockchain is also prohibitively expensive. But through compression, a compact and efficient proof can be generated. Once such a proof is created, any number of nodes in the BTC network can use it to instantly synchronize with the network. By leveraging Zero-Knowledge Proofs, anyone can immediately verify the latest state of the chain, and the proof will not be affected by the inherent size of the chain. When the next block is mined, any prover can incrementally extend the proof to the previous state. The significance of this proof system lies in its seamless connection with the immutability of Bitcoin. ZeroSync will serve as a tool to fill the aforementioned gap, providing correct verification of the Bitcoin blockchain. It functions similarly to a full node implementation, not only obtaining the final state after applying all block transactions but also allowing verification of this process at a later time. The ZKP system introduces great flexibility on top of the rigid foundational layer of Bitcoin and opens up a range of new applications for exploration. **3.The State Proof Technology in Three Phases** ------------------------------------------------ ZeroSync is based on STARK proofs, which are relatively simple compared to other proof systems. STARK relies only on hash functions and polynomials and does not require new cryptographic assumptions. Most importantly, there is no need for any trust setup. To achieve the Bitcoin proof, the official team is using Cairo, a language created by StarkWare for building verifiable programs. The technical team can create a program to verify a single block, and the proof is generated only when the verification is successful. The official team is working closely with developers of all STARK tools that support ZeroSync. Implementing chain state proofs is a complex task, so the official ZeroSync team is rolling it out in three consecutive phases. As of now, the team has completed prototypes for the first two phases. ### **1. THE HEADER CHAIN PROOF** **Block Headers:** Each block contains the hash of the previous block and the timestamp, forming a chain-like structure that can be traced back to the first block in chronological order. Similar to Simplified Payment Verification (SPV), the Block Header State Proof verifies only the block headers, proof of work, and difficulty adjustments. Additionally, it enhances the block header chain by building a Merkle tree over all block headers, making the inclusion proofs for all blocks and transactions concise. This state proof is relatively simple, lightweight, and has low computational cost. Currently, the official team has completed the Block Header Proof System, and through the demo on their official website, the block header verification process only takes a few seconds to synchronize the BTC node state. The demo link is as follows: [https://zerosync.org/headers-chain.html](https://zerosync.org/headers-chain.html) ![](https://storage.googleapis.com/papyrus_images/1e63b4fc3fef7fbffb2e5eda81a5f9373a9a957407ba2643d9c9d10993f15138.png) **Block Header Chain Verification Rules:** When a lightweight client receives block header information from the Bitcoin network, it needs to perform a series of checks to validate the block's validity and the correct order of the chain. This process can be simplified into the following four steps: Verify Proof of Work: The lightweight client first checks whether the block's hash is below the current target value, which is related to the block's mining difficulty. If the block's hash is below the target value, it indicates that the block's proof of work is valid. Confirm Chain Order: The lightweight client checks whether the encoded hash of the previous block in the current block matches the actual hash of the previous block. This step is used to confirm the correct order of the blocks in the chain. Check Timestamp: The lightweight client checks whether the block's timestamp falls within a reasonable range. Specifically, the block's timestamp cannot be lower than the median of the timestamps of the previous 11 blocks or exceed the network time plus two hours. Confirm Target Value Accuracy: Finally, the lightweight client checks whether the encoded target value in the block is correct. If there is a variation in the time intervals between blocks, the new target value needs to be adjusted based on the timestamps. The above four steps ensure the validity of blocks and the correct order of the chain in the Bitcoin network while preventing malicious nodes from cheating by modifying the target value. **Verifiable Computation for Block Header Validation:** ZeroSync achieves the verification of block headers by implementing the above rules in Cairo. The official team uses an open-source Cairo prover called "giza" (and contributes to the implementation of recursive proofs) to prove the generated program and its execution trace. Due to the underlying STARK protocol, this protocol ensures that forging a proof of execution is impossible, and the size of a correct proof is only a few hundred to a few thousand bytes, making it feasible for verification on other blockchains, off-chain (e.g., for node synchronization), or even within another STARK proof. To generate proofs for multiple consecutive block headers, the official team batches their verification in a single Cairo program, as long as the underlying prover has sufficient processing power. By verifying several batch verification proofs in a new STARK proof, they can create a proof for the entire Bitcoin chain. ![](https://storage.googleapis.com/papyrus_images/3a2ab3ce7e2d11c86cb86660e6e29410d29bd7213df741e1e104e90435816570.png) **Assumed Valid State Proof:** This step is designed to mimic the "Assume Valid" option in Bitcoin Core. It verifies all Bitcoin consensus rules except for transaction signature validation. More precisely, all witness data is assumed to be valid. Additionally, this proof utilizes Utreexo to enhance the UTXO set commitment on the chain. The team completed the initial prototype of this state proof in February 2023. Assumed valid blocks are an optimization technique aimed at speeding up the synchronization process of Bitcoin full nodes. This technique allows nodes to skip signature verification for certain blocks during the synchronization, saving a significant amount of computational resources and time. In practice, if a new full node knows that a certain block is valid at startup (usually due to default software settings or manual user settings), it can skip signature verification for all blocks before the known valid block while synchronizing. After reaching the known valid block, the node will continue with normal signature verification for subsequent blocks. It's essential to note that assumed valid blocks do not alter Bitcoin's security model or consensus rules; they are merely an optimization. Bitcoin nodes can still function correctly even if users do not set any assumed valid blocks or if the set assumed valid blocks are not on the longest blockchain, though the synchronization speed may be slower in such cases. **Full Node Proof:** Performing a double SHA256 hash on the block header is the most computationally intensive operation in block header validation. Current Bitcoin blocks may contain over 2000 transactions, making full validation of these transactions much more complex than simply validating the block header. Each transaction requires hash computations, and it is not feasible to verify a large number of blocks in a single proof unless we use recursive proofs and keep track of a chain state (mainly composed of the set of unspent transaction outputs after each block), which needs to be updated during the validation process of each block. **Coping with the UTXO Set:** While STARK proofs are concise and make it easier to validate compared to verifying corresponding blocks, the chain state must be part of the public input for each proof, resulting in its size increasing by several gigabytes. Coping with the growth of the UTXO set is a significant concern as an overly large UTXO set can impact node performance and storage requirements. Handling a large UTXO set may lead to nodes needing more storage space and longer synchronization times, affecting the overall efficiency and scalability of the blockchain network. To address this issue, we can employ a technique called accumulators, specifically a technology called UTreeXO, which is a form of Merkle Mountain Ranges for exchangeable tree nodes. With this approach, we can reduce the input and output needed for each validation by only requiring a list containing the UTreeXO root hashes representing the entire UTXO set. If a transaction utilizes a specific UTXO, it can provide a membership proof alongside the proof, which does not need to be included in the public input. This significantly reduces the proof's size, enhancing the efficiency and scalability of the Bitcoin network. **Proof Mechanism:** ![](https://storage.googleapis.com/papyrus_images/6db2656d9963f1e5d39adb490e82b7f174a1d74d0b95f809a2eae10e8efcf9ff.png) Here, the technical team is exploring the use of a technique called Incrementally Verifiable Computation (IVC) to optimize the process of proof generation and verification. IVC can be imagined as a method of breaking down a large task into multiple smaller tasks. In this case, each "task" is the generation of a proof for a block. Typically, for each proof generated, a separate verification is required, which demands significant computational resources and time. Therefore, the team proposes a new approach: first, parallelize the generation of proofs for 10 blocks and then compress these 10 proofs into a single proof. The compression process is akin to creating a tree, where each branch (proof) points to a central point (compressed proof). This way, the verification process only needs to be performed on this single compressed proof, significantly reducing computational complexity and time. Then, this compressed proof can serve as input for the verification of the next block. This approach ensures that the generation and verification of the next proof can begin while the previous proof is still running, thereby increasing efficiency. Finally, to guarantee data consistency, the verification process must check whether all input states match the output states of the previous proof. It is like verifying each step's results to ensure the correctness of the entire process. This mechanism verifies all of Bitcoin's consensus rules, including all witness data. It is the most computationally expensive proof, requiring significant optimization of the prover to make it feasible. The first major application from the team will be broadcasting state proofs via Blockstream Satellite, enabling people from almost anywhere on Earth to synchronize to the Bitcoin blockchain instantly through full node verification. ![](https://storage.googleapis.com/papyrus_images/9b5c461c581ca1a4b7bc10ade6fd24145361443a57a5b0d13acb0a87ee14435e.png) **4.Conclusion** ---------------- In summary, ZeroSync is capable of generating STARK proofs for the Bitcoin blockchain with the goal of creating a single proof for the entire chain. This proof, combined with the corresponding UTXO (Unspent Transaction Output) set, enables rapid synchronization of Bitcoin full nodes. Currently, the Starkware team has reached the stage of "Assume Valid Node," but transaction script validation is yet to be implemented, and the team is actively working on achieving recursive verification. Initial test results show that it can validate a block containing 108 transactions in approximately 5 million Cairo steps. ZeroSync is an open-source project aiming to address scalability, accessibility, and privacy concerns in the Bitcoin ecosystem through the use of zero-knowledge proof technology. Once successful, it is expected to accelerate the prosperity of the BTC ecosystem, as outlined in the following points: * Improve the efficiency and scalability of the Bitcoin network: By utilizing ZeroSync, Bitcoin network nodes can instantly synchronize the latest chain state without the need to download and verify all block data. This significantly improves the synchronization speed of the Bitcoin network, allowing more users and devices to participate, thus enhancing its scalability. * Enhance the security and privacy of the Bitcoin network: ZeroSync leverages ZKP technology to verify the validity of transactions without revealing specific transaction information, thereby greatly enhancing the privacy of the Bitcoin network. Furthermore, due to the non-interactive nature of ZKP, even in the presence of malicious actors between the prover and verifier, the correctness of the proof remains unaffected, thus increasing the security of the Bitcoin network. * Foster the development of the Bitcoin ecosystem: ZeroSync serves not only as a tool to facilitate developers in building and deploying Bitcoin applications but also enhances protocols, applications, and services within the Bitcoin ecosystem, thereby driving its further development. Twitter: [https://twitter.com/Web3cn\_global](https://twitter.com/Web3cn_global) Discord @Web3CN [https://discord.com/invite/CDAkZ8Kc3K](https://discord.com/invite/CDAkZ8Kc3K) Mirror: [https://mirror.xyz/0x8e67fe3E56a3f1834D3a11EF42529EEa14A1EB1F](https://mirror.xyz/0x8e67fe3E56a3f1834D3a11EF42529EEa14A1EB1F) --- *Originally published on [WEB3CN_Global](https://paragraph.com/@web3cn-global/zerosync-zero-knowledge-proofs-in-the-btc-ecosystem)*