Author: a16z crypto; Compiler: Block unicorn

Foreword

Today, LayerZero released their new chain Zero, which incorporates several technological advancements - including a new zero-knowledge proof approach that decouples transaction execution from verification. All thanks to "Jolt Inside".

What is Jolt? Jolt is an open source RISC-V zkVM (zero-knowledge virtual machine, or rather a "no-frills" virtual machine) that is fast, secure, and easy to use. It represents a new, state-of-the-art SNARK design approach based on three years of research and development at a16z crypto, and we are making it open source for anyone to use or further develop. But the creation of Jolt is actually a story decades in the making.

Why are zkVM and SNARK design so important?

Before we dive into the evolution of SNARK design, we first need to understand in detail what zkVM is.

This type of virtual machine is often called a "zk" virtual machine, but the more common feature here is simplicity. While “zero-knowledge” is crucial for privacy protection, “brevity” means proofs are short and easy to verify—two useful but different properties that are often conflated. (Jolt already has simplicity and will soon be zero-knowledge as well.)

But why is zkVM so important? zkVM, and more broadly SNARKs (Succinct Non-Interactive Arguments of Knowledge), are important components of blockchain’s scalability, privacy, security and many other aspects. These types of proofs, arguments, and zero-knowledge (collectively known as verifiable computing techniques) have countless applications in the crypto industry and beyond.

Due to traditional design architecture and other reasons, the industry has so far taken a more complex approach to building zkVM; this is explained in more detail below. However, Jolt has focused from the beginning on a radically different approach to SNARK design, aiming for greater efficiency, usability, and performance.

In short, zkVM is a way to prove that you are running a computer program correctly. The advantage of zkVM over other SNARKs is that it is developer-friendly. By leveraging existing computing infrastructure, such as the open source LLVM compiler ecosystem, developers can leverage the power of SNARKs in their programming language of choice without using a domain-specific language (DSL).

This is similar to much of modern cryptography today - we have standard, built-in libraries for encryption and digital signatures - which the average developer uses every day without understanding their inner workings. Jolt provides developers with the same abstractionLayer: Just use an existing program and verify it without worrying about the interaction between the two. This is a necessary condition for the widespread application of any new cryptography.

Developers can focus on practical operations. With Jolt, developers don't need any SNARK expertise and can generate Jolt proofs using computer code they've already written with the push of a button.

However, even with Jolt's many advances, proving any moderately complex proof (such as a single standard CPU core performing an operation for one second) still requires significant computing power. To generate complex proofs in a reasonable amount of time, you need multiple GPUs. LayerZero ported the Jolt prover to CUDA and launched Zero: it combines the highly parallelized algorithms underlying Jolt with the parallel hardware of GPUs, enabling higher-order scalability. LayerZero is committed to pushing Jolt towards production-grade GPU proofs, including working with us to develop a GPU-friendly version of Jolt’s algorithm, which is critical to improving the scalability of zkVM and proofs.

Open source research and development

Jolt itself is open source, so anyone can use or build on its innovative technology. Open source is the ultimate multiplier: sharing results openly allows more people in the ecosystem to use, reuse, stress test/review/fix, improve, and innovate further on top of it.

It may seem unusual for a venture capital firm to invest in open source projects, but the structure of modern R&D means that most development work occurs either within companies—such as corporate labs in the past or foundation labs today—or in academia. Our purpose of establishing the a16z encryption research institution is to create an industrial research laboratory and engineering team that connects academic theory and industrial practice. As a venture capital firm, we are also able to fund projects that others cannot fund...especially in the context of contrarian investing.

The reverse design method that supports SNARK is particularly important to Jolt because it represents a major "paradigm shift" from previous design methods. This design evolution took place over the years.

The story of innovation is often about the transformation of architectural designThe story of change

To understand Jolt 's major changes in SNARK design methods, we must go back more than two thousand years: the ancient Greeks pioneered the development of formal mathematical proof systems, which were later expanded by scholars in the Middle East, Asia, and elsewhere.

These early proofs - logical derivations written out step by step - wererecorded in a formal language or formula so that anyone could verify them. For example, one mathematician could write the proof in a "book" and then another mathematician could verify it by reading the book verbatim. This traditional concept of static written proofs is the embodiment of the famous "P vs. NP" complexity class NP.

It is worth noting that this traditional proof method is sequential and requires taking turns: it is static, not interactive.

ButFast forward to 1985*, Shafi Goldwasser, Silvio Micali, and Charles Rackoff proposed the concept of Interactive Proofs ("IP"). [*In fact, their paper was proposed several years earlier, but it was accepted after many rejections. The core idea of this interactive proof method is that if two mathematicians are communicating, for example, they do not need to wait for one to write down a proof before convincing the other. Instead, they can ask questions in real time; in other words, explore the proof through interaction.

This type of interactive proofThe enormous power of interactive proofs - relative to the traditional static proofs pioneered by the ancient Greeks - was not fully appreciated until 1990, five years later. At that time, Carsten Lund, Lance Fortnow, Howard Karloff, and Noam Nisan proposed thesummation check protocol: an algebraic method for interactive proof systems. Combined with Adi Shamir's subsequent work, this soon led to the foundational conclusion "IP=PSPACE" - a technical way of saying that summarizes the following intuitive statement:

• If the prover and verifier can interact - that is, challenge-response like a traditional proof system** [**

  Assume that a lying prover will not be "caught" by a challenge that he cannot answer),

• ThenWe can quickly verify more complex statementscompared to the traditional, static, written proofs of ancient Greece.

In other words: the interactive property gives us a huge advantage in proof systems. Sum-check is the core of converting this advantage into efficient verification - it allows the verifier to verify the claimed results without reconstructing the entire calculation process to be proved.

A few years later Joe Kilian proposed constructing a concise zero-knowledge argument starting from probabilistic verifiable proofs (PCP). In PCP's proof theory, the prover (think of an ancient Greek mathematician, only now a computer) writes an ordinary proof in a "book", but in a highly redundant format. Remarkably, this redundancy eliminates the need for the verifier to read the entire book: the verifier can judge with high confidence whether the entire proof is valid by simply randomly sampling a fixed number of proof locations—say, three “words” in the book.

The problem, however, is that the PCP proof itself is very long, despite the low verification cost.

Thus, Kilian shows how to combine PCP with cryptography, allowing the prover to "commit" to completing the "long book" and then make public only a few words extracted, along with a short cryptographic certification. The final proof in the Kilian protocol is really just these few words (plus some cryptographic authentication data) - but they are enough to convince the verifier that the entire book is valid.

These proofs were still interactive at the time. Micali then shows how to transform Kilian's interactive PCP-based arguments into non-interactive arguments by applying the Fiat-Shamir transformation. In short, the Fiat-Shamir transformation "eliminates" random challenges for the verifier, enabling the prover to generate its own challenges and output the entire proof in one go.

The lasting impact of legacy architecture

Throughout the history and evolution of proof systems we have gone through the evolution from static to interactive, to probabilistic and non-interactive (PCP), then back to interactive (see Kilian), and finally back to non-interactive (see Micali). SNARKs appeared at the end of this evolution: by applying the Fiat-Shamir transformation to Kilian's interactive argument, Micali arrived at what we now call the first SNARK construction.

But inthese early PCP-based SNARKs, the prover's workload was huge—the computation took too long—making them difficult to deploy in practice.

However, SNARK's design approach has been used for decades. Even as the industry attempts to move away from PCP-based SNARK design methods, designers still use related concepts (such as "linear PCP", etc.) that are really just variations of the PCP heuristic technique. While these methods do lead to extremely short SNARKs for the prover, they do not lead to the fastest SNARKs for the prover.

SNARK designers never returned to their roots—summation verification protocols—to achieve the faster, easier-to-use provers that are now possible with modern computing.

Stepping back: Earlier adoption of sum-checking protocols would require looking at the history and evolution of SNARKs we outlined above in a non-linear way. From the development of (a) interactive proof → (b) PCP → (c) concise interactive argument → (d) early SNARK, the industry has experienced the following changes:

From

(a) Interactive proof → (b) In the transition to PCP, the main challenge is how to remove interaction from the proof system while maintaining the simplicity of verification. This prompted the designers to abandon the sum verification protocol (i.e. the interactive part).

But the interaction reappears when moving from (b) PCP to (c) concise zero-knowledge argument...

Ultimately, this is removed via a Fiat-Shamir transformation, thereby achieving the transition from (c) concise interactive arguments to (d) early SNARKs.

Afterwards

It appears that looking at all these steps linearly from (a) → (b) → (c) → (d), we can clearly see that the SNARK designers actually omitted the interaction twice - once from (a) → (b) and once from (c) → (d).

But if

If we were going to use Fiat-Shamir to eliminate interactions... we should just skip the intermediate step (b), which is the probabilistically verifiable proof!

Skipping this intermediate (b) step is the key insight behind Jolt's method, which builds SNARKs directly from interactive proofs - go straight

Sum verification.

Why haven't more people moved to design methods based on summation verification protocols earlier? Early SNARK designers may not have done this because PCP and SNARK appear superficially similar in that they both implement the concept of succinct verification. As for developments going forward, structures—and misunderstandings—are likely to persist.

For us devoting significant engineering and research resources to a zkVM Jolt based on sum-checking is a contrarian bet because it goes against the paradigm that has dominated the SNARK field for decades.

‘Jolt Inside’

Jolt's SNARK design approach (which itself is based on batch evaluation and memory checking mechanisms such as Twist + Shout) is based on interactive proof and sum verification protocols.

Now, a few years after we started building Jolt, others are beginning to adopt the sum-checking protocol approach in their designs. So, what are the distinguishing features of Jolt in today’s zkVM? Jolt takes maximum advantage of repetitive structures in CPU execution. By observing how the fetch-decode-execute abstraction of each CPU core lends itself to a batch evaluation mechanism, Jolt achieves unparalleled efficiency with minimal complexity.

In contrast, other zkVMs rely heavily on "precompilation" (ASIC-like accelerators for specific subroutines) to achieve reasonable performance. Jolt abandoned these precompilations because they would have gone the way of pre-zkVM SNARK design approaches: since experts were required to design such specialized SNARKs, they were more prone to bugs and harder to use by a wide range of developers. Jolt's focus is on popularizing SNARKs.

Verifying the correctness of CPU execution is a core value of zkVM—and a breakthrough in the developer experience—because it allows the reuse of existing, hardened general-purpose computing infrastructure. The world's computing infrastructure is built to support CPUs, and Jolt takes advantage of the inherent "structure" of CPU execution to maximize simplicity and performance.

Jolt Will be available from the startUsablesafetyWithProduction-level performancePutting it first: developers can directly verify existing programs; even for quick verification, there is no need to modify any code. Rather than forcing teams to refactor applications around "precompiled" or special APIs to achieve acceptable performance, as other approaches do, Jolt keeps the original code intact, making it easier to adopt, easier to audit, and easier to audit. leaf="">, and iteration costs are lower.

More importantly, Jolt is not onlyfaster, but also simpler. While other approaches would require zkVM designers to specify a circuit for each basic instruction of the virtual machine, Jolt does not: in Jolt, each basic instruction can be specified in only about ten lines of Rust code. No circuit required, just ten lines of code.

What’s next for Jolt?

We are already leading the way in speed. As further optimizations and features are added, including recursion and zero-knowledge proofs—notably our planned transition from elliptic curve cryptography to lattice cryptography—we will achieve another order of magnitude increase in speed later this year, not to mention the post-quantum era.

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

But as Jolt develops further - for example, building fast and easy zero-knowledge proof virtual machines that can run on phones and laptops - developers will be able to unlock more use cases on the client side and privacy protection. For example, privacy protection apps on mobile phones can go from being difficult to maintain and barely working to being easy to use right out of the box.

In the long term, these proof systems will become a core component of the world's digital infrastructure, similar to encryption and digital signatures. This general-purpose cryptographic compression technology—where anyone can prove they have gigabytes of data that meets certain properties by simply sending a 50-kilobyte proof file instead of the entire data—is so powerful that it’s hard to predict what applications people will build with it. The possibilities are endless.