ZK-SNARK Revocation Witness vs Explicit On-Chain Record

Privacy-First Design: The holder proves non-revocation without revealing the credential ID or the state of the entire registry. This matters for anonymous credentials and private voting systems. Off-Chain Efficiency: The witness (e.g., a Merkle root) is small (~32 bytes). Only this compact proof is submitted on-chain, leading to ~90% lower gas costs for high-frequency checks compared to on-chain lookups. Prover Overhead: Requires the holder to generate a ZK proof, adding ~100-500ms of client-side compute. Best for user-centric applications where privacy is paramount.

Witness Freshness Challenge: Requires a reliable, available service to provide the latest non-revocation witness. This introduces a trust assumption or liveness requirement on the witness publisher (e.g., Issuer node). Complex State Management: Revocation updates require re-computing and broadcasting a new witness to all potential provers. This is complex for large, dynamic registries. Verifier Complexity: Smart contracts must verify a ZK-SNARK, requiring a pre-compiled verifier (like in zkEVM chains) or custom circuit logic.

Absolute State Authority: The chain is the single source of truth. A verifier checks a public registry (e.g., a mapping or bitfield) for immediate, cryptographically certain revocation status. This matters for high-value DeFi collateral or permissioned access. Simpler Architecture: No need for auxiliary witness services. Revocation is a simple transaction to update the on-chain state. Easier to implement using standards like ERC-5845. Instant Global Sync: Any verifier sees the update immediately upon block confirmation, eliminating freshness delays.

Privacy Leakage: Every check reveals the specific credential ID being queried, creating a public linkage between holder and verifier. Unsuitable for private attestations. Gas Cost Scaling: Storing and checking against a large registry on-chain becomes expensive. A single status check can cost 10x-100x more gas than verifying a ZK proof, especially on Ethereum Mainnet. Chain Bloat: Storing revocation data for millions of credentials leads to significant state growth, a concern for full node operators.

Privacy-Preserving: The prover reveals only a proof of non-revocation, not the credential ID or its status. This is critical for self-sovereign identity (SSI) and anonymous credentials in systems like zkPass or Sismo. Off-Chain Efficiency: The witness (e.g., a Merkle root) is small (~32 bytes). Updating it for many users costs one on-chain transaction, enabling high-throughput revocation for applications like private airdrops or DAO voting.

Prover Complexity: Users must generate a ZK-SNARK proof, requiring client-side computation and trust in setup. This adds friction vs. a simple on-chain check. Liveness Dependency: Users rely on a witness provider (e.g., a sequencer or issuer) to publish frequent, accurate updates. Centralized providers or downtime can brick functionality, a key risk for decentralized applications (dApps) requiring high availability.

Verification Simplicity: A smart contract (e.g., an ERC-721 or registry) holds a direct mapping. Verification is a simple, gas-efficient SLOAD opcode, ideal for NFT gating or DeFi permissions. State Guarantee: Revocation is globally finalized upon blockchain confirmation. There is no liveness risk or trust in external data providers, providing strong assurance for high-value financial credentials or access control.

Linear Scaling Cost: Revoking N users requires O(N) on-chain transactions (e.g., updating a mapping). At ~$5-50 per transaction (variable by chain), this is prohibitive for mass revocation events. Total Privacy Loss: All credential IDs and their revocation status are public on-chain. This leaks user graphs and is unsuitable for private attestations (e.g., proof-of-humanity, medical credentials) where data minimization is required.

Privacy and Scalability: The witness is a small, constant-size proof (e.g., ~1 KB) that a credential is not on a hidden revocation list. This enables private verification without revealing the credential ID or the state of the list, and scales independently of the list size.

This matters for high-throughput, privacy-first applications like anonymous voting (e.g., Semaphore), private airdrops, or enterprise KYC where data minimization is legally required.

Complexity and Cost: Requires a trusted setup for the initial circuit and ongoing prover infrastructure. Generating a witness has computational overhead (e.g., 2-5 seconds prover time) and gas costs for on-chain verification (~500k-1M gas on Ethereum).

This matters for teams with limited cryptography expertise, applications requiring instant verification, or protocols where minimizing single-transaction gas fees is critical.

Simplicity and Verifiability: Revocation status is stored directly in a smart contract (e.g., an Ethereum registry or a Solana program). Verification is a simple, cheap state read. No cryptographic proofs or special clients are needed.

This matters for interoperability, maximal transparency, and developer onboarding. Standards like Ethereum's ERC-7802 or Veramo's on-chain registries use this model for its straightforward auditability and compatibility with any wallet.

Privacy and Scalability Limits: Every credential ID and its status is publicly visible, creating privacy leaks. As the revocation list grows, so does the storage cost and the gas for updates, leading to scaling challenges for large user bases (e.g., 1M+ users).

This matters for consumer applications where user privacy is a product requirement, or for protocols that must manage revocation for millions of credentials cost-effectively.