Introduction Groth16 | zkDatabase Architecture
February 26, 2026
6 mins read
Why zkDatabase chose Groth16, 0.4s proving, 200-byte proofs, 100K gas verification. Technical deep dive into Merkle circuits and benchmarks.
In the pursuit of building zkDatabase, a high-performance, verifiable database, the choice of a Zero-Knowledge Proof (ZKP) system is the most critical architectural decision. After evaluating various proof systems including Kimchi (Mina’s stack), PLONK, and STARKs, Orochi Network has standardized on Groth16.
This article deep dives into the technical constraints, the arithmetic of Merkle Membership circuits, and the benchmarking data that proves Groth16’s dominance in on-chain verification and proof succinctness.
Technical Rationale - The Efficiency Frontier
For zkDatabase, ZKPs are not merely a privacy feature but a verifiable computation primitive. Our core requirement is proving that a query result matches a committed Merkle Root.
The Constant-Size Argument
Groth16 is a pairing-based zk-SNARK that produces the most succinct proofs in the cryptographic landscape. Regardless of the circuit complexity (number of constraints $n$), a Groth16 proof always consists of exactly 3 group elements:
-
Proof Size: ~128 to 200 bytes.
-
Significance: Proof Size: ~128 to 200 bytes. This minimizes on-chain costs, particularly "Data Availability" (DA) costs, the expense of publishing and storing proof data on the blockchain so that anyone can verify it.
-
Since Groth16 proofs are extremely compact (~128-200 bytes), the cost to post them on-chain remains negligible. In contrast, while STARKs scale logarithmically and don't require a trusted setup, their proofs can reach 40-100KB, making them significantly more expensive for frequent database state updates where DA costs would accumulate rapidly.
-
Verification via Pairing Equations The verification of a Groth16 proof involves a single pairing equation check: e(A,B)=e(α,β)⋅e(S,γ)⋅e(C,δ)
-
Verification Cost: This requires only 3 pairing operations and t scalar multiplications in G1, where t is the number of public inputs. Since pairing operations dominate the gas cost, with bn254 pairing precompiles on the EVM consuming approximately 34,000 gas each, the cost of t scalar multiplications in G1 is negligible by comparison (roughly 6,000 gas per operation).
This makes Groth16 the most economical choice for smart contract verifiers, with total verification costs typically ranging from ~100,000 to 150,000 gas depending on the number of public inputs.
Architecture: Merkle Membership Circuit
The primary workload of zkDatabase is generating Zero-Knowledge Proofs that attest to the correctness of Merkle inclusion proofs. Rather than directly exposing Merkle inclusion proofs (which reveal the Merkle witness path), zkDatabase wraps them inside a zkSNARK. This approach serves two key purposes:
-
Zero-Knowledge Property: The verifier learns only that a specific value exists in the Merkle tree, without gaining access to sensitive information such as the Merkle witness path, sibling nodes, or the value's position in the tree.
-
Succinct Verification: While zkSNARKs provide constant-time verification regardless of tree depth, the primary advantage here is privacy preservation rather than performance gains, verification of a bare Merkle proof is already efficient. In essence, if the Zero-Knowledge Proof verifies successfully, it cryptographically guarantees that the claimed value is indeed a member of the Merkle tree, while revealing nothing beyond this membership fact.
Circuit Logic
To utilize general-purpose zkSNARKs, we must first express the problem as an arithmetic circuit. Below is the circuit logic for verifying a Merkle inclusion proof.
Private Inputs (Witness):
- The Merkle path (sibling nodes from leaf to root)
- The leaf value to be proven
- The path indices (left/right indicators at each level)
Why Groth16 fits this Circuit?
Merkle Tree circuits are relatively small and have a fixed structure per collection. Each collection in zkDatabase has a predetermined tree height that remains constant throughout its lifetime. This makes Groth16's requirement for a per-circuit Trusted Setup not only manageable but actually advantageous, the circuit structure is fixed at collection creation time and never changes.
Since the tree height and circuit topology are locked in for each collection, the one-time MPC ceremony becomes a negligible setup cost compared to the ongoing performance benefits: compact proofs (~200 bytes), minimal verification gas costs (~100-150K), and fast proof generation. The fixed-circuit nature of database collections is precisely the use case where Groth16's trusted setup trade-off makes the most sense.
Benchmarking & Comparative Analysis
We conducted stress tests comparing the circom + rapid snark (Groth16) stack against modern alternatives. The focus was on Merkle Height 128, a standard for large-scale databases.
Proof Generation Latency
PLONK (Barretenberg): +19.4s overhead
- Witness generation overhead: Barretenberg requires compiling the circuit to a specific intermediate representation and generating the full execution trace before proving
- Setup and initialization: Loading proving keys, initializing polynomial commitment schemes
- Multi-phase proving: PLONK's proving process involves multiple rounds of polynomial evaluations and commitments
The overhead is particularly high because Barretenberg is designed for general-purpose circuits (like Aztec's zkVM), not optimized for simple Merkle circuits.
Why this matter for RWA Tokenization and Stablecoin Infrastructure ?
When proving time drops, proof generation becomes operationally feasible at higher frequency. And for tokenized funds (espcially for NAV workflow), NAV calculation can be proven more often without creating computational bottelenecks, lower latency proofs reduce verification overhead that lowers operational cost. So, at a result NAV updates can move from daily batches toward near real time attestation, enabling continuous transparency rather than delayed reporting.
In RWA Tokenization, where trust depends on valuation integrity, and faster Groth16 proving directly supports scalable, audit grade transparency.
For stablecoin issuers, Groth16’s compact proof size is equally critical. Its small verification footprint makes on-chain verification cheap on EVM-compatible chains.
This reduces gas costs for Proof-of-Reserve commitments and historical balance attestations. When both proving time and verification cost are low, daily or even intraday reserve anchoring becomes economically sustainable. Instead of quarterly audits or opaque attestations, issuers can anchor cryptographic reserve proofs on-chain with predictable costs.
Conclusion
Groth16 provides the most "battle-tested" and efficient framework for current zkDatabase requirements. It outperforms the previous Kimchi-based system by a factor of 50x in proving speed (from ~22s down to <0.5s). While Groth16 is our current choice, our research team is investigating Proof Aggregation and Recursive SNARKs to bundle thousands of database queries into a single verification, ensuring zkDatabase remains the fastest verifiable data layer in Web3.
In parallel, we are expanding into stablecoin infrastructure, payments, and transaction systems, enabling continuous Proof-of-Reserve, real-time transaction integrity, and audit-grade financial reporting.
FAQs
Why does Orochi Network use Groth16 for zkDatabase?
Orochi Network uses Groth16 because it offers constant-size proofs and the lowest on-chain verification cost, which is critical for frequent database queries and state updates. This makes Groth16 the most efficient ZKP system for a high-throughput, verifiable database like zkDatabase.
What makes Groth16 suitable for a verifiable database like zkDatabase?
Groth16 is ideal for zkDatabase because its proof size remains constant regardless of circuit complexity. Since zkDatabase primarily proves Merkle membership and query correctness, Groth16 minimizes gas costs while maintaining strong cryptographic guarantees.
How does zkDatabase reduce proving latency with Groth16?
zkDatabase integrates native C++ witness generation and an optimized prover stack, reducing witness computation time from over 200 ms to under 50 ms. Combined with Groth16 and optimized provers, this enables sub-second end-to-end proof generation.
Related to
