a16z Crypto Blog Analysis – Batch 4

1. The Path to Secure and Efficient zkVMs: How to Track Progress

Author: Justin Thaler | Date: March 11, 2025

Core Thesis

zkVMs are years away from being secure and performant enough for real deployment. The industry is overhyping readiness while current systems are riddled with bugs and have ~1,000,000x prover overhead. The post proposes staged, concrete milestones to cut through hype.

Key Insights

  • Current zkVMs have overhead approaching 1 million times native execution cost
  • Projects paying for onchain proofs today are "merely an expensive way of pretending a system is secured by a SNARK" β€” actually secured by permissioning or vulnerable
  • Pre-compiles are a crutch, not a solution β€” they sacrifice security (bugs) and developer experience while only helping narrow workloads
  • 100 bits of classical security is the bare minimum; industry should target 128 bits
  • Post-quantum security is less urgent than fixing bugs over the next 5+ years
  • Performance benchmarks are misleading when they lump together intrinsic efficiency, pre-compiles, and hardware acceleration

Technical Mechanisms

  • Security Stages (3 stages, formal verification-based):
    • Stage 1: Correct protocols β€” formally verify PIOP soundness, PCS binding, Fiat-Shamir composition, constraint system equivalence to VM semantics, and full end-to-end proof
    • Stage 2: Correct verifier implementation β€” formally verify that Rust/Solidity verifier matches the verified protocol
    • Stage 3: Correct prover implementation β€” formally verify prover for completeness and ZK
  • Performance Stages:
    • Speed Stage 1: ≀100,000x overhead (single-threaded, no pre-compiles) β€” ~30K RISC-V cycles/sec
    • Speed Stage 2: ≀10,000x overhead (FPGAs allowed)
    • Speed Stage 3: ≀1,000x via automatically synthesized, formally verified pre-compiles
    • Memory Stage 1: <2GB prover memory (enabling mobile/client-side proving)
    • Memory Stage 2: <200MB prover memory
  • Proof size must be <256KB and verification time <16ms for Stage 2+

Research Directions

  • Formal verification of SNARKs (ZKLib effort)
  • Fiat-Shamir security β€” fundamental open research question; known attacks resemble recursive proof circuits
  • Automatically synthesized and formally verified pre-compiles
  • Binary field SNARKs (promising but hindered by current CPU/GPU architectures, need FPGAs)
  • Generating formally verified bytecode
  • Reducing prover memory for mobile/browser client-side proving

2. On the Limits of Encrypted Mempools

Authors: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach | Date: July 15, 2025

Core Thesis

Encrypted mempools cannot serve as a universal solution to MEV. They face fundamental technical limitations (metadata leakage, spam, fee auction disruption), economic challenges (incentivized decryption, payment-for-order-flow dynamics), and significant engineering complexity. The community needs other complementary solutions.

Key Insights

  • Speculative MEV undermines user-decrypts models: attackers submit encrypted txs hoping for favorable ordering, only decrypt if profitable
  • Threshold encryption trust assumptions are stronger than consensus assumptions β€” colluding committee members leave no public evidence (unlike forking)
  • Metadata leaks are devastating: transaction size, broadcast time, originating IP, sender address, gas budget all leak intent even with encryption
  • Economic impossibility: Even with perfect encryption, users can be incentivized to voluntarily reveal transactions (MEV Share model / payment-for-order-flow like Robinhood)
  • Encrypted mempools increase price uncertainty, leading to more failed trades and ironically more arbitrage opportunities
  • Censorship compliance may force users to reveal plaintext anyway

Technical Mechanisms

  • Decryption approaches: TEEs (hardware trust), threshold encryption/secret-sharing (committee trust), time-lock/delay encryption (computational puzzles), witness encryption (theoretical ideal, no practical constructions)
  • Metadata attack vectors: Transaction size correlation, timing analysis, IP address monitoring, gas budget fingerprinting, sender address linking
  • Mitigations and their costs: Padding (wastes bandwidth), delays (harms latency), Tor (complexity), SNARKs for well-formedness proofs (overhead)
  • Witness encryption generalizes all other approaches but requires trusting committee anyway for PoS chains (committee can privately simulate consensus)

Research Directions

  • Hybrid designs where only certain high-value transactions use encryption
  • Batch threshold decryption for efficiency
  • Application-layer MEV defenses
  • Minimizing finality time as MEV mitigation
  • ZK proofs of censorship compliance for encrypted transactions
  • Practical witness encryption constructions

3. Putting the ZK in zkVM: Jolt Now Supports Zero Knowledge

Authors: Sagar Dhawan, Markos Georghiades, Justin Thaler, Andrew Tretyakov, Michael Zhu | Date: March 3, 2026

Core Thesis

Jolt (a16z's open-source zkVM) now achieves true zero knowledge without recursion, without trusted setup, and with only ~3KB additional proof size and essentially no prover time increase. This is notable because most "zkVMs" are not actually zero-knowledge without expensive recursive wrapping.

Key Insights

  • Most "zkVMs" misuse the term "zk" β€” they provide succinctness (short proofs) but not zero knowledge (privacy of witness data)
  • Adding ZK typically requires expensive recursive "wrapping" in another proof system, often sacrificing transparency (introducing trusted setup)
  • Jolt's approach adds ZK with negligible overhead: +3KB proof size, ~0 prover time increase
  • The blinded proof is actually shorter than the original because hiding commitments compress multiple field elements into single group elements

Technical Mechanisms

  • NovaBlindFold technique (from Nova/HyperNova folding schemes, 1990s origins):
    1. Sum-check prover messages leak witness data β€” this is the only non-ZK component
    2. Blinding step: Replace cleartext sum-check messages with hiding commitments β†’ produces blinded proof Ο€ (shorter than original)
    3. Extension proof Ο€': Proves the blinded commitments satisfy sum-check verifier checks
    4. Ο€' constructed by: expressing sum-check verifier checks as constraint system, folding the real witness with a random solution (one-time pad intuition), then applying Spartan (non-ZK) to prove the folded solution satisfies constraints
    5. Spartan on folded solution grows only logarithmically with solution length
  • No recursion needed; no trusted setup; maintains transparency

Research Directions

  • Client-side ZK proving on mobile devices
  • Privacy-preserving applications leveraging true ZK without performance penalties
  • Further optimization of sum-check based proof systems
  • Folding scheme techniques for other proof systems

4. Stablecoins: Payments Without Intermediaries

Author: Chris Dixon | Date: April 9, 2025

Core Thesis

Stablecoins are the "WhatsApp moment for money" β€” they can do for payments what email did for communication. The current payment system is a Rube Goldberg machine of intermediaries imposing regressive taxes on commerce. Stablecoins on open blockchains offer a clean-slate reset.

Key Insights

  • International remittances cost up to 10% in fees (200remittance=200 remittance =12.13 USβ†’Colombia traditionally vs $0.01 via stablecoins)
  • B2B payments Mexicoβ†’Vietnam take 3-7 days, cost 14βˆ’14-150 per $1000, pass through up to 5 intermediaries
  • In 2024, stablecoins moved $15.6 trillion in value, matching Visa's volume
  • For low-margin businesses (grocery stores), reducing payment fees by 1.5% could double net income
  • SpaceX uses stablecoins for corporate treasury management; ScaleAI for global workforce payouts; Stripe offers 1.5% crypto checkout
  • Smart regulation is the unlock, not the obstacle β€” stablecoin legislation could trigger mainstream adoption
  • Blockchains are the internet's native financial layer: composable, programmable public infrastructure

Technical Mechanisms

  • Stablecoins on open, programmable blockchains as neutral financial infrastructure (analogous to TCP/IP for data)
  • Programmable payments: machine-to-machine transactions, micropayments, transparent audit trails
  • Bypassing SWIFT and correspondent banking networks entirely
  • Open protocol model vs. closed corporate network model

Research Directions

  • Stablecoin regulatory frameworks (differentiating network tokens vs. security tokens)
  • AI agent-powered marketplaces using stablecoin payments
  • Smart wallet systems with budget rules for automated micropayments
  • Government spending transparency via onchain audit trails
  • Reducing fiat on/off-ramp costs (currently 0-5% for stablecoin↔local currency)

5. Privacy Trends for 2026

Authors: a16z crypto editorial (Ali Yahya, Shane Mac, Adeniyi Abiodun, Daejun Park) | Date: January 6, 2026

Core Thesis

Privacy is becoming the defining competitive moat in crypto for 2026, spanning blockchain differentiation, decentralized messaging, secrets infrastructure, and security testing paradigms.

Key Insights

  1. Privacy as chain moat: "Bridging tokens is easy, bridging secrets is hard." Privacy chains create winner-take-most dynamics because moving between private chains leaks metadata. Public chains are undifferentiated and race to zero fees; privacy chains have genuine network effects and lock-in.
  2. Decentralized quantum-resistant messaging: Quantum-resistant encryption is necessary but insufficient β€” centralized servers (Signal, WhatsApp) are single points of government coercion. Need open protocols with no private servers, where users own messages with keys. "Shut down an app and 500 new versions pop up."
  3. Secrets-as-a-service: Need programmable data access controls, client-side encryption, decentralized key management enforced onchain β€” making privacy core infrastructure rather than application-level patches. Critical for institutional adoption (finance, healthcare, RWA tokenization).
  4. "Spec is law" security testing: DeFi security must move from heuristic bug-hunting to proving global invariants. AI-assisted proof tools can help write specs. Runtime assertions enforce invariants as live guardrails, automatically reverting violating transactions. "Almost every exploit to date would have tripped one of these checks."

Technical Mechanisms

  • Privacy network effects and metadata leakage at chain boundaries (timing, size correlations)
  • Decentralized messaging: open protocols, no private servers, blockchain-incentivized node replacement, user-owned keys for message ownership
  • Secrets-as-a-service: programmable native data access rules, client-side encryption, decentralized key management with onchain enforcement
  • Formal verification + AI-assisted invariant generation for DeFi security
  • Runtime enforcement of global invariants as transaction-level assertions

Research Directions

  • Privacy-preserving cross-chain bridges that minimize metadata leakage
  • Open decentralized messaging protocols with quantum-resistant encryption
  • Onchain secrets infrastructure for institutional adoption
  • AI-assisted formal verification and invariant discovery for smart contracts
  • Runtime enforcement mechanisms for DeFi safety properties