How to Evaluate Proof Sizes for Onchain Use

In blockchain systems, a zero-knowledge proof (ZKP) is a cryptographic method that allows one party (the prover) to convince another (the verifier) that a statement is true without revealing any underlying information. The output of this process is a proof. For onchain applications—where the proof is submitted and verified directly on a blockchain—the size of this proof data is a primary constraint. It directly impacts transaction fees, block space utilization, and the practical scalability of protocols like zkRollups, privacy-preserving DeFi, and verifiable computation. A smaller proof reduces gas costs and network congestion, making applications more viable for end-users.

Evaluating proof size requires analyzing the proving system and the circuit being proven. Common systems include Groth16, PLONK, and STARKs, each with different trade-offs. For instance, a Groth16 proof for a simple Merkle tree inclusion might be only 192 bytes, while a STARK proof for a complex computation could be hundreds of kilobytes. The size is determined by the number of constraints in the arithmetic circuit and the cryptographic primitives used. Developers must benchmark proof sizes for their specific use case using tools like snarkjs for Circom circuits or the starknet-rs crate for Cairo programs to get concrete metrics.

The verification cost onchain is intrinsically linked to proof size. A verifier smart contract must execute cryptographic operations (pairings for Groth16, hash functions for STARKs) on the submitted proof data. Larger proofs require more calldata, which is expensive on networks like Ethereum, and more computation, increasing gas fees. For example, verifying a zkSNARK on Ethereum Mainnet can cost between 200,000 to 500,000 gas, a significant portion of which is for processing the proof bytes. Optimizing circuit design to minimize constraints and selecting a proof system with a compact verification routine are essential steps for cost-effective onchain verification.

When architecting a system, you must define your proof size budget based on the target blockchain's limitations. On Ethereum, the calldata cost per non-zero byte is 16 gas (post-EIP-4844), creating a direct monetary cost. If your application expects high throughput, like a zkRollup processing thousands of transactions per batch, even a few hundred extra bytes per proof becomes economically prohibitive. Furthermore, consider future-proofing: newer proof systems like Nova and folding schemes aim to create succinct proofs for incremental computation, dramatically reducing the onchain footprint for recursive or stateful applications.

To systematically evaluate proof sizes, follow this actionable process: First, profile your circuit to understand the constraint count and witness generation. Second, generate proofs for representative inputs using your chosen backend (e.g., Arkworks, Halo2). Third, measure the serialized proof size in bytes. Fourth, deploy a verifier contract on a testnet and benchmark the gas cost of the verify() function. Finally, compare systems; you might find that a PLONK-based system with a universal trusted setup offers a better size/trust trade-off for your project than a Groth16 system, despite a slightly larger proof.

A zero-knowledge proof's size directly impacts the gas cost of onchain verification. On Ethereum, every byte of calldata costs gas, making proof size a primary cost driver. For example, a Groth16 proof for a simple circuit might be ~200 bytes, while a larger Plonk or STARK proof could be tens of kilobytes. The verification contract must receive and process this entire proof, so optimizing for minimal size is essential for user affordability and scalability. This evaluation is the first step in designing a viable onchain zk application.

You must understand the components that constitute a proof's total onchain footprint. The core proof data (e.g., (A, B, C) points for Groth16) is only part of it. You also need to account for any public inputs or public outputs that must be supplied alongside the proof for verification. For recursive proofs or batch verification, you may need to provide multiple proofs or intermediate verification keys. Always calculate the total calldata payload, not just the theoretical proof size from your proving system's documentation.

Different proving systems have vastly different size characteristics. Groth16 proofs are constant and very small (~200 bytes) but require a trusted setup and a specific verification key per circuit. PLONK and Groth16 with universal setup have slightly larger proofs but reusable verification keys. STARKs generate much larger proofs (e.g., 45-200 KB) but offer post-quantum security and transparent setup. Your choice involves a trade-off: smaller proofs reduce gas costs, while larger-proof systems may offer better trust assumptions or faster prover times.

To measure proof size pragmatically, integrate size logging into your development workflow. When you generate a proof in a framework like SnarkJS, Circom, or StarkWare's Cairo, serialize it and check the byte length. Use tools like the Chainscore SDK to simulate onchain verification gas costs with your exact proof payload. This test should be run for a range of realistic input scenarios to understand the variance. Don't rely on estimates; actual measurement against your target blockchain's gas pricing is non-negotiable for production planning.

Finally, consider compression and optimization strategies. Some proof systems allow for proof aggregation, where multiple proofs are verified with a single, marginally larger aggregated proof. Techniques like using elliptic curve point compression can reduce the size of group elements in the proof. For systems with large proofs, you may explore offchain verification with an onchain commitment, or using a proof marketplace like Herodotus or Brevis that may offer optimized verification pathways. The goal is to align proof architecture with your application's cost tolerance and security requirements.

Proof size, measured in bytes, directly impacts the gas cost of onchain verification. In Ethereum, every byte of calldata has a cost. For a zk-SNARK, a proof might be a few hundred bytes, while a zk-STARK proof can be tens of kilobytes. The verification contract must receive and process this data. A smaller proof reduces transaction fees for the end-user but often requires more complex, computationally intensive proving. The primary goal is to find the optimal balance between proving time, verification gas, and security assumptions for your specific application.

Several key factors influence final proof size. The most significant is the underlying proof system (e.g., Groth16, PLONK, STARK). Groth16 proofs are constant and very small (~128-200 bytes) but require a trusted setup. PLONK and similar universal schemes have larger proofs (~400-800 bytes) but offer better scalability. The arithmetization of your circuit (R1CS vs. AIR) and the choice of cryptographic curves (BN254 vs. BLS12-381) also affect size. Furthermore, the number and type of constraints in your circuit are a major driver; more complex logic creates larger proving keys and potentially larger proofs.

To evaluate effectively, you must measure the full verification payload. This includes the proof itself plus any necessary public inputs or outputs. For example, a proof verifying a Merkle membership must also include the leaf and root hashes. Use tools specific to your proof stack for measurement. With Circom, you can compile circuits and inspect the resulting R1CS constraint count. For StarkNet contracts, the starknet-proof-size tool can estimate proof length. Always profile in the context of your target chain; a 50 KB proof may be trivial on a dedicated L2 but prohibitively expensive on Ethereum L1.

Optimization strategies exist at multiple layers. At the circuit level, use custom gates and efficient representations to minimize constraints. Recursive proof composition aggregates multiple proofs into one, amortizing the onchain cost. Proof batching allows verifying multiple statements with a single verification call. For applications like rollups, consider data availability solutions; posting state diffs offchain with a small proof can be cheaper than embedding all data in the proof. The trade-off is introducing external trust assumptions or latency.

Finally, benchmark against real-world limits. Ethereum's block gas limit and calldata costs set a hard ceiling. As of 2024, a verification costing over 1-2 million gas may be unsustainable for frequent use. Compare your metrics to existing systems: a zkEVM proof might be 200 KB, while a simple token transfer proof could be under 10 KB. Use these benchmarks to guide architecture decisions, choosing a proof system and circuit design that delivers the required functionality within your gas budget.

Evaluating proof sizes is a critical step in designing efficient zero-knowledge applications. The primary metric is the onchain verification cost, which is directly proportional to the size of the proof data that must be published to the blockchain. This framework provides a systematic approach to measure this cost across different proving systems like Groth16, PLONK, and STARKs. The goal is to make informed architectural decisions by benchmarking proof size against your application's gas budget and data availability requirements.

The first step is to instrument your proving pipeline. Use your chosen proving library (e.g., snarkjs, arkworks, circom) to generate a proof for a representative set of inputs. Capture the raw byte size of the generated proof. For SNARKs, also capture the size of the public inputs or the verification key if it needs to be submitted onchain. For example, a simple Groth16 proof for a Merkle tree inclusion might be 192 bytes, while a more complex circuit could produce proofs exceeding 1 KB.

Next, simulate the onchain transaction. Encode the proof and necessary public data according to the verifier contract's expected ABI. Use a local testnet or a forked mainnet environment with tools like Hardhat or Foundry to call the verifier's verifyProof function. The key output is the gas consumed, which translates directly to cost. Record gas usage for different proof sizes to establish a baseline. This step reveals the non-linear relationship between proof size and gas cost due to EVM opcode pricing for calldata and elliptic curve operations.

Analyze the data and identify bottlenecks. Break down the gas cost: how much is from proof data (CALLDATA opcode), and how much is from computation within the verifier? For L2s or alternative data availability layers, consider the cost of posting the proof to blobs or calldata. Compare your measurements against known benchmarks; for instance, verifying a Groth16 proof on Ethereum mainnet typically costs 200k-400k gas, while a STARK proof might be larger in bytes but cheaper to verify due to different cryptographic assumptions.

Finally, iterate and optimize. Use the data to guide circuit optimization—reducing the number of constraints or using more efficient primitives can shrink proof size. Consider proof aggregation schemes like proof recursion or proof batching to amortize costs. The choice of proving system is crucial: PLONK/Universal SNARKs have larger proofs but reusable trusted setups, while STARKs have no trusted setup but larger proof sizes. This framework turns proof size from an abstract concern into a quantifiable, optimizable resource constraint for your onchain application.

Proof size is a critical metric for any zero-knowledge (ZK) application destined for a blockchain. Onchain verification costs are directly tied to the amount of calldata required to post the proof, making size optimization a primary economic concern. For example, on Ethereum, posting 100KB of proof data can cost over $50 in gas during periods of high network congestion. Evaluating proof size involves more than just the final byte count; you must consider the proof system (e.g., Groth16, PLONK, STARK), the underlying circuit complexity, and the specific verification contract that will process it.

Start by establishing a baseline. Generate a proof for a representative computation using your chosen proving system and measure the raw serialized proof size. For a Groth16 proof on the BN254 curve, this is typically three elliptic curve points (G1, G2, G1), resulting in a fixed size of ~192 bytes. PLONK-based proofs (like those from snarkjs) are larger and variable, often ranging from 1-10KB, as they include polynomial commitments and evaluation proofs. STARKs produce the largest proofs, often 100KB+, but offer post-quantum security. Use tools like snarkjs's zkey export verificationkey and proof commands to inspect the structure.

The onchain cost is dictated by the verifier smart contract. This contract must receive all necessary proof elements as calldata. Analyze the verifier's verifyProof or verify function signature. It will specify the exact parameters needed, such as uint256[8] memory proof for a Groth16 verifier. Each uint256 is 32 bytes, so this structure consumes 256 bytes of calldata, regardless of the proof's internal compression. Any additional public inputs (the inputs array) add 32 bytes each. Therefore, your evaluation must account for the total calldata: proof parameters plus all public inputs.

To optimize, first minimize your circuit. Use custom constraints to reduce the number of multiplication gates, which directly impacts proof size in SNARKs. Employ hash functions like Poseidon or MiMC that are circuit-friendly, rather than SHA-256. For recursive proofs, where one proof verifies others, size can be amortized across many transactions. Consider proof aggregation protocols like zkEVM's aggregation layer or Nova, which combine multiple proofs into one, drastically reducing the per-transaction cost. Finally, explore data compression techniques for the proof elements themselves before submission, though this adds offchain overhead.

Benchmark rigorously. Create a test suite that generates proofs for varying input sizes and tracks the resulting calldata. Compare different proving backends (e.g., Circom with snarkjs vs. Halo2). Monitor the impact of trusted setup sizes (powers of tau) on your final proof. Remember that a smaller proof often trades off with prover time or memory requirements. The optimal configuration balances verification cost, prover performance, and security. For live deployment, implement gas estimation in your application logic to predict costs dynamically based on current network gas prices and your proof's fixed calldata footprint.

Ultimately, evaluating proof size is an iterative process of circuit design, toolchain selection, and economic modeling. By understanding the breakdown between proof elements and verifier calldata, developers can make informed decisions to build scalable and affordable ZK-powered applications. Key resources for further study include the zkEVM documentation, the Circom documentation, and research papers on PLONK and STARK proving systems.

When deploying a zero-knowledge application on Ethereum, the primary onchain cost is the gas required to verify the proof. This cost is not a single number but a function of two main components: the base verification cost of the verifier smart contract's logic and the calldata cost for transmitting the proof itself. For a typical Groth16 proof on Ethereum, the base verification can cost between 200k to 400k gas, depending on the circuit's complexity and the number of pairing operations. The proof data, usually around 128-256 bytes, is sent as calldata, which at 16 gas per non-zero byte adds another 2k-4k gas. Understanding this breakdown is the first step in cost estimation.

The proof size is a critical variable. In the EVM, calldata pricing creates a direct, linear relationship: more proof data equals higher cost. For a zkSNARK like Groth16, the proof consists of elliptic curve points (e.g., G1 and G2 elements). A standard proof for a BN254 curve is about 128 bytes. However, circuits with more constraints or different proving systems (like PLONK) can yield larger proofs. You can estimate this cost by simply multiplying your proof's byte length by 16 (for non-zero bytes) or 4 (for zero bytes). Tools like the snarkjs library can output the raw proof, allowing you to measure its exact size programmatically before deployment.

The verifier contract logic is the other major cost driver. This contract, often generated by tools like snarkjs or circom, performs cryptographic operations—primarily elliptic curve pairings—to check the proof's validity. The gas cost here scales with the number of constraints or the specific trusted setup used. A circuit with 10,000 constraints will have a cheaper verifier than one with 1,000,000. You can benchmark this by compiling and deploying the verifier to a testnet (like Sepolia) and using a trace from forge or hardhat to get an exact gas report. Always test with the exact proof data you intend to use in production.

To perform a complete estimation, follow this workflow: First, generate your proof offline and serialize it to get the exact byte length. Calculate the calldata cost. Second, deploy your verifier to a local or testnet environment. Use the eth_estimateGas RPC call with the proof data as input to get a total verification cost. Subtract the known calldata cost to isolate the logic cost. For example: Total Gas (500,000) - Calldata Cost (3,000) = Verification Logic Cost (497,000). This separation helps identify optimization targets—whether you need a more efficient circuit or a proof system with smaller serialization.

Optimization strategies are twofold. To reduce proof size, consider proof compression techniques or alternative serialization formats. Some protocols use BLS12-381 curves which have different size characteristics. To reduce verification logic cost, focus on circuit optimization: minimizing constraints, using efficient gadgets, and potentially adopting a verifier with fewer pairings. For batch verification of multiple proofs, the marginal cost per proof can be significantly lower. Always validate your gas estimates against current mainnet block gas limits and prioritize audits for any custom verifier logic, as a single bug can make the entire system unusable.

Evaluating proof sizes for onchain use is a multi-faceted process that balances technical constraints with economic and security considerations. The primary metrics are gas cost for verification and calldata cost for proof submission, which directly translate to user fees. For a system to be viable, these costs must be predictable and remain low relative to the transaction's value. You should benchmark against the target chain's block gas limit and average calldata costs, using tools like snarkjs to generate proofs and hardhat or forge scripts to estimate onchain verification gas.

Your evaluation framework should include a comparative analysis against alternative solutions. For instance, compare a zk-SNARK proof for a private transaction to the gas cost of a standard transfer or a more complex privacy mixnet. Consider the trade-offs: while a zk-rollup batch proof might be large, its cost per transaction amortizes efficiently. Always profile proof generation time and memory usage offchain, as these impact user experience and the hardware requirements for provers. Libraries like arkworks (Rust) or circomlib provide benchmarks for different curve operations and constraint systems.

The next step is integration testing in a forked mainnet environment. Deploy your verifier contract and simulate full transaction flows using tools like Tenderly or Foundry's cheatcodes. This reveals real-world gas costs under network congestion and validates that proof sizes remain within acceptable limits after all encoding and ABI packaging. Monitor for edge cases that could inflate proof data, such as dynamic array lengths or optional fields that aren't efficiently handled by your proof circuit.

Finally, stay informed about layer-2 and scalability innovations that can alter the cost calculus. Ethereum's EIP-4844 (proto-danksharding) introduces blob storage for rollups, drastically reducing calldata costs for large proofs. Emerging chains like zkSync Era and Starknet have native, gas-optimized verifiers for their respective proof systems (SNARKs and STARKs). Regularly consult resources like the Ethereum Gas Station for current fee data and the documentation for your chosen proof framework (e.g., Circom, Halo2) for performance updates.