A16z: Key Elements for Builders: 'Jolt Inside'

Author: a16z crypto

Article translation: Block unicorn

Introduction

Today, LayerZero announced the launch of their new chain, Zero, which incorporates 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) that 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 will open-source for anyone to use or further develop. But the story of Jolt’s creation is actually a decades-in-the-making journey.

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 confused. (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 vital components for blockchain scalability, privacy, security, and more. 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; this will be explained in more detail below. However, Jolt from the outset focuses on a fundamentally different SNARK design approach aimed at achieving 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 languages without needing domain-specific languages (DSLs).

This is similar to many modern cryptography practices today—we have standards and built-in libraries for encryption and digital signatures that developers use daily without understanding their internal workings. Jolt provides the same abstraction layer: simply use existing programs and verify them, without worrying about the interaction between the two. This is a necessary condition for popularizing new cryptographic applications.

Developers can focus on practical implementation. 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 a reasonable time, multiple GPUs are needed. LayerZero has ported the Jolt prover to CUDA and launched Zero: it combines Jolt’s highly parallelized algorithms with GPU hardware to achieve higher scalability.

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

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 structure of modern R&D—where most development occurs either within companies (such as past corporate labs or current foundation labs) 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 practical industry applications. 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 many years.

The story of innovation often revolves around shifts in architecture design

To understand the major transformation in SNARK design that Jolt embodies, we must trace back over two millennia: the development of formalized mathematical proof systems initiated by the Greeks, later expanded by scholars in the Middle East, Asia, and elsewhere.

These early proofs—logical deductions written step-by-step—were recorded in formal language or formulas so anyone could verify them. For example, a mathematician could write a proof in a “book,” and another 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 these traditional proofs are sequential and require a step-by-step process: they are static, non-interactive.

Fast forward to 1985*, when Shafi Goldwasser, Silvio Micali, and Charles Rackoff introduced the concept of interactive proofs (“IP”). [*Their paper was actually submitted 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 the sum-check protocol: an algebraic method 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 states:

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

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

A few years later, Joe Kilian proposed constructing succinct zero-knowledge proofs from probabilistically checkable proofs (PCPs). 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 check the proof by randomly sampling only a few locations—say, three “words”—and still be highly confident in its 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 sampled parts with cryptographic authentication. The final proof in Kilian’s protocol is essentially these few words plus cryptographic data—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, Fiat-Shamir “eliminates” the verifier’s random challenges, allowing the prover to generate challenges internally and produce a single, complete proof.

Legacy architecture’s lasting impact

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 constructed what we now call the first SNARK.

But early PCP-based SNARKs had enormous prover workloads—long computation times—making them impractical for deployment.

Yet, the way SNARKs have been designed has persisted for decades. Even when the industry tried to move away from PCP-based SNARKs, designers still relied on related concepts (like “linear PCPs”), which are essentially variants of PCP-inspired techniques. While these methods produce very short proofs, they do not necessarily offer the fastest prover.

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

In fact, to adopt sum-check protocols earlier, we would need to view the entire SNARK history and evolution non-linearly. From (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 designers to abandon sum-check protocols (the interactive part).

When moving from (b) to ©, interaction re-emerged… and finally, Fiat-Shamir transformed © into (d), the early SNARKs.

Looking back, the linear view of (a) → (b) → © → (d) reveals that SNARK designers effectively skipped interaction twice—once from (a) to (b), and again from © to (d).

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

Why haven’t more people adopted sum-check-based designs earlier? Early SNARK designers may not have done so because PCP and SNARKs superficially seem similar—they both aim for succinct verification. Over time, architecture—and misconceptions—may have persisted.

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

‘Jolt Inside’

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

Today, after years of developing Jolt, others are beginning to adopt sum-check protocols in their designs. So, what are Jolt’s key 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 mechanisms, 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 echo the pitfalls of traditional SNARK design before zkVMs: requiring expert design, more prone to bugs, and harder for broad developer adoption. Jolt’s focus is on democratizing SNARKs.

Verifying CPU execution correctness is at the core of zkVM value—and 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 the start, 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 for 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 SNARK designers to specify a circuit for each instruction; Jolt only needs about ten lines of Rust code per instruction. 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 recursive proofs and zero-knowledge proofs—we plan to achieve another order of magnitude in performance later this year, not to mention post-quantum security.

Jolt enables more applications. For blockchain, the long-awaited scalability and decentralization become easier to deploy. Zero-knowledge proof summaries can be ready to use out of the box, without months or years of cryptographic engineering.

As Jolt continues to evolve—such as building fast, simple zkVMs that run on smartphones and laptops—developers will unlock more use cases in client-side privacy and security. Privacy apps on mobile devices could become easier to maintain and deploy, even in resource-constrained environments.

Long-term, 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 all the applications it will enable. The possibilities are endless.