A proof format is a standardized data structure and serialization protocol that defines how a cryptographic proof is constructed, encoded, and interpreted by a verifier. It specifies the precise arrangement of data fields, such as commitments, public inputs, and the proof object itself, ensuring different systems can generate and validate proofs interoperably. Common proof formats include Groth16, PLONK, and STARK proofs, each with distinct serialization rules for their specific proving system.
LABS
Glossary
Proof Format
A proof format is the specific data structure and serialization method used to encode a verifiable credential or presentation, defining how claims and cryptographic proofs are packaged.
Chainscore © 2026
definition
BLOCKCHAIN GLOSSARY
What is a Proof Format?
A technical specification defining how cryptographic proofs are structured, serialized, and verified.
The choice of proof format is critical for system compatibility and performance. It dictates how proof data is transmitted over a network or stored on-chain, impacting gas costs in Ethereum Virtual Machine (EVM) environments and verification speed. For instance, a verifier smart contract is programmed to expect a proof in a specific format; submitting a correctly structured but differently encoded proof will cause verification to fail. Standardization efforts, like the EIP-197 precompile for elliptic curve pairings, often formalize a format for a given proof system.
Key components of a proof format typically include the proof points (cryptographic curve elements), the public inputs (the statement being proven is true for), and sometimes auxiliary data. Formats may be binary for efficiency or JSON for debugging. In zk-rollup architectures, the proof format is a core part of the protocol, defining the data that must be posted to Layer 1 to finalize state transitions. Developers must ensure their prover and verifier implementations adhere to the same format specification.
Evolution in proof formats is driven by the need for greater efficiency and new cryptographic features. For example, the transition to recursive proof formats enables proofs to verify other proofs, enabling scalability through proof aggregation. Furthermore, formats are adapting to support custom gates and lookups in advanced proving systems. As zero-knowledge technology matures, interoperability standards for proof formats across different proving backends and virtual machines are becoming increasingly important for the modular blockchain stack.
how-it-works
MECHANISM
How Proof Formats Work
A proof format is a standardized data structure and encoding scheme that defines how a cryptographic proof is constructed, serialized, and verified, enabling interoperability between different proving and verification systems.
A proof format specifies the precise schema for a zero-knowledge proof or validity proof, dictating the arrangement of its core components: the public inputs, the proof string itself, and any auxiliary verification data. This standardization is critical because a proof generated by one proving system (e.g., using the Groth16 protocol) must be verifiable by any compatible verifier, regardless of its implementation. Common formats include Groth16, PLONK, and STARK proofs, each with distinct serialization rules for their unique mathematical structures. Without a defined format, proofs would be opaque blobs of data, impossible to interpret or trust.
The technical implementation of a format involves defining a serialization method, such as a specific byte ordering, field element encoding, and elliptic curve point compression. For instance, the Ethereum ecosystem often uses formats that output proofs as a flat list of finite field elements and elliptic curve points serialized in big-endian order, ready to be passed into a precompiled smart contract for verification. This allows a zk-SNARK proof generated off-chain to be consumed on-chain by a verifier contract that expects data in that exact layout. Standardization bodies and projects like the Ethereum Foundation's zkEVM team often publish formal specifications for these formats to ensure consistency across clients.
Choosing a proof format involves trade-offs between proof size, verification speed, trusted setup requirements, and recursive composition capabilities. A STARK proof format typically yields larger proofs but requires no trusted setup, while a Groth16 format produces very compact proofs at the cost of a circuit-specific trusted ceremony. Furthermore, some advanced formats are designed for recursive proofs, where the output of one verification can be seamlessly used as an input to another, enabling scalable zk-rollup constructions. The format must therefore align with the application's security model and performance constraints.
In practice, developers interact with proof formats through prover and verifier libraries (like snarkjs or circom) and domain-specific languages. These tools handle the complexity of generating and checking proofs according to the chosen format. The evolution of proof formats is a key area of blockchain scalability research, with new standards emerging to support more expressive virtual machines (e.g., zkEVMs) and to enable efficient proof aggregation across multiple transactions or blocks, further reducing the on-chain verification footprint.
key-features
ARCHITECTURAL COMPONENTS
Key Features of Proof Formats
Proof formats are the standardized data structures that define how cryptographic proofs are constructed, serialized, and verified. Their design dictates a system's performance, trust model, and interoperability.
01
Proof Size & Verification Cost
The byte size of a proof directly impacts on-chain gas costs and off-chain bandwidth. Formats like Groth16 produce constant-size proofs, while STARKs and PlonK have logarithmic scaling. Smaller proofs enable cheaper L1 settlement and faster transmission for light clients.
02
Trust Assumptions & Setup
This defines the cryptographic security model. Transparent setups (STARKs) require no trusted ceremony. Trusted setups (Groth16, PlonK) require a one-time powers-of-tau ceremony, producing public parameters. Updatable setups allow the trust to be distributed and refreshed over time.
03
Prover & Verifier Complexity
The computational workload for generating (prover time) and checking (verifier time) a proof. SNARKs prioritize ultra-fast verification (milliseconds) ideal for L1 contracts. STARKs offer faster proving and transparent setups, with slightly larger proofs and longer verification times.
04
Arithmetic Circuit Backend
The underlying cryptographic system that enforces computation integrity. Common backends include:
- R1CS (Rank-1 Constraint Systems): Used by Groth16, Marlin.
- Plonkish Arithmetization: Used by PlonK, Halo2, offering more flexible circuit design.
- AIR (Algebraic Intermediate Representation): The foundation for STARK proofs.
05
Recursion & Composition
The ability to efficiently verify proofs inside other proofs. Recursive proofs (e.g., using cycles of elliptic curves in Halo2) enable incrementally verifiable computation (IVC) and parallel proving. This is essential for scaling zkRollups and building zkEVMs.
06
Interoperability & Standardization
Efforts to create common interfaces for proof systems. The Ethereum EIP-196/197 precompiles enabled BN254 curve verification. Emerging standards like RISC Zero's zkVM and the Polygon zkEVM define format conventions to ensure proofs are portable across clients and verifiers.
common-formats
GLOSSARY
Common Proof Formats
A proof format is a standardized structure for representing and verifying computational integrity. Different formats are optimized for specific trade-offs in size, verification speed, and cryptographic assumptions.
06
Proof of Solvency (Merkle Tree)
A cryptographic proof format used by exchanges to demonstrate they hold sufficient reserves to cover customer liabilities. It involves constructing a Merkle tree where leaves represent hashed customer balances. The exchange publishes the root hash and provides individual Merkle proofs to users, allowing them to verify inclusion without revealing other users' data.
VERIFIABLE CREDENTIALS
Proof Format Comparison: JWT vs. JSON-LD
A technical comparison of the two primary proof formats for encoding and verifying digital attestations in decentralized identity systems.
| Feature / Characteristic | JWT (JSON Web Token) | JSON-LD (JSON for Linked Data) |
|---|---|---|
Core Data Model | Flat, compact JSON claims set | Graph-based, linked data using RDF |
Proof Mechanism | Cryptographic signature in JWS header | Linked Data Proofs (e.g., Ed25519Signature2020) embedded in document |
Semantic Interoperability | Low; relies on claim names known to verifier | High; uses shared vocabularies and contexts for machine-readable meaning |
Selective Disclosure | Not natively supported (requires ZKP/JWT extensions) | Native support via derived proofs and blank nodes |
Standardization Body | IETF (RFC 7519) | W3C (Verifiable Credentials Data Model) |
Typical Use Case | API authentication, compact credential exchange | Complex, interoperable credentials requiring rich semantics |
Signature Verification | Validate JWS structure and signature | Perform Linked Data Proof normalization (canonicalization) then verify |
Human Readability | Moderate (structured JSON) | Lower (requires processing of @context) |
ecosystem-usage
ECOSYSTEM USAGE & STANDARDS
Proof Format
A proof format is the standardized data structure and serialization method used to represent and verify cryptographic proofs, enabling interoperability between different proving systems and verifiers.
01
Groth16
A zk-SNARK proof format known for its small proof size and fast verification. It is non-updatable, meaning the circuit's trusted setup is specific to a single program.
- Key Feature: Extremely succinct proofs (~200 bytes).
- Common Use: Early Zcash, various private payment applications.
- Limitation: Requires a new trusted setup for each circuit.
02
PLONK
A universal and updatable zk-SNARK proof format. Its universal trusted setup can be used for any circuit up to a certain size, and the setup can be securely updated by new participants.
- Key Feature: Single trusted setup for many programs.
- Common Use: Aztec Network, various application-specific rollups.
- Advantage: Enhances trust minimization and developer flexibility.
03
STARKs
A zk-STARK proof format that uses hash-based cryptography (like Merkle trees) instead of elliptic curves. It is post-quantum secure and does not require a trusted setup.
- Key Feature: Scalable, transparent proofs.
- Common Use: Starknet, Polygon Miden.
- Trade-off: Proofs are larger than SNARKs (~45-200 KB) but verify quickly.
04
RISC Zero zkVM
A proof format that generates zk-SNARKs for arbitrary computations executed inside its RISC-V virtual machine. It proves correct execution of standard machine code.
- Key Feature: Developer-friendly; write provable code in Rust.
- Proof Type: Uses the zk-STARK protocol, then wraps it in a SNARK (Groth16) for efficient on-chain verification.
- Common Use: General-purpose zk-rollups and verifiable compute.
05
EIP-4844 & Blobs
An Ethereum upgrade introducing blob-carrying transactions as a new data format for rollups. While not a cryptographic proof itself, it defines the standard for how large batches of calldata and proofs are posted to Ethereum.
- Purpose: Dramatically reduces L2 data availability costs.
- Format: Blobs are ~128 KB data packets that are not accessible to the EVM but are committed to by consensus.
- Impact: Essential infrastructure for scalable, cost-effective proof verification.
06
Verification Smart Contracts
On-chain contracts, often called verifiers, are programmed to validate a specific proof format. They are the final arbiter of a proof's correctness on a blockchain.
- Function: Takes proof bytes and public inputs; returns
trueorfalse. - Key Consideration: Gas cost of verification varies significantly by format (e.g., Groth16 verifiers are very gas-efficient).
- Example: An Optimism fault proof or a zkRollup's state transition verifier.
security-considerations
PROOF FORMAT
Security & Privacy Considerations
The design of a cryptographic proof format directly impacts the security guarantees and privacy properties of a zero-knowledge system. These considerations define what is proven, what is hidden, and the trust assumptions involved.
01
Trusted Setup Requirements
Many proof systems, particularly zk-SNARKs, require a trusted setup ceremony to generate public parameters. This introduces a potential security risk: if the setup is compromised, proofs can be forged. Systems like zk-STARKs and Bulletproofs are transparent, eliminating this trust assumption. The security model must account for whether a universal (reusable) or circuit-specific setup is used.
02
Proof Soundness & Knowledge Soundness
Soundness guarantees that a false statement cannot be proven. Knowledge soundness (proof of knowledge) ensures the prover actually possesses a valid witness, not just that a valid witness exists. A proof format must specify its soundness error (e.g., 2^-128), which is the probability a malicious prover can succeed. This is a foundational cryptographic security property.
03
Zero-Knowledge Property
A core privacy feature where the proof reveals nothing beyond the validity of the statement. The proof format must guarantee computational or statistical zero-knowledge. This prevents leakage of sensitive witness data (e.g., account balances, private keys, or transaction details). Formats vary in how they achieve this, often through randomization and commitment schemes.
04
Post-Quantum Security
The proof format's reliance on cryptographic assumptions determines its resilience against future quantum computers. zk-SNARKs often depend on elliptic curve pairings (broken by Shor's algorithm), while zk-STARKs and some Bulletproofs constructions rely on collision-resistant hashes, which are considered post-quantum secure. This is a long-term security consideration for systems requiring longevity.
05
Proof Size & Verification Cost
Proof size impacts bandwidth and storage, while verification cost (gas on Ethereum) affects practicality. Smaller proofs (e.g., Groth16 SNARKs) are cheaper to verify but may require a trusted setup. Larger proofs (e.g., STARKs) are transparent but have higher verification costs. The trade-off directly influences the economic security and scalability of the application.
06
Recursion & Aggregation
The ability to verify proofs inside other proofs (recursion) or combine multiple proofs into one (aggregation) is a security and scalability feature. It allows for creating a single proof for a batch of transactions or a rollup's state transition. The proof format must support efficient recursive verification, which often requires specific elliptic curves (e.g., cycles of curves) or FRI-based constructions.
PROOF FORMAT
Technical Deep Dive
A proof format is the standardized data structure and encoding method used to represent a cryptographic proof, defining how the prover's claim and the verifier's check are serialized and communicated.
A proof format is the standardized data structure and encoding method used to represent a cryptographic proof, defining how the prover's claim and the verifier's check are serialized and communicated. Its importance is foundational: it ensures interoperability between different proving systems and verifiers, enables efficient proof aggregation and recursion, and directly impacts proof size and verification speed. Common formats include Groth16 proofs, Plonk proofs, and STARK proofs, each with distinct serialization rules. Without a standardized format, proofs generated by one system would be unreadable by another, crippling the composability essential for scalable blockchain applications like zkRollups and validiums.
PROOF FORMAT
Frequently Asked Questions
A proof format is the standardized structure and encoding for cryptographic proofs, enabling verification of computational integrity. This section answers common questions about their purpose, types, and applications in blockchain systems.
A proof format is a standardized data structure and serialization method for representing a cryptographic proof, such as a zero-knowledge proof (ZKP) or validity proof, enabling independent verifiers to check the correctness of a computation or state transition. It defines how the proof's components—like commitments, public inputs, and the proof bytes themselves—are organized and encoded. Common formats include Groth16, PLONK, and STARK proofs, each with specific serialization rules. Standardized formats are crucial for interoperability, allowing proof generation in one system (e.g., a zk-rollup) and verification in another (e.g., an Ethereum smart contract), forming the backbone of scalability and privacy solutions.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall