a16z: Thoughts on and Clarifications Regarding Jolt zkVM
TechFlow Selected TechFlow Selected
a16z: Thoughts on and Clarifications Regarding Jolt zkVM
The cost of zkVM mainly depends on the number of cycles, not on the characteristics of any specific application—a small miracle.
Navigating Web3 tides with focused insightsAuthor: Justin Thaler, Research Partner at a16z
Translation: xiaozou, Jinse Finance
Since the release of our foundational paper and Lasso deployment last summer, to the fully open-source Jolt implementation released last month, we have steadily advanced our research on Lasso+Jolt—the new, simple, high-performance lookup argument and zkVM.
Compared to existing technologies, this implementation demonstrates the promising future of Jolt and challenges many traditional assumptions in SNARK design. Since launch, we’ve continued iterating—adding support for the Rust standard library, integrating improvements from over ten contributors, merging nearly fifty pull requests, and enhancing modularity, performance, and scalability of the codebase.
As we continue improving Jolt, I’d like to respond to external questions and confusion, clarify misunderstandings, and share my thoughts on several key issues. In this article, I will discuss four topics: (1) the relationship between the sum-check protocol and the Binius commitment scheme, (2) the roles of sum-check and lookups in Jolt, (3) elliptic curves versus hashing, and (4) precompiles related to zkVMs.
1. Sum-Check Protocol and the Binius Commitment Scheme
Commitment schemes are often viewed as a cornerstone of SNARKs. However, another equally important component is the polynomial interactive oracle proof (PIOP). For instance, Binius’s commitment scheme based on multilinear polynomials over binary fields is a major advancement, but it must be paired with a suitable PIOP to ensure that the committed data actually verifies the prover’s claims.
Binius’s commitment is highly compatible with PIOPs that use the sum-check protocol. The reasons are both clear (sum-check relies on multilinear polynomials rather than univariate ones; FRI-Binius even uses sum-check internally) and subtle (sum-check-based PIOPs naturally operate over any field characteristic, which is crucial for unlocking Binius’s full performance potential). Unfortunately, Binius’s commitment does not align well with the most commonly used PIOPs today, especially those that do not employ sum-check.
Designing a fast PIOP requires more insight than simply saying “use sum-check.” Binius leverages the sum-check protocol to achieve efficient polynomial IOPs. Sections 4 and 5 of the Binius paper focus specifically on designing novel, efficient sum-check-based PIOPs to pair with its commitment scheme.
The pairing of Binius commitments with Jolt is a match made in heaven—because Jolt is currently the only zkVM built entirely around the sum-check protocol. Today, Jolt uses elliptic-curve-based commitments, but integrating Binius commitments into Jolt is a top priority for our team.
2. Sum-Check, Lookups, Performance, and Succinctness
What sets Jolt apart? Is it because Jolt is the first—and so far only—zkVM to exclusively use a sum-check-based polynomial IOP? Or is it because Jolt achieves the lookup singularity (where nearly everything is done via lookups instead of constraint systems or circuits)? The answer is both. Compared to prior zkVMs, most of Jolt’s succinctness gains come from lookups, while its performance advantages stem from combining lookups with sum-check.
Pure lookup methods perform better for certain instructions—especially those without very small circuits—but may underperform for others that already have extremely compact circuit representations. Overall, however, pure lookup approaches only improve performance, at least when working over 256-bit fields. Currently, the Jolt prover spends about 20% of its time on “instruction execution” lookups and 40% on verifying constraints. Adding more constraints to reduce lookups offers no benefit.
Roughly speaking, Jolt uses lookups to implement the “fetch” and “execute” stages of the CPU fetch-decode-execute cycle. These lookups are fast enough that most of the prover’s time is actually spent proving the “decode” stage, which is handled using traditional constraints.
The pure lookup approach also enables cleaner, more auditable implementations. These benefits are hard to quantify and take time to appreciate. But in terms of lines of code (Jolt’s codebase is about 25k LOC, 2–4x smaller than previous RISC-V zkVMs) and development time, Jolt excels. Such improvements are much harder to achieve than pure speedups: while I expect zkVM provers to become roughly 100x faster in the coming months compared to August 2023, it’s hard to imagine a zkVM ever reducing its code size by an order of magnitude.
3. Elliptic Curves
Public discourse tends to underestimate the value of having a fast zkVM tailored for elliptic curve operations, partly due to widespread excitement around hash-based commitment schemes like Binius.
When proving statements involving elliptic curve cryptography, a curve-native zkVM avoids costly non-native field arithmetic, which can add hundreds or thousands of times more overhead to proof generation. Applications include proving digital signatures (a core task for blockchain light clients and SNARK-based bridges), aggregating Plonk/Groth16/Nova/Honk proofs, and proving Verkle tree authentication paths.
I remain optimistic that the community will recognize the combination of sum-check-based PIOPs with FRI-Binius commitments as the right approach for SNARKs in many applications. Even if that happens, fast SNARKs based on elliptic curves will still be valuable—unless society completely abandons elliptic curve cryptography (e.g., after transitioning away from quantum-insecure cryptographic systems).
In summary:
Curve-based commitments compete with all other existing zkVMs (which already use hash-based commitments over small fields).
When proving statements about elliptic curves (at least absent major advances in non-native field algorithms), users will want to use Jolt with curve-based commitments.
As a pure zkVM, Jolt combined with Binius commitments will outperform other alternatives in most cases—except when proving statements about elliptic curves or operating over small fields (in which case one would use Jolt with curve-based commitments). Otherwise, users will prefer Jolt with Binius commitments.
Even before posting proofs on-chain, elliptic curve-based SNARKs will continue to play a role in compressing proof size and verifier costs. In such cases, zkVMs capable of handling large fields become essential. Even today, projects perceived as using hash-based zkVMs often rely on zkVMs defined over BN254 as part of recursive proof pipelines.
4. Precompiles and zkVM Benchmarks
There has been some discussion around precompiles and their role in zkVMs and benchmarking. Before addressing that, it helps to clarify what we mean by “precompile,” since the term carries different meanings across contexts.
(1) “Precompiles” in Ethereum
In the Ethereum Virtual Machine (EVM), a precompile refers to a frequently executed operation that is natively supported for efficiency. This avoids the substantial overhead and high gas costs associated with executing these operations via long sequences of EVM opcodes.
The distinction between an “EVM precompile” and a “native instruction” (opcode) is largely semantic. For example, Keccak hashing is an EVM opcode, while SHA-2 is an EVM precompile. Both precompiles and opcodes represent frequently used operations, and Ethereum supports them natively for the same reason: to optimize efficiency and gas costs. Admittedly, precompiles are part of the EVM, which is often used broadly to describe Ethereum’s execution environment beyond just opcodes.
If EVM precompiles serve essentially the same function as opcodes, why do they exist separately? Mainly due to convention. Another possible reason is that precompiles involve relatively complex operations—such as cryptographic primitives that might need updates—making them easier to modify in the future if they aren’t assigned dedicated opcodes.
(2) “Precompiles” in zkVM Design
In zkVM design, a precompile refers to a special-purpose SNARK for a specific function (like Keccak or SHA hashing) or a set of elliptic curve operations. Today, SNARK precompiles are typically implemented via hand-optimized constraint systems (though as the community shifts toward sum-check-based SNARKs, the nature of these constraints and how they’re proven will evolve).
There is deep similarity between EVM precompiles and zkVM precompiles. Prior to Jolt’s release, zkVMs implemented native instructions using hand-optimized constraint systems—one per instruction—just as they did for precompiles. The difference between so-called zkVM precompiles and native instructions was purely semantic. There was no practical distinction.
In Jolt, we implement native instructions using lookups instead of traditional constraints. However, choosing to implement some instructions via constraints isn’t inherently problematic. (In fact, lookups can even be viewed as a form of constraint.) Practically speaking, as I mentioned earlier, once we transition to Binius commitments, we may need to use traditional constraints for RISC-V addition and multiplication.
5. zkVM Benchmarking
With this background, let me now share my views on precompiles as they relate to zkVMs and benchmarking.
First, benchmarking various RISC-V zkVMs without precompiles is precisely what RISC-V zkVM benchmarking should entail. The term “zkVM” is informal and inevitably leads to disagreement, but in my view, a RISC-V zkVM with one or more precompiles is no longer a RISC-V zkVM—it becomes a zkVM based on a new instruction set, where each precompile is added as a native instruction. At minimum, every precompile added to a zkVM weakens the value proposition of the zkVM paradigm: each additional circuit increases the surface area for potential bugs, and existing programs cannot leverage these new precompiles out-of-the-box.
Some also conflate zkEVM’s concept of EVM precompiles with the idea of precompiles in general-purpose zkVMs. But these are fundamentally different. While some critical operations in zkEVMs—such as Merkle hashing and signature verification—are indeed more complex than basic RISC-V instructions, this doesn’t change the fact that there is no functional difference between EVM precompiles and native EVM instructions. A zkEVM must support EVM precompiles to claim EVM equivalence. In contrast, a RISC-V zkVM like Jolt that extends the instruction set with precompiles is doing something categorically different.
Another question is how to select a “fair” set of functions for zkVM benchmarking. But for RISC-V zkVMs, any function set is fair. Prover time depends almost entirely on the number of RISC-V CPU cycles executed, for two reasons. First, the prover spends only a small fraction of time on the “execute” phase of the fetch-decode-execute loop. Second, different RISC-V instructions—and memory accesses—have highly similar proof times. (In Jolt, they are all handled via offline memory checking techniques.)
Finally, even when precompiles are used, Jolt is unlikely to underperform relative to alternatives. In fact, I expect it to perform better, because sum-check-based precompiles will be the fastest, and they can be integrated into Jolt with zero overhead since Jolt is purpose-built for sum-check-based PIOPs. Some worry that precompiles using elliptic curve commitments will lag significantly behind those using hash-based schemes. Today, Jolt uses curves—but this isn’t mandatory. We remain fully open to transitioning to Binius in the future.
6. Broader Thoughts on Benchmarking
Our main goal in benchmarking is to understand the intrinsic performance of different proof systems—ideally isolating design-level characteristics from implementation-specific optimizations. This approach allows the community to focus on identifying the right techniques for building high-performance, secure SNARKs. However, comparing two different SNARKs often introduces countless confounding factors that make rigorous comparisons impossible.
Engineering effort is one such confounding factor, despite many in the community appearing to hold the opposite view. The prevailing sentiment seems to be: if a project adds “features” like hardware-specific precompiles or custom optimizations, it deserves credit in any benchmark.
Both perspectives have merit. But in the long run, the latter view is clearly unsustainable. New approaches will always appear disadvantaged in benchmarks because they lack the years of engineering investment that older projects have accumulated. Such a perspective ultimately hinders progress.
Over time, I expect confounding factors in benchmarking to diminish. As SNARK development tools mature, less engineering effort will be required to achieve strong performance. That zkVM cost depends primarily on cycle count—not application-specific features—is something of a miracle (at least for RISC-V). If attention shifts from today’s fragmented landscape of R1CS, AIR, Plonkish, etc., toward constraint system choices, we may see similar simplifications for constraint-system-based SNARKs—using simple metrics like constraint system size instead of cycle counts.
Until then, striking the right balance between under-controlling and over-controlling for confounders remains difficult. Disagreements are inevitable, and builders must provide full context, details, and rationale behind any benchmark so the community can properly understand and engage with it.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
a16z
