Jolt gets a 6× speedup — and we’re just getting started

After six months of work, Jolt now fully integrates the Twist and Shout memory-checking arguments. This unlocks:

• Over 1 million RISC-V cycles/sec on a 32-core CPU and over 500,000 cycles/sec on a MacBook, a roughly 6x speedup compared to just a few months ago.
• Proof sizes of about 50 KB, an order of magnitude smaller than alternative zkVMs.
• An even cleaner codebase. No longer does the Jolt verifier need to know “Lasso decompositions” of RISC-V primitive instructions. It now just evaluates the multilinear extension of each instruction at a random point. The Jolt core repository is now about 35,000 lines of code.

Twist and Shout bring economies of scale to proving. They pay a small fixed cost that’s independent of the number of RISC-V cycles proved, to lower the per-cycle proving cost. As a result, more cycles mean a faster prover on a per-cycle basis. In other words, Jolt’s throughput improves with longer traces. At the scale of real proving workloads — for example, an Ethereum block consuming hundreds of millions of RISC-V cycles — Jolt runs near its top speed. (I’ve included a plot of measured speed vs. cycle count below.)

 

 

This is just the beginning. On top of additional optimizations that are in progress, Twist and Shout make possible a highly efficient “streaming prover,” which is our next major implementation target. That means we’ll be able to prove arbitrarily long executions in under 2 GB of RAM, without recursion. This will enable proving on resource-constrained devices like mobile phones, and eliminate the complicated recursion-heavy stack most zkVMs today use to control prover space. 

Jolt is also far less vulnerable to “prover killers,” workloads that crush other zkVMs. For example, big-number arithmetic is a bottleneck for zkVMs operating over 31-bit fields: They have to decompose large values into bytes and multiply byte-by-byte, since the product of two 16-bit numbers already overflows a 31-bit field element. Jolt avoids this overhead by using large prime fields. In general, Jolt’s prover time depends primarily on the total cycle count, and shows minimal variation between different programs of the same length. It matters little which primitive instructions are executed, how much memory is touched, or other workload details.

Under the hood, Jolt avoids much of the machinery that makes other zkVMs slow and brittle: Jolt needs no recursion, no quotient polynomials, no byte decomposition, no grand products, no permutation checks, no complicated circuits. Instead, Jolt builds on a completely different foundation. It uses sparse polynomials, elliptic-curve commitments (for now), the sum-check protocol, and batch-evaluation arguments (also called lookups). 

The most basic component in this list is the sum-check protocol, a simple interactive proof that underpins the fastest-prover SNARKs. Its efficiency benefits apply broadly, even if you don’t care about Twist, Shout, or Jolt. This replaces the prevailing stack with something far more modular, analyzable, and performant. Jolt isn’t an incremental evolution of prior zkVMs: It’s a fundamentally different design.

Today, the Jolt prover is doing under 100,000 times more work than simply running the computer program with no proof of correctness. That is, proving a single RISC-V cycle requires under 100,000 CPU cycles on a laptop. This is what we call the prover work overhead. This means that Jolt has reached Speed Stage 1 on our roadmap for tracking zkVM progress. The prover overhead of other projects remains around 1 million, an order of magnitude higher than Jolt’s. 

Here’s another way to frame Jolt’s performance: The Jolt prover now performs under 800 field multiplications per RISC-V cycle. In contrast, the Plonk prover applied to an arithmetic circuit commits to ~8 random values per gate, translating to at least 800 field multiplications per gate. This makes the Jolt prover faster per RISC-V cycle than the Plonk prover per gate. For most applications, this means the Jolt prover is much faster than popular SNARKs applied to hand-optimized circuits.

Why is this true? Because SNARKs like Plonk and Groth16 fail to exploit repeated structure at multiple levels. First, their prover costs don’t improve when applied to circuits with internal structure — they’re just as slow on structured circuits as on arbitrary ones. Second, encoding computations as circuits is already a mistake in many contexts. Batch-evaluation arguments like Shout do the opposite: They exploit repeated evaluation of the same function to dramatically reduce prover cost. And batch-evaluation is exactly what VMs do: They execute the same small set of primitive instructions over and over, one per cycle. So while a VM abstraction introduces some overhead compared to hand-optimized circuits, the structure it imposes enables optimizations that more than make up for it.

***

For more information on Twist and Shout and their implications for SNARK design, see this recent talk at the a16z crypto summer research lab or this one at the Simons Institute Proofs workshop, and stay tuned for further updates.

***

Markos Georghiades is an engineering intern at a16z crypto, where he focuses on cryptography and core Jolt development. He’s an undergraduate at the University of Waterloo studying Computer Science and Mathematics.

Justin Thaler is Research Partner at a16z and an Associate Professor in the Department of Computer Science at Georgetown University. His research interests include verifiable computing, complexity theory, and algorithms for massive data sets.

Andrew Tretyakov is a University of Waterloo student and cryptography engineering Intern at a16z crypto. He contributes to the Jolt zkVM project, working on core prover components, protocol architecture, and guest program optimizations.

Julius Zhang is an engineering intern at a16z crypto, where he works on Jolt. Previously, he studied Mathematics and Computer Science at Stanford. 

Michael Zhu is a research engineer for a16z crypto, writing open-source code in collaboration with the research team and helping portfolio companies on all things smart contract-related. Prior to joining a16z crypto, Michael led protocol development at 0x Labs, architecting smart contracts to facilitate peer-to-peer trading on multiple blockchains. Before that, he was a student at Stanford University, where he received BS and MS degrees in Computer Science.

***

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.