ZK Proofs vs Public Key Cryptography

Foundational Relationship: ZKPs Extend Public Key Cryptography

Public key cryptography answers a fundamental question: how can two parties establish trust without a shared secret? The key pair mechanism — a public key anyone can use to verify, and a private key only the owner holds — is the bedrock of digital signatures, encrypted communication, and blockchain transaction authentication. Every Bitcoin transfer, every Ethereum smart contract invocation, every TLS handshake relies on this primitive.

Zero-knowledge proofs take this a step further. Where public key cryptography proves "this message came from the holder of this key," ZKPs prove arbitrary statements — "I have sufficient funds," "this computation was performed correctly," "I am over 18" — without revealing the evidence behind them. ZKPs typically rely on public key cryptographic primitives internally (elliptic curve pairings, hash functions, commitment schemes), making them an extension of, not a replacement for, the public key infrastructure.

This layered relationship means that advances in public key cryptography — particularly the post-quantum migration — directly affect ZK systems. zk-SNARKs built on elliptic curve pairings face the same quantum vulnerability as the underlying curves, while zk-STARKs, which rely on hash functions and algebraic structures resistant to quantum attack, offer a natural quantum-safe path for zero-knowledge applications.

Scalability and Performance Trade-offs

The performance profiles of these technologies are nearly inverted. Public key operations — signing a transaction or verifying a signature — are computationally cheap and fast. An Ed25519 signature can be generated in microseconds and verified in microseconds. This efficiency is why public key cryptography scales to billions of TLS connections per day and millions of blockchain transactions.

Zero-knowledge proof generation, by contrast, is computationally expensive. Generating a zk-SNARK proof for a complex computation can take seconds to minutes, requiring significant CPU or GPU resources. However, the verification of that proof is extremely fast and the proof itself is tiny — a few hundred bytes regardless of the computation's complexity. This asymmetry is precisely what makes ZK-rollups work: thousands of transactions are processed off-chain (expensive proof generation), but the on-chain verification is cheap and succinct.

The Ethereum Fusaka upgrade, scheduled for late 2025, includes specific improvements to make ZK-rollup proof verification more gas-efficient on mainnet, further tilting the economics in favor of ZK-based scaling. As hardware acceleration for ZK proof generation matures — including dedicated ASICs and GPU optimizations — the generation cost continues to fall.

Privacy Architectures: Selective Disclosure vs. Encryption

Public key cryptography provides confidentiality through encryption (only the intended recipient can decrypt) and authenticity through signatures (the sender's identity is verifiable). But the signature itself is public — anyone can see which public key signed a transaction. On a transparent blockchain, this means all transaction flows are visible, linked to pseudonymous addresses that can often be de-anonymized.

ZKPs introduce a fundamentally different privacy model: selective disclosure. Rather than encrypting data so only one party can read it, ZKPs allow you to prove properties of data without revealing the data at all. This is transformative for digital identity — proving you meet a credential requirement without exposing the credential itself. Projects like Humanity's zkTLS, launched in 2025, let users prove financial or identity facts ("I have funds to buy a house") without exposing documents.

For AI agents operating in the agentic web, this distinction matters enormously. An agent can use ZKPs to prove it holds valid credentials, has performed a computation correctly, or meets policy requirements — all without exposing its internal state or the sensitive data it processes. Public key signatures alone can prove the agent's identity, but not these richer statements.

The Post-Quantum Transition

Both technologies face a quantum reckoning, but with very different timelines and mitigation strategies. RSA and elliptic curve cryptography — the workhorses of public key infrastructure — are theoretically vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. NIST published its first post-quantum standards in August 2024: ML-KEM (CRYSTALS-Kyber) for key encapsulation and ML-DSA (CRYSTALS-Dilithium) for digital signatures. In March 2025, NIST selected HQC as an additional code-based alternative. Under NIST IR 8547, quantum-vulnerable algorithms will be deprecated by 2035.

The ZK world has a split story. zk-SNARKs relying on elliptic curve pairings (like Groth16) inherit the same quantum vulnerabilities as the underlying curves. However, zk-STARKs — used by StarkNet and increasingly adopted across the ecosystem — are built on hash functions and algebraic techniques that are believed to be quantum-resistant without any migration needed. This has given STARKs a strategic advantage in long-term infrastructure planning.

The practical implication: organizations planning cryptographic infrastructure for the next decade must account for both the PQC migration of their public key systems and the quantum readiness of any ZK systems they deploy. Choosing STARK-based ZK infrastructure today avoids a second migration later.

Developer Experience and Ecosystem Maturity

Public key cryptography benefits from nearly 50 years of library development, standardization, and developer tooling. Every programming language has battle-tested implementations of RSA, ECDSA, Ed25519, and TLS. Developers rarely interact with the cryptographic primitives directly — they call high-level APIs that handle key generation, signing, and verification.

ZK development remains significantly more complex. Writing ZK circuits — the programs that define what a proof attests to — requires specialized languages like Circom, Cairo (StarkNet's language), or Noir. ZK-friendly virtual machines like zkSync's zkEVM and Polygon zkEVM have reduced this barrier by letting developers deploy standard Solidity code on ZK-rollups, but custom ZK applications still demand deep cryptographic expertise.

The gap is narrowing. By 2025, zkEVM compatibility means most smart contract developers can deploy to ZK-rollups without learning ZK-specific tooling. Higher-level frameworks abstract away circuit design for common patterns. But for novel ZK applications — custom identity proofs, verifiable computation, privacy-preserving protocols — the developer experience still lags well behind traditional public key tooling.