6/ So yes, zkVMs and SNARKs hold enormous potential, but we flirt with disaster if we pretend they’re ready for prime time. I’ll be using these stages to track zkVM progress in the coming years—and hope others will too. Check out my post here:

5/ Crucially, we must isolate a proof system’s fundamental efficiency. Right now, many benchmarks bundle everything—proof system, engineering, hardware boosts, and hand-tuned precompiles—into a single top-line number, obscuring where we really stand.

4/ On performance, overheads versus native execution still exceed 100,000×—a non-starter for most use cases. My post proposes five “performance stages” to slash that overhead by orders of magnitude and eventually enable on-device proofs.

3/ On security, I identify three stages for formal verification: . • Verified protocols • Verified verifiers • Verified provers. Until we reach Stage 2, we can’t really call a zkVM “secure”—and getting there is still likely several years off.

2/ I’ve just published a post outlining a structured roadmap for zkVM development. It separates “security stages” from “speed stages,” giving us a transparent way to track progress. Read it here:

1/ Beware the hype: while SNARKs and zkVMs show immense promise, they’re not ready for complex, high-stakes deployments. Bugs are everywhere, formal verification is nascent, and proofs can be hundreds of thousands of times slower than native execution.

RT @recmo: @Ingo_zk @yuval_domb It's no exaggeration that this will make most cryptography 10-20% faster.

RT @zkv_xyz: Memory checking is a major bottleneck in zkVMs. This new paper by @SuccinctJT and @srinathtv improves it by 10×, making zkVM….

8/ Bottom line: Twist & Shout validate our big design bets in Jolt and, as a bonus, give much faster SNARKs outside of the zkVM context too. See the post and paper for details, and stay tuned for more updates as the Jolt implementation matures.

7/ If you prefer non-uniform circuits to zkVMs, Shout implies a Spartan variant, which we call SpeedySpartan, that is an order of magnitude faster than Spartan itself. The SpeedySpartan prover simply commits to witness. The rest is field ops!.

6/ On “SNARK-friendly VMs”: Twist & Shout bring the cost profile of SNARKs even closer to that of real CPUs. Proposals for “SNARK-friendly” VMs at best cater to today’s SNARK limits, and prevent reuse of mature tooling.

5/ The key performance dichotomy in SNARK design isn’t “big fields vs. small fields” or “hashing vs. curves”. It’s the sum-check protocol and multilinear polynomials vs. univariate polynomials.

4/ One takeaway: 256-bit or binary fields are better than 31-bit or 64-bit fields for SNARK performance. One reason among many: committing to 0s is basically free with elliptic curves and 30x faster in binary fields than in 31-bit fields.

3/ Key insight of Twist+Shout: The prover can quickly commit to huge, sparse vectors, making memory-checking boil down to massive but straightforward constraint systems. Crucially, these constraints are sparse, and the sum-check prover only pays for non-zero elements.

2/ Jolt’s design turns every VM action into lookups (reads into read-only memory) or reads/writes (for registers + RAM). Today we use Spice for reads/writes and Lasso for lookups. Soon, we'll switch Spice to Twist and Lasso to Shout.

1/ We just unveiled Twist and Shout, two new memory-checking arguments designed to supercharge the Jolt zkVM. Expect ~3x end-to-end prover speedups (on top of 2x improvements that are already in progress), plus shorter proofs. Full post:

6/ Read more about our journey toward a verified zkVM here, and stay tuned for more updates:

5/ zkVMs today are massive, with codebases reaching hundreds of thousands of lines, and almost certainly contain critical flaws. The rush to deploy them worries me. This informs Jolt’s focus on simplicity in addition to performance.

4/ But the biggest challenge lies beyond soundness. Ensuring Jolt’s Rust implementation matches its specification is where the real work begins—and we likely won’t even start that in earnest for another year or more.

3/ We’ve already verified Jolt’s table decompositions, the backbone of its lookup-centric architecture. Next, we’ll tackle formal verification of the polynomial IOPs powering Jolt (Spartan, Lasso, Spice).