Abstract

This article delves into the practical methods for enabling ZK verification in Bitcoin, covering topics like Bitcoin’s UTXO model, scripting limitations, Taproot, OP_CAT, BitVM, and Chain State Proofs. It presents a clear argument that integrating ZK into the Bitcoin protocol is inevitable. Two potential routes are highlighted: one is reintroducing the OP_CAT opcode to directly support SNARK verification in Bitcoin scripts—a change that has a high likelihood of eventual approval. The second approach revolves around BitVM, which incorporates fraud proofs. Additionally, the ZeroSync team’s proposal for Chain State Proofs aims to reduce the cost of verifying historical data for node clients.

Main Text: To fully grasp Bitcoin, it’s helpful to view it as a social system. In its early days, Bitcoin’s creators defined the software that nodes must run, much like establishing the rules that govern a society. Bitcoin’s stability depends on a broad consensus about its fundamental nature, leading to questions like “What is Bitcoin at its core?” and “What should Bitcoin evolve into?” However, reaching consensus on these questions is notoriously difficult, as opinions vary widely and continually evolve.

This goes back to the historical origin of Bitcoin. When Satoshi Nakamoto released the Bitcoin white paper, he said: “I am working on a brand new electronic payment system. This system is completely P2P and does not need to rely on any third party.” This passage was published on the Cypherpunks mailing list (an email discussion group established in 1992, composed of a group of cryptographers and technology enthusiasts who are concerned about privacy protection and cryptography technology).

However, Bitcoin limits data throughput at the product design level. The number of transactions it can process per unit time is limited. If the number of transactions to be processed increases rapidly, users will initiate a price war in order to successfully complete the transaction quickly, quickly increasing the handling fees paid. The single transaction with the highest handling fee in the Bitcoin network occurred after the block reward was halved in 2024, and the handling fee for a transaction with a medium priority on the chain reached $150. It can be said that the expensive transaction fees of the Bitcoin network have become a problem.

In order to solve the problem of transaction fees, people have invested a lot of resources into the development of Lightning Network. But according to a paper published in 2016, the Lightning Network can only support tens of millions of users in practice and cannot realize its vision of a global payment system. In addition to the excessively expensive transaction fees, there is another problem, that isBitcoin has never been able to achieve the anonymity it envisioned.

Satoshi Nakamoto pointed out in a cypherpunk email discussion group that Bitcoin has a privacy protection function and the transaction initiator can be completely anonymous. However, although the transaction initiator does not require KYC, the transaction data on the Bitcoin chain leaks a lot of information, exposing user privacy to a large extent. Although there are some wallet clients with privacy functions that solve the above problems to a certain extent, the developers of these wallet clients face threats of various sizes. For example, the developer of the Samourai CoinJoin wallet was arrested by the FBI in April 2024, and a week later, the developer of the Wasabi wallet shut down their CoinJoin coordination component. Obviously, these so-called privacy wallets are not entirely worthy of users’ trust.

To sum up, many of the concepts of Bitcoin are far from being realized until today, and related technologies are still under continuous development. Even so, many people in the Bitcoin community believe that Bitcoin’s protocol design should remain unchanged, but there are also many people, like me, who are passionate about making improvements to Bitcoin. So, in what direction should Bitcoin improve?

In response to the above issues,There are many proposals in the Bitcoin community, and the ones with the best theoretical results should be related to ZK and SNARKs. With ZK and SNARKs, the following features can be achieved:

1. Significantly-improved privacy: use homomorphic Peterson commitment to transaction amount and Range Proof to significantly improve user privacy (such as done in Blockstream’s Element side chain); use linkable signatures (such as Monero ) to hide transaction traces; achieve truly private transactions (such as Zcash).

2. Improve transaction throughput

Many technical solutions could address Bitcoin’s existing issues, but why haven’t these technologies been integrated into the Bitcoin protocol? The answer lies in the difficulty of modifying the protocol. Unlike Ethereum, Bitcoin doesn’t have a centralized organization like the Ethereum Foundation. Any protocol change requires a high level of community consensus, involving extensive negotiation and balancing of interests. As a result, while Ethereum regularly updates its EVM opcodes, Bitcoin’s protocol has seen very few changes since its inception.

In some ways, this difficulty in modifying the protocol is beneficial. If changes were easy to implement, malicious alterations or attacks would be more likely. This raises the question: How can Bitcoin’s performance be improved without altering the protocol?

To answer this, we need to revisit some basics of Bitcoin. When you transfer Bitcoin to someone else, you create a transaction and broadcast it to the Bitcoin network. The transaction’s output data specifies the amount of BTC being transferred. The recipient can then create a new transaction to spend the received BTC, generating new output data in the process.

It’s important to note that Bitcoin doesn’t have a global state like Ethereum, particularly lacking an account state; it only has transaction output data. Each transaction output has two states: either it has been spent by the recipient or remains unspent. Unspent transaction outputs (UTXOs) are what we’re familiar with. Besides the associated BTC amount, each transaction output also has an attached script written in Bitcoin Script. Whoever can provide the correct proof (Witness) to this script can spend the UTXO.

Bitcoin Script is a stack-based programming language with a series of opcodes. The programs attached to UTXOs often consist of multiple opcodes, performing computations based on the stack and returning results to it. Many common Bitcoin scripts have existed since Bitcoin’s inception. For instance, the most common script consists of a public key and an opcode that checks the digital signature. This opcode requires that to spend or unlock a UTXO, one must provide a digital signature corresponding to the public key.

Recommended Reading: [Approaching BTC: Background Knowledge for Understanding BitVM (1)]

Capabilities of Bitcoin Script

What Bitcoin Script Can Do:

• Rearrange the stack and perform equality checks (to verify specific conditions and ensure transaction security and validity).
• Perform conditional operations similar to if-else statements.
• Perform limited arithmetic operations on 32-bit numbers, such as addition and subtraction.
• Hash data and verify ECDSA and Schnorr signatures.

What Bitcoin Script Cannot Do:

• No loops, jumps, or recursion; it is not Turing-complete, with very limited programming capabilities.
• Cannot perform bitwise operations.
• Lacks opcodes for multiplication and division.
• Cannot concatenate elements on the stack.
• Has very limited ability to read and verify on-chain transaction data. Bitcoin Script cannot directly access the amount of each transaction and cannot pass state (UTXOs are single-use, and each transfer burns the old and generates new ones).

In early versions of Bitcoin, some of the “cannot-do” functionalities mentioned above were possible, but certain opcodes were later disabled by Satoshi Nakamoto due to security vulnerabilities. For example, the OP_CAT opcode, which could combine two stack elements, was used to remotely attack Bitcoin nodes and cause crashes. Satoshi disabled OP_CAT and other opcodes for security reasons.

So, can Bitcoin Script verify SNARKs? Theoretically, even though Bitcoin Script is not Turing-complete, its basic operations are sufficient to verify any computation. However, in practice, SNARK verification is not feasible because the program size required for the verification steps exceeds Bitcoin’s maximum block limit of 4MB. While we could attempt arithmetic operations in large finite fields, the cost would be prohibitively high. For example, in BitVM, multiplying two 254-bit integers resulted in a Bitcoin script size of nearly 8KB. Moreover, without OP_CAT, the cost of verifying Merkle proofs is also high, as this requires operations similar to loops.

So, why not just modify the Bitcoin protocol to add more powerful opcodes? As previously mentioned, achieving a majority consensus on new protocol rules is extremely difficult. Bitcoin lacks a centralized decision-maker, and any proposal to improve Bitcoin Script faces considerable opposition from stakeholders with different perspectives. There is no effective way to gauge community consensus in the Bitcoin network, and forcing an update without it could lead to chain splits. Of course, Bitcoin is not entirely immutable. The most recent updates were SegWit in 2017 and Taproot in 2021.

The Taproot upgrade, which altered many rules, took three and a half years to move from theoretical release to actual activation. The key factor in enabling Taproot was that it did not alter existing security assumptions and made clear improvements to the Bitcoin protocol. For example, it allows the use of Schnorr signatures instead of ECDSA. Both are based on the discrete logarithm assumption and use the same elliptic curve, but the former is more efficient and requires less computation.

Moreover, Taproot’s improvements to Bitcoin can be categorized into the following three aspects:

First, Taproot reduces the verification costs of scripts with many conditional branches, enabling Bitcoin to support more complex programs.

Second, Taproot reduces the amount of script data to be revealed on the chain, and you can assemble multiple script programs into a Merkle tree, with each script located on a different leaf. If you want to trigger a certain script, you only need to reveal the leaf where it is located and the Merkle proof;

Third, Taproot also added other mechanism designs.

Considering Bitcoin’s precedent with Taproot for integrating more advanced features, one might wonder why a dedicated opcode for SNARK verification hasn’t been introduced. The key difference lies in the complexity and consensus required for OP_SNARK. Unlike Taproot, which had a clear, straightforward design that gained broad support, OP_SNARK proposals vary widely, making it hard to rally the community around a single approach. If implemented, every Bitcoin node would need to support this specific SNARK verification method, which would significantly increase the technical demands. Moreover, OP_SNARK’s inherent complexity is a major hurdle—Taproot added around 1,600 lines of code, manageable by community standards, whereas OP_SNARK would entail much more intricate coding. Furthermore, determining who would assess the activation of OP_SNARK and achieving consensus when few fully grasp its intricacies adds layers of difficulty. Given these challenges, an OP_SNARK upgrade is unlikely to materialize in the near future.

However, there are other ways to verify SNARKs in Bitcoin Script. We can make Bitcoin scripts more functional by adding simpler opcodes, allowing people to implement SNARK validator programs in scripts. But in fact, it is very difficult to write a SNARK verification program in Bitcoin script language.Therefore, the Blockstream research team is developing Simplicity, a programming language designed to replace Bitcoin Script. Simplicity is specifically designed for blockchain consensus systems and is intentionally not Turing-complete, making it easy for static analysis and formal verification.

Let’s turn our attention to a seemingly simple but highly impactful proposal that could significantly enhance Bitcoin’s scripting capabilities: the reactivation of the OP_CAT opcode. OP_CAT was originally included in Bitcoin’s early code but was later disabled by Satoshi Nakamoto due to its potential to enable DoS attacks under specific conditions. However, there is now growing interest within the Bitcoin community to bring it back.

The function of OP_CAT is straightforward—it takes the top two elements from the stack, concatenates them, and then pushes the result back onto the stack. While this may appear basic, it has the potential to unlock substantial improvements in Bitcoin’s scripting language. For example, current Bitcoin scripts are unable to access certain on-chain transaction data, such as the amounts involved, but with OP_CAT, this capability could be introduced. Additionally, OP_CAT could be instrumental in verifying Merkle proofs.

In essence, OP_CAT is a low-level opcode upgrade that could lead to a wide range of new functionalities. Many have pointed out that OP_CAT could be crucial in achieving various objectives. A key question is whether OP_CAT could assist in SNARK verification within scripts. The answer is yes. Since Merkle proof verification is a step toward validating FRI-based SNARKs, OP_CAT would be a valuable addition. In the past, scripts designed for SNARK verification might have been too large to fit within Bitcoin’s block size limits, but OP_CAT could help streamline these scripts, making them more compact.

OP_CAT has been discussed for years, with increasing awareness of its potential role in transaction introspection. One of its major advantages over other proposals is that it was once an integral part of Bitcoin Script, which could make it easier to achieve community consensus. However, the downside is that enabling OP_CAT could negatively impact MEV (Miner Extractable Value) profits for some, which has led to ongoing debate within the community about its reactivation.

In summary, Bitcoin could take a step toward enabling SNARK verification in scripts by reintroducing straightforward opcodes like OP_CAT. Additionally, it’s worth mentioning a recent proposal called the “Great Script Restoration,” which reintroduces a multiplication opcode and enables all arithmetic operations to be performed with arbitrary precision.

Additionally, when evaluating the impact of OP_CAT on the Bitcoin network, it’s important to consider its effects on Bitcoin node operators. To ensure Bitcoin remains censorship-resistant and decentralized, the community strives to have as many people as possible running nodes to validate transactions. If Bitcoin were to implement SNARK verification, it would not significantly raise the cost of operating a node, which would not greatly affect Bitcoin’s security or censorship resistance.

Currently, a Bitcoin block can hold up to 4MB of data, with new blocks being mined roughly every 10 minutes. Most blocks are filled with Bitcoin scripts and Witness data (similar to digital signatures). On average, each block can accommodate between 7,000 and 10,000 signature verifications, with a maximum of around 80,000 verifications per block. For context, my 2020 Intel CPU takes about 3.2 seconds to verify a Bitcoin block. Naturally, block verification speed is influenced by factors beyond just the time for signature verification.

Furthermore, if Bitcoin transactions eventually support zero-knowledge (ZK) proofs, any increase in transaction generation time might not be a major concern. Hardware wallets, which are used for long-term asset storage, typically have screens and compact designs focused on key storage and signature creation. These wallets usually feature relatively low-power CPUs, like a 240MHz dual-core processor, but they handle Bitcoin transactions efficiently.

I did a small survey asking users about the maximum delay they would accept for a signing device to generate a proof, and many people were okay with a longer wait, especially if there were significant gains to be made. So if we introduce ZK into Bitcoin transactions, there doesn’t seem to be much trouble.We’ve spent a lot of time discussing potential changes to Bitcoin’s underlying design, but there are many applications that can be developed without altering Bitcoin itself. One such application worth mentioning is Chain State Proofs, which is related to BitVM. This approach uses zero-knowledge proofs to validate the correctness of block hashes.

What impact does this technology have on Bitcoin? Firstly, Chain State Proofs can greatly reduce the workload involved in syncing and verifying Bitcoin’s historical data, which in turn lowers the costs of running a node. Currently, syncing and verifying data from the genesis block to the latest block takes about 5 hours and 30 minutes on a high-end device, and several days on a Raspberry Pi-level device. Chain State Proofs could significantly shorten this process.

Secondly, Chain State Proofs play a crucial role in advancing BitVM. The ZeroSync team has thoroughly researched Chain State Proofs and developed a streamlined version called “header chain Proofs.” This approach uses zero-knowledge proofs to validate Bitcoin block headers, creating a “header chain” that encompasses all 850,000 block headers in Bitcoin’s history. Each block header is hashed to produce an 80-byte proof. This method requires double SHA-256 calculations for each header to verify the associated proof of work. ZeroSync utilizes STARKs to generate these header chain proofs, costing around $4,000 to produce, while verification takes only about 3 seconds in my browser.

However, since header chain proofs don’t verify the transactions within the blocks, they can only assume that the blockchain with the most proof-of-work (PoW) is valid and rely on Bitcoin clients to sync the latest blocks from this chain. In this setup, an attacker could theoretically create blocks with invalid transactions, add more blocks after them, and generate a header chain proof to mislead clients syncing historical data. However, the cost of such an attack would be prohibitively high, and it would likely be detected by existing Bitcoin full node clients.

However, even though the chances of such an attack succeeding are low, if it could allow attackers to steal a significant amount of BTC, header chain proofs would not be considered a completely secure solution. To verify the full state of the chain, we need to ensure that all Bitcoin block contents are valid, including ECDSA and Schnorr signature verifications based on the secp256k1 elliptic curve. Bitcoin’s historical blocks contain approximately 30 million signatures each month, totaling around 2.5 billion signatures historically, along with numerous SHA-256 computations. As a result, the Bitcoin network generates about 7GB of block data monthly, with historical data surpassing 650GB—and in practice, this figure might be 2 to 3 times higher.

Now, let’s look at BitVM. BitVM allows Bitcoin to verify any computational task, providing an optimal way to perform SNARK verification without modifying the protocol. BitVM overcomes Bitcoin’s script size limitations using two methods. First, it leverages the Taproot MerkleTree script structure. Second, it uses a KV storage scheme that can be accessed across individual scripts, facilitating connections to a large number of script programs. However, the Bitcoin protocol does not enforce the integrity of this KV storage scheme. BitVM addresses this by employing fraud proofs to detect malicious Provers. If a Prover makes invalid claims or uses faulty KV storage, others can initiate a transaction on the Bitcoin blockchain to report the Prover’s misconduct and seize the Prover’s staked assets.

In summary, Bitcoin is grappling with significant challenges, and while various proposals have been put forward to address these, gaining rapid acceptance from the Bitcoin community is unlikely. Protocol changes are not achievable in the short term, reflecting both the strengths and constraints of Bitcoin’s decentralization and security. The potential of SNARKs and STARKs is generating considerable excitement within the community. BitVM appears to be the most promising method for integrating SNARK verification in the medium to long term, though it requires further research and development to be fully practical. Re-enabling the OP_CAT opcode is another avenue to explore, but it needs to demonstrate that the benefits of reactivation outweigh the risks, and identify which simple opcodes could facilitate SNARK verification or similar functions in Bitcoin scripts. Ultimately, the Bitcoin community aims to enhance the technology’s practicality and support more actionable use cases.

Read the original content here: https://www.youtube.com/watch?v=GrSCZmFuy7U

Disclaimer：

1. This article is reprinted from [Geek Web3], All copyrights belong to the original author [Geek Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.