# 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 can be used to integrate 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 promise the correctness of the GC and the Structured Reference String (SRS) generated by the prover and designated verifier, respectively.

## 2. Garbled Circuits and DV-SNARK
### 2.1 Garbled Circuit Construction and Evaluation

A Garbled Circuit (GC) is a cryptographic protocol, introduced by Yao in 1986, that enables secure two-party computation. It allows two distrustful parties to jointly compute a function on their private inputs without revealing those inputs to each other. The core idea is to encode the function as a Boolean circuit (composed of gates like NAND, AND, XOR, etc). One party, the Garbler, encrypts or "garbles" the truth table of each gate, turning meaningful binary values (0/1) into random-looking labels. The other party, the Evaluator, then obliviously evaluates this encrypted circuit using these labels—through a process like Oblivious Transfer (OT) to obtain the labels corresponding to their own inputs—and learns only the final output without gaining any information about intermediate values or the Garbler's inputs. This approach supports arbitrary functions with a constant round of interaction. While early GCs had high communication costs, key optimizations like free-XOR [14] (making XOR gates virtually free in terms of cost) and point-and-permute (which allows the Evaluator to decrypt only one entry per garbled table) have significantly improved efficiency.

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

- Global Setup: the Garbler 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$.
- 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-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$.
-- 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$.
-- 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 Gate: Compute $w_o = w_a^x \oplus w_b^y$.
- NOT Gate: Compute $w_o = w_a^x$.
- AND Gate (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 Gate (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.2 Designated Verifier SNARKs

DV-SNARK is an optimized variant of SNARKs designed to address the high on-chain costs and computational overhead associated with traditional SNARK verification circuits. It achieves this by replacing expensive cryptographic operations with more efficient alternatives, making it particularly suitable for blockchain applications like Bitcoin L2 solutions where minimizing on-chain footprint is critical.

Traditional SNARKs (e.g., Groth16 [16]) rely on elliptic curve pairings for verification, which require complex operations in large prime fields. These operations must be encoded as binary circuits when integrated with GC, leading to massive circuit sizes (billions of gates) and prohibitive off-chain communicaiton costs.

DV-SNARK adapts techniques from schemes like DV-KZG [17] to substitute pairing operations with elliptic curve scalar multiplications. This reduces the verification circuit size by orders of magnitude.

It uses a designated verifier model, where the verifier holds a secret key, allowing the prover to generate proofs tailored to that specific verifier without revealing critical information.

By eliminating pairings, DV-SNARK can operate on binary elliptic curves (e.g., Sect233k1). These curves are optimized for Boolean circuits, enabling seamless integration with garbled circuit schemes.

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

### 3.1 Motivation and Core Component

GC enable an Evaluator to perform computations on encrypted data (known as labels), with visibility restricted solely to the inputs supplied by the Garbler and the resulting labels of intermediate and final values. This cryptographic primitive facilitates verifiable computation on the Bitcoin network. In the proposed design, the Operator (acting as the Garbler) constructs a GC that represents a ZKP verifier circuit. The Operator commits to a set of all possible input and output labels. During the verification phase, if a proof is invalid, revealing the corresponding labels results in a 0-output label. This specific value can then be used on-chain to Disprove the malicious Operator’s claim and trigger a penalty.

By streamlining the Disprove process, this approach significantly reduces the dispute procedure’s complexity and on-chain cost, making BitVM2 practically feasible.
The integration of a Designated Verifier substantially lowers the complexity of the underlying verification circuit, resulting in a GC that is more efficient to construct and verify.

The integration of GC into the BitVM2 framework primarily involves three phases: Peg-in, Assert, and Disprove. The latter two phases are activated during the Peg-out process when a challenge is presented.The detailed workflow is structured as follows:

Phase 1: Peg-in
- The Designated Verifier generates the SRS while holding the trapdoor (secret values). The Operator uses a combination method of Cut & Choose and random challenge to attest to the correctness of the SRS generation.
- After verifying the correctness of SRS, the Operator generates a GC based on the DV-SNARK verifier circuit, publishes this GC off-chain, and uses a ZKP to prove the GC was constructed correctly.
- The Operator commits to the input and output labels of the GC on-chain. The Verifier commits the trapdoor on-chain.

Phase 2: Assertion after A Challenge
- The Operator has already publishes a SNARK proof, asserting that the off-chain state transition is valid. Once challenged, the Operator reveals the corresponding input labels excluding those related to the Verifier's trapdoor on-chain.
- The Designated Verifier responds by disclosing the trapdoor on-chain.
- The Operator then publishes the input labels corresponding to the revealed trapdoor.

Phase 3: Disprove
- If the SNARK proof or the circuit execution is invalid, any Challenger will:
-- Evaluate the garbled circuit using all the published input labels.
-- Derive the specific output label representing a logical '0' (indicating failure).
-- Submit this '0'-output label on-chain as a fraud proof to invalidate the Operator's Kick-off.

To ensure security, the protocol requires at least one honest Designated Verifier. During the Peg-in setup, $n$ (i.e., 10) verifiers are selected, and the GC circuits are produced in nindependent copies. The system guarantees that if at least one of the verifiers is honest and performs correctly, it can prevent a malicious Operator from successfully executing an illegal BTC withdrawal.

### 3.2 SRS Verification

The DV-SNARK-based BitVM2-GC scheme reduces GC size and off-chain communication from hundreds to just a few gigabytes compared to traditional SNARKs, but poses new challenges for verifying the correctness of the SRS.

***SRS Correctness Burden.*** Each Designated Verifier must generate an individual SRS (no universal reference string exists), requiring rigorous validation. When using non-pairing-friendly elliptic curves (e.g., Sect233k1 for binary circuit efficiency), verifying SRS correctness becomes computationally intensive---often exceeding the cost of GC verification itself when using methods like non-interactive zero-knowledge (NIZK) proofs.

***Combining Cut \& Choose and Randomized Challenge Solution.*** Instead of direct SRS verification, our protocol employs a probabilistic game to ensure SRS reliability using parameters $(n, m, k)$:

- Cut-and-Choose Procedure:
-- The Designated Verifier generates $n$ SRS instances and commits to each (e.g., via short digests of the SRS and associated trapdoor).
-- The Prover randomly selects $n-m$ instances and requests the Verifier to reveal the corresponding trapdoors.
-- The Prover recomputes the SRS using the revealed trapdoors and verifies consistency with the commitments. If inconsistencies are detected, the protocol terminates.
- Random Challenge Procedure (applied to the remaining $m$ SRS instances):
-- The Verifier sends the full SRS data for the $m$ instances to the Prover.
-- The Prover generates $k$ random proofs (using random public inputs) for each SRS and sends them to the Verifier.
-- The Verifier uses a NIZK proof to demonstrate that these proofs pass the verification circuit associated with the committed trapdoor.

- On-Chain Deployment: The $m$ GC circuits corresponding to the $m$ trapdoors are deployed on-chain. Verification results are combined using an 'OR' logic, allowing the Prover to withdraw funds if at least one GC circuit validates successfully.

With parameters $n=20$, $m=2$, and $k=10$, the probability of an honest Porver fails to pass the DV-SNARK verification circuit in face of a malicious Verifier is bounded by:

$$\frac{2}{n(n-1)} \cdot (1-\alpha)^n \alpha^2 \leq \frac{1}{190} \cdot \left(\frac{10}{11}\right)^{20} \cdot \left(\frac{1}{11}\right)^2 \approx 6.5 \times 10^{-6}.$$

***Alternative Methods for SRS Correctness Promise.*** As an alternative, the BN254 curve—a pairing-friendly elliptic curve—can be employed to construct the DV-SNARK circuit. Using BN254, the correctness of the SRS can be ensured through a straightforward pairing consistency check [18]. However, this approach significantly increases the scale of the verifier circuit, which expands to approximately 2 billion gates, including 506 million non-free gates. While guaranteeing SRS correctness with BN254 is relatively direct, the process of proving the correctness of the GC requires about 3–4 times longer compared to using the Sect233k1 curve. For detailed performance benchmarks on GC correctness under Sect233k1, refer to Section 4.3.

### 3.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)$.
- Pairing-friendly Curve BN254 for Efficient SRS Verification:
– Curve: $y^2 =x^3 + 3$ over prime field $\mathbb{F}_p$ with a $254$-bit prime $p$.

## 4. 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).

### 4.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.

### 4.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.

### 4.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 |2,800 |

All tests were conducted on a system powered by a 16-core AMD EPYC 7R13 processor, with the GC proving process accerated 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 transformed into about 66 billion cycles and partitioned into 200 sub-circuits, each comprising approximately 330 million cycles. Each sub-circuit requires an average of 14 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:
STARK-to-SNARK: [https://github.com/ProjectZKM/Ziren](https://github.com/ProjectZKM/Ziren)
DV-Pari: https://github.com/GOATNetwork/dv-pari
bitvm2-gc: [https://github.com/GOATNetwork/bitvm2-gc](https://github.com/GOATNetwork/bitvm2-gc)

With an 8-GPU configuration, the proof for GC generation of the DV-SNARK verification circuit completes in under an hour, demonstrating its practical feasibility. The use of the BN254 curve enables efficient SRS validity checks, but at the expense of a significant increase in GC proof generation time, notably by a factor of 3 to 4.

## 5. Conclusion

GC is a cryptographic protocol that enables two-party secure computation, allowing mutually distrusting parties to jointly evaluate a function using their private inputs without relying on a trusted third party. In this protocol, all input and output values are encrypted and stored in a garbled table. Once the garbler reveals the input keys, the output can be decrypted deterministically.

In BitVM2, when an optimistic withdrawal is challenged, the Operator is required to reveal execution traces, and the Challenger must publish a fraud proof. Both steps incur high on-chain costs because expressing execution traces and fraud proofs in Tapscript consumes substantial block space.

BitVM2-GC leverages the GC protocol to reduce the on-chain fraud proof data size by approximately three orders of magnitude. Our work presents a variant of DV-SNARK design, achieving the smallest on-chain fraud proof size among existing approaches and an excellent balance in off-chain complexity.

<!--
BitVM2-GC represents a significant advancement in realizing practical zkRollups on Bitcoin by systematically addressing the core limitations of the original BitVM2 protocol and establishes a new paradigm for Bitcoin L2 solutions that balances security, efficiency, and practical deployability.

The integration of GCs with DV-SNARK verification achieves a fundamental breakthrough in on-chain efficiency. By reducing the verification circuit size by two orders of magnitude and optimizing the dispute resolution mechanism, we minimize both the computational overhead and on-chain footprint while maintaining the security guarantees of the underlying cryptographic primitives. The carefully designed three-phase workflow (Peg-in, Assert, Disprove) ensures that the system remains practical for real-world deployment.
-->

## 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.
16. J. Groth. “On the size of pairing-based non-interactive arguments”. In Advances in Cryptology - EUROCRYPT https://eprint.iacr.org/2016/260.pdf, 2016.
17. Michele Orr‘u. “Revisiting keyed-verification anonymous credentials.” https://eprint.iacr.org/2024/1552.pdf, 2024.
18. Sean Bowe et al. “A multi-party protocol for constructing the public parameters of the pinocchio zk-snark.” https://eprint.iacr.org/2017/602.pdf, 2017.