zk-SNARK

If the statement is true and both the prover and verifier follow the protocol honestly, the verifier will always accept the proof. In a healthcare federated learning context, this guarantees that a hospital correctly executing a model update on genuine patient data will never be falsely rejected by the network coordinator.

• Honest Prover Guarantee: A valid witness always produces a convincing proof
• Deterministic Acceptance: No false negatives for legitimate computations
• Protocol Fidelity: Ensures compliant nodes are never penalized for correct behavior

A computationally bounded prover cannot convince the verifier of a false statement, except with negligible probability. This property cryptographically enforces that a hospital cannot fabricate a model update without actually training on real data, preventing data poisoning and free-riding in collaborative learning.

• Knowledge Soundness: Proving implies actual knowledge of the witness
• Computational Binding: Breaking soundness requires solving hard mathematical problems
• Fraud Prevention: Malicious actors cannot inject fake gradients into the global model

The proof reveals nothing beyond the validity of the statement itself. When a medical institution submits a zk-SNARK proof that it correctly trained a model, the verifier learns only that the computation was performed correctly—not the patient data, model architecture, or intermediate gradients.

• Perfect Secrecy: The verifier gains zero information about the private input
• Simulatability: A simulator can generate indistinguishable proofs without the witness
• HIPAA Alignment: Enables compliance by mathematically eliminating data exposure risk

The proof size is small (typically a few hundred bytes) and verification time is fast (often sub-second), regardless of the complexity of the computation being proven. This enables a central aggregator to verify thousands of hospital model updates without proportional computational overhead.

• Constant-Size Proofs: Proof length does not grow with computation complexity
• Sub-Linear Verification: Verifier work is exponentially smaller than re-executing the computation
• Scalable Auditing: A single lightweight node can validate an entire federated round

The proof generation requires no back-and-forth communication between prover and verifier. A hospital generates a single, self-contained proof and broadcasts it to the network. Any verifier can independently check it without engaging in an interactive challenge-response protocol.

• Single Message Proof: One-shot generation and verification
• Asynchronous Validation: Verifiers can check proofs at any time without coordinating with the prover
• Broadcast Friendly: Ideal for decentralized networks where nodes operate independently

zk-SNARKs require a one-time trusted setup ceremony to generate a Common Reference String (CRS). The security of all proofs depends on the destruction of the toxic waste generated during this phase. In healthcare consortia, this is typically performed via multi-party computation ceremonies where no single institution controls the secret.

• Structured Reference String: Pre-generated public parameters shared by all participants
• Toxic Waste: Secret randomness that must be destroyed to preserve soundness
• Ceremony Integrity: Requires at least one honest participant to destroy their share
• Per-Circuit Setup: A new ceremony is needed for each distinct computation circuit

The foundational cryptographic primitive from which zk-SNARKs derive. A ZKP allows a prover to convince a verifier that a statement is true without revealing any information beyond the statement's validity. zk-SNARKs add the properties of succinctness (small proof size) and non-interactivity (no back-and-forth communication).

• Completeness: An honest prover always convinces an honest verifier.
• Soundness: A malicious prover cannot convince a verifier of a false statement.
• Zero-Knowledge: The verifier learns nothing beyond the truth of the statement.

Zero-Knowledge Scalable Transparent Argument of Knowledge. A variant that eliminates the trusted setup requirement of zk-SNARKs by using publicly verifiable randomness and collision-resistant hash functions instead of elliptic curve pairings. STARKs produce larger proofs than SNARKs but offer post-quantum security and faster proving times for large computations.

• Transparent setup: No toxic waste, fully public parameters.
• Scalability: Proving time scales quasilinearly with computation size.
• Quantum-resistant: Relies on hash functions, not bilinear pairings.

A multi-party computation protocol required by most zk-SNARK constructions to generate the Common Reference String (CRS). Participants sequentially contribute randomness to generate the proving and verification keys. The security guarantee holds as long as at least one participant honestly destroys their contribution—known as the 'toxic waste.'

• Powers of Tau: A universal setup ceremony usable across multiple circuits.
• Circuit-specific: Some SNARKs require a new ceremony per application.
• Perpetual ceremonies: Ongoing setups that continuously accept new contributions.

The mathematical encoding that transforms a computational statement into a form suitable for zk-SNARK proving. A QAP represents a computation as a system of quadratic equations over polynomials, enabling the prover to demonstrate knowledge of a satisfying assignment without revealing it. The degree of the QAP polynomial directly impacts proving time and proof size.

• R1CS: Rank-1 Constraint System, the intermediate representation compiled into a QAP.
• Witness: The secret assignment that satisfies the constraint system.

A non-falsifiable cryptographic assumption underlying the soundness of many pairing-based zk-SNARKs. KEA posits that if an adversary can produce a pair of group elements with a specific relationship, they must 'know' the exponent that relates them. This assumption enables extractability—the ability to recover a witness from a valid proof in the security reduction.

• Non-falsifiable: Cannot be empirically disproven through efficient experiments.
• Bilinear pairings: The algebraic structure enabling KEA-based constructions.

A technique where a zk-SNARK proves the validity of another zk-SNARK verification, enabling proof aggregation and incrementally verifiable computation. A single constant-size proof can attest to an arbitrarily long chain of computations. This is critical for blockchain scalability solutions like zk-rollups and Mina Protocol's succinct blockchain.

• Proof-carrying data: Extending recursion across distributed computations.
• IVC: Incrementally Verifiable Computation, maintaining a running proof of state.