# BitVM2-GC with DV-SNARK

## 1. Introduction to BitVM2-GC with DV-SNARK

BitVM [1] first introduced by Robin Linus enables Turing-complete smart contracts on Bitcoin by offloading computations off-chain and verifying results on-chain via Taproot scripts, similar to Optimistic Rollups in Ethereum [2,3]. The initial version required fixed two-party setups (prover-verifier) with inefficient multi-round challenges and high setup costs. BitVM2 [4] later introduced permissionless verification, allowing any user to challenge invalid claims in just two rounds. While it prevented fund theft (malicious actors can only burn deposits), its on-chain transaction costs remained prohibitively high for bridge scalability.

Delbrag [5] (also termed BitVM3s in [6]) dramatically reduces costs using garbled circuits (GC) [7]. During setup, a garbler commits to a SNARK verifier circuit in a Taproot tree and shares it with an evaluator. If the garbler submits an invalid SNARK proof, the evaluator generates a fraud proof using this pre-shared circuit. This approach retains BitVM2's trust model while minimizing its on-chain footprint. It achieves this by embedding gate computations as Taproot leaves, utilizing Bitcoin-compatible hashing (BitHash) for script-based validation in BitVM3s, or by directly verifying the output label for publicly verifiable garbled circuits.

Representing the verification circuit as a Boolean circuit results in an extremely large circuit size, with the number of gates reaching the billions. This massive circuit imposes a significant burden on both off-chain data storage requirements and the computational complexity of proving the correctness of the GC. Although algebraic GC circuits offer a way to reduce circuit scale, current schemes [8] can only support computations over integers and cannot efficiently simulate calculations modulo a large prime. Alpen Labs proposed using designated-verifier SNARK schemes to reduce the size of the GC circuit (i.e., Glock [9]). The DV-SNARK verifier simplifies pairing verification into scalar multiplication on elliptic curves by utilizing a designated verifier. This reduces the verification circuit size by at least two orders of magnitude compared to traditional schemes (such as Groth16). It further employs binary elliptic curves (i.e., Sect233k1) to optimize Boolean circuits. To ensure the correctness of the GC, Glock uses the classic Cut and Choose [10] scheme to filter valid garbled circuits, combines Verifiable Secret Sharing (VSS) to ensure output consistency, and replaces Lamport signatures with adaptor signatures to reduce on-chain data volume.

BitVM2-GC with DV-SNARK proof system integrates the Bitcoin zkRollup GOAT BitVM2 [11] with the efficient garbled circuits of a DV-SNARK verifier to reduce off-chain communication overhead. It combines this with ZK-friendly components: the Poseidon2 [12] hash algorithm and Ziren [13] (a custom zero-knowledge virtual machine optimized for batch-proof generation on MIPS architectures). This architecture merges Bitcoin’s robust security with minimal on-chain footprint while efficiently proving the correctness of the GC and the Structured Reference String (SRS) generated by the prover and designated verifier, respectively.

## 2. BitVM2-GC Protocol with DV-SNARK Verifiers

### 2.1 High-Level Design

BitVM2-GC with DV-SNARK verifier extends GOAT BitVM2’s foundational “assert-disprove” framework through three coordinated phases:

1. Setup:
– The designated verifier (evaluator/challenger) generates the SRS, holds the trapdoor (secret values), and uses a zero-knowledge proof (ZKP) to prove the correctness of the SRS.
– The prover (garbler/operator) verifies the correctness of the SRS, generates a GC based on the DV-SNARK verifier circuit, publishes the GC off-chain, and uses a ZKP to prove its correctness.
– The prover commits input/output labels on-chain, and the verifier commits the trapdoor on-chain.
2. Assertion:
– The prover publishes a SNARK proof and its corresponding input labels (excluding the trapdoor's input labels) on-chain, claiming that its off-chain state transition is valid.
– The verifier discloses the trapdoor on-chain.
– The prover publishes the input labels corresponding to the trapdoor.
3. Disprove: If the SNARK proof or circuit is invalid, the verifier will:
– Evaluates the garbled circuit using published input labels.
– Derives the “0” output label.
– Submits “0” output label on-chain as a fraud proof to falsify the assertion.

To ensure the existence of an honest verifier, based on the 1-of-n assumption, a peg-in setup involves n verifiers. The GC circuits are generated in n copies, and as long as at least one verifier is honest, it can prevent the operator from illegally withdrawing BTC.

### 2.2 Garbled Circuit Construction and Evaluation

BitVM2-GC employs the Poseidon2 hash algorithm H(·) as the cryptographic primitive for GC construction and leverages the free-XOR technique [15] and the secret-free GC approach in [14]. The garbler generates the GC by adhering to the following rules:

- Global Setup: Generates a global offset $r$. For any wire, its labels satisfy $w^0$ (0-label) and $w^1$ (1-label) with $w^1 = w^0 \oplus r$. (For all labels $x$ in the circuit, we always have $w_x^1 = w_x^0 \oplus r$.)
- Input Wire Labels: For each input wire, the Garbler randomly sample the 0-label $w^0$ and derive the 1-label as $w^1 = w^0 \oplus r$.
- Gate Garbling:
– Free-XOR Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = w_a^0 \oplus w_b^0$.
– Free-XNOR Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = w_a^0 \oplus w_b^1$.
– Free-NOT Gate: For input wire $a$, compute output wire labels: $w_o^0 = w_a^1$ .
– AND Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^0, gid)$, and generate the ciphertext $c = H(w_a^1,gid) \oplus w_o^1 \oplus w_b^1$.
– NAND Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^0, gid) \oplus r$, and generate the ciphertext $c = H(w_a^1, gid) \oplus H(w_a^0, gid) \oplus w_b^0$.
– IMP Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^0, gid) \oplus r$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^1$.
– NIMP Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^0,gid)$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^1$.
– CIMP Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^1,gid)\oplus r$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^1$.
– NCIMP Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^1,gid)$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^0$.
– OR Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^1,gid)\oplus r$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^1$.
– NOR Gate: For input wires $a, b$, compute output wire labels: $w_o^0 = H(w_a^1,gid)$, and generate the ciphertext $c = H(w_a^1,gid) \oplus H(w_a^0,gid) \oplus w_b^1$.
– For all output wires $o$, compute its 1- label: $w_o^1 = w_o^0 \oplus r$.

To evaluate a garbled gate with input wire labels $w_a^x, w_b^y$ (where $x,y \in \{0,1\}$ are known, and except for the NOT gate which only requires $w_a^x$), the evaluator proceeds as follows:

- XOR, NXOR Gates: Compute $w_o = w_a^x \oplus w_b^y$.
- NOT Gate: Compute $w_o = w_a^x$.
- AND, NAND, IMP, NIMP Gates (given ciphertext $c$):
– If $x=0$: $w_o = H(w_a^x, gid)$.
– Otherwise: $w_o = H(w_a^x, gid) \oplus c \oplus w_b^y$.
- OR, NOR, CIMP, NCIMP Gates (given ciphertext $c$):
– If $x=1$: $w_o = H(w_a^x, gid)$.
– Otherwise: $w_o = H(w_a^x, gid) \oplus c \oplus w_b^y$.

### 2.3 Parameters Used in BitVM2-GC Construction

The cryptographic parameters for BitVM2-GC with DV-SNARK are configured as follows:

- Label Width: 128 bits (Security against brute-force attacks).
- Poseidon2 Hash Configuration (Adopted for SNARK circuit efficiency, the 32-byte result is truncated to the higher-order 16 bytes):
– Base Field: KoalarBear prime field $\mathcal{F}_p$ with $p = 2^{31} − 2^{24} + 1$.
– Rate: 8.
– Permutation width: 16.
– Round Structure: 8 for external rounds and 13 for internal rounds.
- Efficient Elliptic Curve for Boolean circuits:
– Curve: $E_{k233}/\mathcal{F}_{2^{233}} : y^2 + x\cdot y = x^3 +1$.
– Base Field: $\mathcal{F}_{2^{233}} = \mathcal{F}_2[X]/(X^{233} + X^{74} + 1)$.

## 3. Complexity Analysis

The DV-SNARK verifier circuit based on the Sect233k1 curve comprises approximately 8.8 million non-free gates. The analysis focuses on a single GC circuit (in practice,  $n$ distinct GC circuits are required for $n$ verifiers).

### 3.1 On-chain Complexity
The total inputs are $268$ bytes:
– SNARK Proof: $128$ bytes.
– Public Inputs: $20$ bytes.
– Trapdoor: $3 \times 40=120$ bytes.
We uses Lamport signatures to commit (using $160$-bit hash output) the input bits and the output bit, and takes the 0/1 labels (128 bits each) for each bit as secret keys. The on-chain communication overhead consists of:
- Setup ($\approx 84$ kB): $(268 \times 8 \times 2 + 1) \times 20 \approx 84$ kB for commitments of $268$-byte inputs and $1$-bit output of ‘0’.
- Assert ( $\approx 42$ kB): Reveal one label for each input bit $268 \times 8 \times 20 \approx 42$ kB.
- Disprove ( $\approx 16$ B): Demonstrates the failure of SNARK verification by revealing the circuit’s ‘0’ output label, thereby invalidating the assertion.

### 3.2 Off-chain Complexity

- Communication Complexity
– GC circuit (141 MB): Each non-free gate requires transmitting a 128-bit ciphertext. The total data required for setting up the DV-SNARK verifier circuit is: $8.8 \times 10^6 \text{ gates} \times 16 \text{ bytes/gate } = 140.8 \text{ MB}$.
– SRS ($\approx 863$ MB): totally $4\times 7,189,516=28,758,064$ elliptic curve points and 30 bytes for each points.
- Computation Complexity
– ZKP for GC circuit: Each non-free gate requires 2 hashes (with 160-bit inputs), resulting in a total of $8.8 \times 10^6 \times 2 = 17.6$ million hashing operations to complete the proof.
– ZKP for SRS ($\approx 2^{35}$ multiplication over $\mathcal{F}_{2^{233}}$). Consider the $m \times n$ matrix in R1CS with $m \approx 2^{23} , n=312.$ The computational complexity primarily consists of three parts: 1) Two sets of polynomial evaluations over the Lagrange basis at $\tau$ with a total complexity is $2 \cdot \log^2(m) \cdot m \approx 2^{33}$ multiplications over $\mathcal{F}_{2^{233}}$. 2) Combining wire contributions using $\delta$, requring $n \cdot m \times 3 \approx 2^{33}$ multiplications over $\mathcal{F}_{2^{233}}$. 3）Scalar multiplication on elliptic curves to generate points for polynomial commitment. totaling $4 \times m = 2^{25}$ scalar multiplications over $E_{k233}/\mathcal{F}_{2^{233}}$, equivalent to approximately $2^{34}$ multiplication over $\mathcal{F}_{2^{233}}$. In total, this amounts to  $2^{35}$ multiplication over $\mathcal{F}_{2^{233}}$. We can leverage a large number of hints and adopt schemes such as IPA (inner product argument) or sum-check for generating proofs. These approaches ultimately yield a proof system with linear complexity overhead.

### 3.3 Performance Testing

The primary computations within the process are concentrated in the Setup phase. The Assertion phase only involves a proving for the DV-SNARK circuit, and the Disprove phase only requires evaluating the GC. We illustrate the key computational steps in the flowchart below and summarize the measured execution times (excluding the proof of SRS correctness) in the accompanying table.
The process begins with a DV-SNARK circuit (designed for verifying off-chain computations) and a verifier’s Boolean circuit. First, the designated verifier generates the SRS and must subsequently prove its correctness or ensure its validity via a specific protocol. Then, the prover constructs the GC and must prove the correctness of the GC.

During the Assertion phase, the prover generates a proof and discloses the input labels corresponding to both the proof and the trapdoor (later revealed by the Designated verifier). If the proof is invalid, the designated verifier (or any other challenger) can initiate a Disprove by evaluating the GC circuit.

The measured execution times for these major computational steps are as follows:

| Test Item | Time(s) |
| --- | --- |
| Initial SRS setup | 25,832 |
| SRS setup with precomputation | 174 |
| Proving STARK verifier by DV-SNARK | 333 |
| GC(of DV-SNARK Verifier) generation | 62 |
| GC evaluation | 15 |
| GC proof generation | 217,080|

All tests were conducted on a system powered by a 16-core AMD EPYC 7R13 processor, with the GC proving process accelerated by 8 NVIDIA RTX 4090 GPUs. The total number of Boolean gates is 2.4 billions, with 8.8 millions non-free (AND) gates. The GC is partitioned into 2,412 sub-circuits, each comprising approximately one million gates. Each sub-circuit requires an average of 90 seconds to prove, and all proofs are executed sequentially. However, since each sub-circuit is independent, the entire proving process could be significantly accelerated through parallel execution if sufficient GPU resources are available. Tests were conducted using the repository (Note: The test data was updated as of October 9, with performance optimized by reducing the number of non-free gates in the circuit from 11 millions to 8.8 millions.):
STARK-to-SNARK: [https://github.com/ProjectZKM/Ziren](https://github.com/ProjectZKM/Ziren/tree/feat/sect233k1)
DV-Pari: https://github.com/GOATNetwork/dv-pari
bitvm2-gc: [https://github.com/GOATNetwork/bitvm2-gc](https://github.com/GOATNetwork/bitvm2-gc/tree/dv-snark)

Currently, even with a 8-GPU configuration, the process of proving the GC still takes approximately 2.5 days. This imposes prohibitively high computational costs and time consumption in practical applications. To address this challenge, the GOAT team plans to undertake a comprehensive optimization strategy across multiple layers of the proof system: garbling precompile which uses a dedicated precompiled circuit specifically for garbling operations, high-performance Hash functions such as AES-NI and its precompile and high-efficiency circuit serialization and deserialization methods.

## 4. Alternative Approaches to SRS Verification

The DV-SNARK-based BitVM2-GC scheme reduces the size of the GC by more than two orders of magnitude compared to conventional SNARK-based verification circuits. This also significantly reduces off-chain communication volume—from hundreds of gigabytes down to the gigabyte range.

However, this approach introduces new challenges. First, the use of designated verifiers requires a larger number of such participants and multiple copies of the GC circuits to ensure sufficient security. Second, ensuring the correctness of the SRS—which must be generated individually by each designated verifier rather than using a universal reference string—becomes critical.

When pairing-based elliptic curves are used, the properties of cryptographic pairings can help verify whether the SRS is generated correctly. In contrast, if elliptic curves that do not support secure pairings are adopted (e.g., $E_{k233}/\mathcal{F}_{2^{233}}$ to support smaller logical circuits), designated verifiers must provide a complete proof of SRS generation to guarantee correctness. Ensuring SRS correctness is a vital step in the DV-SNARK-based BitVM2-GC framework—in fact, its complexity substantially exceeds that of verifying the GC circuit itself.

Currently, the approach involves having designated verifiers directly prove the correctness of the SRS using NIZK. This represents the most computationally intensive part of the current scheme. Alternatively, one may consider a random sampling approach to ensure, with high probability, that proofs computed using a verifier’s SRS will pass the DV-SNARK verification circuit.

The idea draws from zero-knowledge proof methodologies. When proving the zero-knowledge property, the prover uses random witness to generate a proof, denoted as $(W,P)$, where $W$ is a value satisfying a random distribution derived from the randomness, and $P$ is obtained via the proving algorithm. To demonstrate the zero-knowledge property, a simulator can use a trapdoor and public inputs (which can also be viewed as randomly distributed) to emulate $(W,P)$. This illustrates the zero-knowledge property—since no “knowledge” is used, the proof $(W,P)$ can be constructed directly using the trapdoor.

Thus, when checking whether a proof $(W,P)$ satisfies the DV-SNARK verifier, the prover can freely choose $W$ (via randomness). By repeatedly testing whether generated proofs $(W_i, P_i)$ pass the DV-SNARK verification circuit, we can gain confidence that a random proof has a sufficiently high probability of being accepted.

This approach should also ensure, with high probability, that the SRS is correct or more precisely, that proofs generated by the prover circuit will pass the DV-SNARK verifier. This method modifies the setup process. Instead of directly proving the correctness of the SRS via NIZK, the designated verifier ensures—through an interactive game—that the prover's proof will pass the verifier circuit with sufficiently high probability. The specific steps are as follows:

– The verifier generates the SRS, commits to the trapdoor (secret values), and transfers the SRS to the prover.

– The prover generates $k$ random proofs using random public inputs and the provided SRS, then sends these proofs and public inputs to the verifier.

– The verifier uses the trapdoor to demonstrate that the received proofs can pass the verifier circuit with ZK proofs.

Still, this would require a very large number of trials to ensure a random proof can pass the verifier circuit with high enough probability (i.e, $1-1/2^{40}$) . To improve efficiency, we can further modify the final DV-SNARK verifier so that it consists of an OR-combination of multiple DV-SNARK verifier results. This ensures that if at least one proof verification passes, the output is “1”, preventing malicious designated verifiers from gaining an advantage. With this structure, using $m$ random checks and $n$ parallel DV-SNARK verification circuits combined via OR gates, the probability that a malicious designated verifier can succeed is reduced to $m^m \cdot n^n/(m+n)^{m+n}$ ( $m = 50, n=10$ leads to a probability about $1/2^{40}$ ).

## Acknowledgements

We extend our sincere gratitude to the Alpen Labs for their foundational work and open-source contributions, which were instrumental to this research. They were the first to propose a method for significantly simplifying GC based BitVM circuits using DV-SNARK, and they generously open-sourced key implementations, including: 1) the dv-pari proving system, and 2) an efficient implementation of the secp233k1 elliptic curve, which is crucial for building ZK-friendly logical circuits. Their pioneering work provided the essential theoretical foundation and practical tools that enabled and inspired this work.

## Reference

1. R. Linus, “BitVM: Compute Anything on Bitcoin,” https://bitvm.org/bitvm.pdf, 2023.
2. J. Poon and V. Buterin, “Plasma: Scalable Autonomous Smart Contracts,” https://plasma.io/plasma-deprecated.
pdf, 2017.
3. V. Buterin, “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform,” https:
[//github.com/ethereum/wiki/wiki/White-Paper](https://github.com/ethereum/wiki/wiki/White-Paper), 2014.
4. R. Linus et al., “BitVM 2: Permissionless Verification on Bitcoin,” https://bitvm.org/bitvm bridge.pdf, 2024,
[Online; accessed 2025].
5. J. Rubin, “Delbrag,” https://rubin.io/public/pdfs/delbrag.pdf, 2025, [Online; accessed 2025].
6. R. Linus, “BitVM 3s – Garbled Circuits for Efficient Computation on Bitcoin,” 2025, https://bitvm.org/bitvm3.pdf.
7. A. C. Yao, “Protocols for Secure Computations,” https://research.cs.wisc.edu/areas/sec/yao1982-ocr.pdf, 1982.
8. D. Heath, “Efficient Arithmetic in Garbled Circuits,” https://eprint.iacr.org/2024/139.pdf, 2024.
9. Liam Eagen, “Glock: Garbled Locks for Bitcoin,” https://cdn.prod.website-files.com/67cfca80708eb505376820af/68a3e174eaff71d197ac4080_glock.pdf, 2025
10. V. Kolesnikov et al., “DUPLO: Unifying Cut-and-Choose for Garbled Circuits,” https://eprint.iacr.org/2017/
344.pdf, 2017.
11. G. N. R. Group, “GOAT BitVM2 Whitepaper,” https://www.goat.network/bitvm2-whitepaper, 2025.
12. L. Grassi et al., “Poseidon2: A Faster Version of the Poseidon Hash Function,” https://eprint.iacr.org/2023/323.
pdf, 2023.
13. L. Fraga et al., “zkMIPS: a high-level specification,” https://www.zkm.io/whitepaper/zkm-new, 2024.
14. V. Kolesnikov and T. Schneider, “Improved Garbled Circuit: Free XOR Gates and Applications,” [https://www](https://www/).
[cs.toronto.edu/∼vlad/papers/XOR](http://cs.toronto.edu/%E2%88%BCvlad/papers/XOR) ICALP08.pdf, 2008.
15. S. Zahur et al., “Two Halves Make a Whole Reducing Data Transfer in Garbled Circuits using Half Gates,”
https://eprint.iacr.org/2014/756.pdf, 2015.