a16z: Key Elements for Builders: 'Jolt Inside'

Author: a16z crypto

Article translation: Block unicorn

Introduction

Today, LayerZero announced the release of their new chain Zero, which includes multiple technological advancements—including a brand-new zero-knowledge proof method that decouples transaction execution from verification. All of this is made possible by “Jolt Inside.”

What is Jolt? Jolt is an open-source RISC-V zkVM (zero-knowledge virtual machine, or more precisely, a “streamlined” virtual machine). It is fast, secure, and easy to use. It represents a new, cutting-edge SNARK design approach developed over three years by a16z crypto, which we are open-sourcing for anyone to use or further develop. But the story of Jolt’s creation is actually a decades-in-the-making story.

Why are zkVM and SNARK design so important?

Before diving into the evolution of SNARK design, we first need to understand what a zkVM is.

These virtual machines are often called “zk” virtual machines, but the more common feature here is simplicity. While “zero-knowledge” is crucial for privacy, “streamlined” means proofs are short and easy to verify—two useful but distinct properties that are often conflated. (Jolt already has the property of simplicity and will soon also implement zero-knowledge.)

But why are zkVMs so important? zkVMs and, more broadly, SNARKs (succinct non-interactive arguments of knowledge) are key components in blockchain scalability, privacy, and security. These proofs, arguments, and zero-knowledge (collectively, verifiable computation techniques) have countless applications across the crypto industry and beyond.

Due to traditional design architectures and other reasons, the industry has so far taken relatively complex approaches to building zkVMs; we will elaborate on this in more detail below. However, Jolt from the outset focused on a fundamentally different SNARK design approach, aiming for higher efficiency, usability, and performance.

In short, a zkVM is a way to prove that you correctly executed a computer program. Compared to other SNARKs, zkVMs are developer-friendly. By leveraging existing computational infrastructure (such as the open-source LLVM compiler ecosystem), developers can harness the power of SNARKs in their preferred programming language without needing domain-specific languages (DSLs).

This is very similar to how many modern cryptography tools today—such as standards and built-in libraries for encryption and digital signatures—are used daily by developers without understanding their internal workings. Jolt provides developers with a similar abstraction layer: just use existing programs and verify them, without worrying about the interaction between the two. This is a necessary condition for the widespread adoption of any new cryptographic application.

Developers can focus on practical operations. With Jolt, they don’t need any SNARK expertise—just press a button to generate a Jolt proof from their existing code.

However, even with Jolt’s many advances, generating proofs of moderate complexity (e.g., a single standard CPU core performing operations for one second) still requires substantial computational power. To produce complex proofs within reasonable timeframes, multiple GPUs are needed. LayerZero has ported Jolt’s prover to CUDA and launched Zero: it combines Jolt’s highly parallelized underlying algorithms with GPU hardware to achieve higher scalability.

LayerZero is committed to bringing Jolt to production-grade GPU proofs, including collaborating on GPU-friendly versions of the Jolt algorithms, which are critical for improving zkVM and proof scalability.

Open-source R&D

Jolt itself is open-source, so anyone can use or build upon its innovative technology. Open-sourcing is the ultimate multiplier: sharing results publicly allows more ecosystem participants to use, reuse, stress-test, audit, fix, improve, and further innovate on top of it.

Investing in open-source projects may seem unusual for a venture capital firm, but the modern R&D structure—where most development occurs either within corporate labs (past or present) or academia—makes this approach logical. Our goal in establishing the a16z crypto research institute is to create an industry research lab and engineering team that bridges academic theory and industry practice. As a VC, we can also fund projects that other institutions cannot—especially in reverse investment scenarios.

Supporting the reverse design approach for SNARKs is particularly important for Jolt because it represents a major paradigm shift—an evolution that has taken years to develop.

The story of innovation often involves a shift in architecture

To understand the major change in SNARK design that Jolt embodies, we must trace back over two thousand years: the Greeks pioneered formalized mathematical proof systems, which were later expanded upon by scholars in the Middle East, Asia, and elsewhere.

These early proofs—step-by-step logical deductions—were recorded in formal language or formulas so that anyone could verify them. For example, a mathematician could write a proof in a “book,” and another mathematician could read it word-by-word to verify its correctness. This traditional static, written proof concept is the essence of the NP class in the famous “P vs. NP” complexity problem.

It’s important to note that this traditional proof method is sequential and requires turn-taking: it is static, not interactive.

Fast forward to 1985*, when Shafi Goldwasser, Silvio Micali, and Charles Rackoff introduced the concept of interactive proofs (“IP”).[*Their paper was actually written earlier but was rejected multiple times before acceptance.] The core idea of interactive proofs is that, for example, if two mathematicians communicate, they don’t need to wait for one to write down a proof and then persuade the other. Instead, they can ask questions in real-time; in other words, interactively explore the proof’s validity.

The tremendous power of these interactive proofs—compared to the traditional static proofs from ancient Greece—was only fully appreciated five years later, in 1990. Carsten Lund, Lance Fortnow, Howard Karloff, and Noam Nisan introduced sum-check protocols: algebraic methods for interactive proof systems. Coupled with subsequent work by Adi Shamir, this quickly led to the foundational “IP=PSPACE” result—a technical statement that roughly captures:

If the prover and verifier can interact—challenging and responding as in traditional proof systems (assuming a lying prover cannot “catch” the verifier with unanswerable challenges)—then we can verify more complex statements quickly compared to static, written proofs from ancient Greece.

In other words: the interactive property grants us significant advantages in proof systems. The sum-check protocol is central to turning this advantage into efficient verification—it allows the verifier to confirm claimed results without reconstructing the entire computation.

A few years later, Joe Kilian proposed constructing succinct zero-knowledge proofs from probabilistically checkable proofs (PCP). In PCP proof systems, the prover (imagine a Greek mathematician, but now a computer) writes a proof in a “book” with high redundancy. Notably, this redundancy allows the verifier to read only a few randomly chosen parts—say, three “words”—and with high confidence determine the proof’s validity.

However, PCP proofs are very long, even though verification is cheap.

Kilian showed how to combine PCPs with cryptography, enabling the prover to “commit” to the entire long proof and then reveal only a few parts with cryptographic authentication. The final proof in Kilian’s protocol is essentially just these few parts (plus cryptographic data)—but enough for the verifier to be convinced that the entire proof is valid.

Initially, these proofs were interactive. Later, Micali demonstrated how to apply the Fiat-Shamir transform to convert Kilian’s PCP-based interactive proof into a non-interactive proof. In short, the Fiat-Shamir transform “eliminates” the verifier’s random challenges, allowing the prover to generate challenges themselves and produce a single, complete proof.

The lasting impact of legacy architectures

Looking at the history and evolution of proof systems, we see a progression from static to interactive, then to probabilistic and non-interactive (PCP), back to interactive (Kilian), and finally back to non-interactive (Micali). SNARKs appear at the end of this evolution: by applying the Fiat-Shamir transform to Kilian’s interactive proof, Micali obtained what we now call the first SNARK construction.

But early PCP-based SNARKs had enormous prover workloads—long computation times—making them difficult to deploy practically.

Yet, SNARK design has followed the same paradigm for decades. Even when the industry tried to move away from PCP-based SNARKs, designers still used related concepts (like “linear PCPs”), which are essentially variants of PCP-inspired heuristics. While these methods produced very short proofs, they did not necessarily lead to the fastest prover.

SNARK designers have never fundamentally revisited their roots—namely, the sum-check protocol—to achieve faster, more usable proofs enabled by modern computation.

In fact, to adopt sum-check protocols earlier, one would need to view the evolution of SNARKs from a nonlinear perspective, considering the entire chain: (a) interactive proofs → (b) PCP → © succinct interactive arguments → (d) early SNARKs. The industry experienced the following shifts:

In transitioning from (a) to (b), the main challenge was removing interaction while maintaining proof succinctness—this led to abandoning sum-check protocols (the interactive part).

When moving from (b) to ©, interaction re-emerged… and then, through Fiat-Shamir, was eliminated again, leading from © to (d).

Looking back, all these steps form a linear chain: (a) → (b) → © → (d). SNARK designers effectively skipped the interaction twice—once from (a) to (b), and again from © to (d).

If we want to use Fiat-Shamir to eliminate interaction altogether, we should skip the intermediate step (b)—the probabilistically checkable proof! Skipping this step is the key insight behind Jolt’s approach: directly constructing SNARKs from interactive proofs via sum verification.

Why didn’t more people adopt sum-check protocols earlier? Early SNARK designers may have avoided it because PCPs and SNARKs superficially seem similar—they both aim for succinct verification. Over time, architecture and misconceptions persisted.

For us, investing heavily in the engineering and research of the Jolt zkVM based on sum verification is a contrarian bet—because it runs counter to the decades-long dominant paradigm in SNARKs.

‘Jolt Inside’

Jolt’s SNARK design approach (based on batch evaluation and memory checking mechanisms like Twist + Shout) leverages interactive proofs and sum-check protocols.

Now, years after starting to build Jolt, others are also adopting sum-check methods in their designs. So, what are Jolt’s standout features in today’s zkVM landscape? Jolt maximally exploits the repetitive structure inherent in CPU execution. By observing how the “fetch-decode-execute” abstraction of each CPU core applies to batch evaluation, Jolt achieves unparalleled efficiency with minimal complexity.

In contrast, other zkVMs heavily rely on “precompilation” (similar to ASIC accelerators for specific subroutines) to achieve reasonable performance. Jolt discards these precompilations because they risk repeating the pitfalls of earlier SNARK design approaches: requiring experts to craft specialized SNARKs, which are more prone to bugs and harder for general developers to adopt. Jolt’s focus is on democratizing SNARKs.

Verifying CPU execution correctness is at the core of zkVM value—also a major breakthrough for developer experience—because it allows reuse of existing, optimized general-purpose computing infrastructure. The world’s computational infrastructure is built around CPUs, and Jolt fully leverages the inherent “structure” of CPU execution to maximize simplicity and performance.

From day one, Jolt prioritized usability and production-level performance: developers can verify existing programs directly; even for quick validation, no code modifications are needed. Unlike other solutions that force teams to refactor applications around “precompilation” or special APIs to achieve acceptable performance, Jolt preserves the integrity of original code, making adoption easier, auditing simpler, and iteration cheaper.

More importantly, Jolt is not only faster but also simpler. Other approaches require zkVM designers to specify a circuit for each basic instruction, whereas Jolt does not. In Jolt, each instruction can be specified in about ten lines of Rust code—no circuits needed, just ten lines of code.

What’s next for Jolt?

We are already leading in speed. With further optimizations and features—including recursion and zero-knowledge proofs—especially as we transition from elliptic curve cryptography to lattice cryptography, we expect to achieve another order-of-magnitude speed boost later this year, not to mention post-quantum readiness.

Jolt makes more applications possible. For blockchain, the long-awaited scalability and decentralization become easier to deploy. Zero-knowledge proofs can be summarized and used out-of-the-box, without months or years of cryptographic engineering.

As Jolt evolves further—such as enabling fast, simple zkVMs that run on smartphones and laptops—developers will unlock more use cases in client-side privacy and security. For example, privacy-preserving apps on mobile phones could become easier to maintain and run, with minimal effort.

In the long run, these proof systems will become core components of the world’s digital infrastructure—similar to encryption and digital signatures. This universal cryptographic compression technology—where anyone can send a 50 KB proof instead of gigabytes of data to demonstrate possession of certain attributes—has such powerful potential that it’s hard to predict what applications people will develop. The possibilities are endless.