Translated by: Block unicorn

Introduction

Today, LayerZero released their new chain Zero, which includes several technological advancements—most notably a completely new zero-knowledge proof method that separates transaction execution from verification. All of this is thanks to "Jolt Inside."

What is Jolt? Jolt is an open-source RISC-V zkVM (zero-knowledge virtual machine, or more accurately, a "succinct" virtual machine) that is fast, secure, and easy to use. It represents a new state-of-the-art SNARK design methodology based on three years of R&D by a16z crypto, which we have open-sourced for anyone to use or develop further. However, the birth of Jolt is actually a story that has been brewing for decades.

Why are zkVM and SNARK design so important?

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

This type of virtual machine is often referred to as a "zk" virtual machine, but the more commonly emphasized feature here is succinctness. While "zero-knowledge" is crucial for privacy protection, "succinctness" means that the proofs are short and easy to verify—these are two useful but distinct characteristics that are often conflated. (Jolt already possesses succinctness and will soon achieve zero-knowledge.)

But why is zkVM so important? zkVMs and SNARKs (succinct non-interactive arguments of knowledge) in a broader sense are critical components for various aspects of blockchain scalability, privacy, and security. Such proofs, arguments, and zero-knowledge (collectively referred to as verifiable computation technologies) have countless applications in the crypto industry and beyond.

Due to traditional design architectures and other reasons, the industry has so far taken a relatively complex approach to building zkVMs; further details will be elaborated below. However, Jolt has focused from the beginning on a radically different SNARK design methodology aimed at achieving higher efficiency, usability, and performance.

In short, zkVM is a method to prove that you have executed a computer program correctly. The advantage of zkVM over other SNARKs lies in its developer-friendliness. By leveraging existing computational infrastructure (such as the open-source LLVM compiler ecosystem), developers do not need to use domain-specific languages (DSLs) but can harness the powerful features of SNARKs in the programming language of their choice.

This is quite similar to many areas of modern cryptography—we have standards and built-in libraries for encryption and digital signatures—ordinary developers use these libraries daily without needing to understand the inner workings. Jolt provides developers the same layer of abstraction: just use existing programs and verify them without worrying about the interaction between the two. This is a prerequisite for the widespread adoption of any new type of cryptography.

Developers can focus on practical operations. With Jolt, developers do not need any expertise in SNARKs; they can generate Jolt proofs with just the press of a button, using the code they have already written.

However, even with the advancements made by Jolt, proving any moderately complex proof (for example, operations performed for one second on a single standard CPU core) still requires substantial computational power. To generate complex proofs in a reasonable time frame, you need multiple GPUs. LayerZero has ported the Jolt prover to CUDA, introducing Zero: it combines the highly parallelized algorithms underlying Jolt with the parallel hardware of GPUs, achieving higher levels of scalability. LayerZero is committed to bringing Jolt to production-grade GPU proofs, including a GPU-friendly version of the Jolt algorithm developed in collaboration with us, which is crucial for enhancing the scalability of zkVMs and proofs.

Open-Source R&D

Jolt itself is open-source, allowing anyone to use or build upon its innovative technology. Open-source is the ultimate multiplier: sharing results publicly allows more people in the ecosystem to use, reuse, stress test/audit/fix, improve, and innovate further based on those results.

Venture capital investment in open-source projects may seem unusual, but the structure of modern R&D dictates that much of the development work either occurs within companies—such as past corporate labs or today's foundation labs—or in academia. The purpose of establishing the a16z crypto research organization is to create an industry research lab and engineering team that connects academic theory with industrial practice. As a venture capital firm, we can fund projects that other institutions cannot…especially in cases of reverse investment.

Supporting a reverse engineering approach for SNARKs is particularly important for Jolt because it represents a significant "paradigm shift" away from traditional design methodologies. This design evolution has taken years.

Stories of Innovation are Often About Shifts in Architectural Design

To understand the significant changes Jolt has made to SNARK design methodologies, we must trace back over two thousand years: the ancient Greeks pioneered the development of formal mathematical proof systems, which were later extended by scholars in the Middle East, Asia, and other regions.

These early proofs—logical deductions written step by step—were recorded in formal languages or formulas, allowing anyone to verify them. For example, a mathematician might write a proof in a "book," and then another mathematician could read that book word for word to verify it. This traditional notion of static written proofs embodies the famous "P vs. NP" complexity class NP.

It is noteworthy that this traditional proof method is sequential and requires alternation: it is static rather than interactive.

Fast forward to 1985, when Shafi Goldwasser, Silvio Micali, and Charles Rackoff introduced the concept of interactive proofs ("IP"). [*In fact, their papers were submitted a few years earlier but were only accepted after being rejected multiple times.] The core idea of this interactive proof method is that, for example, if two mathematicians are conversing, they do not need to wait for one to write down the proof before convincing the other. Instead, they can ask questions in real time; in other words, they can explore the truth of the proof interactively.

The immense power of this type of interactive proof—relative to the traditional static proofs pioneered by the ancient Greeks—was fully recognized only five years later in 1990. At that time, Carsten Lund, Lance Fortnow, Howard Karloff, and Noam Nisan proposed the sum-check protocol: an algebraic method for interactive proof systems. Combined with Adi Shamir's subsequent work, this swiftly led to the foundational conclusion "IP=PSPACE"—a technical phrase that summarizes the following intuitive statement:

• If the prover and verifier can interact—that is, challenge-response like traditional proof systems** [**assuming a lying prover won't be "caught" by an unanswerable challenge],
• then we can verify more complex statements rapidly compared to the ancient Greeks’ static written proofs.

In other words: the interactive property grants us immense advantages within proof systems. The sum-check is the core that transforms this advantage into efficient verification—it allows the verifier to validate the claimed result without reconstructing the entire computation being proven.

Years later, Joe Kilian proposed constructing succinct zero-knowledge proofs from probabilistic verifiable proofs (PCP). In the proof theory of PCP, the prover (think of them as the ancient Greek mathematicians, but now as computers) writes a common proof in a "book," but the format is highly redundant. Notably, this redundancy allows the verifier to avoid reading the entire book: the verifier only needs to randomly select a fixed number of proof locations—for example, three "words" from the book—to confidently assess whether the entire proof is valid.

However, the problem is that PCP proofs are very long, even though the verification cost is low.

Thus, Kilian demonstrated how to combine PCP with cryptography, allowing the prover to "commit" to completing the "long book," and then only reveal the selected words, along with short cryptographic verification. The final proof in the Kilian protocol consists of just these few words (plus some cryptographic certification data)—but they are sufficient for the verifier to believe that the whole book is valid.

These proofs at that time remained interactive. Subsequently, Micali showed how to convert Kilian’s PCP-based interactive proofs into non-interactive proofs by applying the Fiat-Shamir transformation. In short, the Fiat-Shamir transformation "eliminates" the random challenges for the verifier, enabling the prover to generate challenges themselves and output the entire proof at once.

The Lasting Impact of Legacy Architectures

Looking at the history and evolution of proof systems, we have seen both static and interactive transitions, then probabilistic and non-interactive (PCP), and then back to interactive (see Kilian), before returning to non-interactive (see Micali). SNARK emerged at the tail end of this evolution: by applying the Fiat-Shamir transformation to Kilian’s interactive proof, Micali derived the first construction of what we now refer to as SNARK.

However, in these early PCP-based SNARKs, the prover's workload was immense—computationally time-consuming—making them difficult to deploy in practice.

Nevertheless, the design methodology of SNARK has persisted for decades. Even when the industry has attempted to move away from PCP-based SNARK design methods, designers still utilize related concepts (like "linear PCP," etc.), which are merely variants of the heuristics introduced by PCP. While these methods indeed resulted in very short proofs, they did not yield the fastest proving performance.

SNARK designers have consistently failed to return to their fundamental source—the sum-check protocol—to achieve faster and more user-friendly proving methodologies now made possible by modern computation.

To put it another way: to adopt the sum-check protocol sooner, we need to view the history and evolution of SNARK outlined above in a non-linear fashion. From (a) interactive proofs → (b) PCP → (c) succinct interactive proofs → (d) development of early SNARKs, the industry has undergone the following transformations:

• In the transition from (a) interactive proofs → (b) PCP, the main challenge was how to remove interaction from the proof system while maintaining verification succinctness. This led designers to abandon the sum-check protocol (i.e., the interactive part).
• But when transitioning from (b) PCP to (c) succinct zero-knowledge proofs, interaction re-emerged...
• Ultimately, it was removed again through the Fiat-Shamir transformation, enabling the shift from (c) succinct interactive proofs to (d) early SNARK.
• In hindsight, viewing all these steps linearly from (a) → (b) → (c) → (d), we can clearly see that SNARK designers effectively omitted interaction twice—once from (a) → (b) and once from (c) → (d).
• However, if we intend to use Fiat-Shamir to eliminate interaction...we should directly skip the intermediate step (b), which is probabilistic verifiable proofs!
• Skipping this intermediate (b) step is the key insight behind the Jolt methodology, which constructs SNARKs directly from interactive proofs—straight to sum verification.

Why did not more people turn to sum-check protocol-based design methods sooner? Early SNARK designers may have avoided this because PCP and SNARK appeared superficially similar, as they both implement the concept of succinct verification. As for the ensuing developments, architectures—and misconceptions—may continue to persist.

For us, investing significant engineering and research resources in the sum-check-based zkVM Jolt is a reverse bet, as it runs counter to the dominant paradigms in the SNARK field for decades.

‘Jolt Inside’

Jolt's SNARK design methodology (which itself is based on batch evaluation and memory check mechanisms, such as Twist + Shout) is rooted in interactive proofs and the sum-check protocol.

Now, a few years after we began building Jolt, others have also started to adopt sum-check protocol methods in their designs. So, what are the distinctive features of Jolt in today's zkVM? Jolt maximizes the repeated structures in CPU executions. By observing how the "fetch-decode-execute" abstraction of each CPU core applies to the batch evaluation mechanism, Jolt achieves unparalleled efficiency with minimal complexity.

In contrast, other zkVMs heavily rely on "precompiled" (ASIC-like accelerators for specific subroutines) to achieve reasonable performance. Jolt discards these precompiles because they risk repeating the pitfalls of SNARK design methodologies prior to zkVM: requiring experts to design such dedicated SNARKs makes them more prone to bugs and harder for the broader developer community to use. Jolt's focus is on democratizing SNARK.

Verifying the correctness of CPU execution is precisely the core value of zkVM—and a major breakthrough in developer experience—because it allows for the reuse of existing, fortified general computational infrastructure. The global computational infrastructures are built to support CPUs, and Jolt takes full advantage of the "structures" inherent in CPU execution to maximize succinctness and performance.

From the outset, Jolt prioritizes usability and production-grade performance: developers can directly verify existing programs; even for quick verification, there is no need to modify any code. Jolt does not force teams to refactor applications around "precompiled" or specialized APIs to achieve acceptable performance like other solutions; instead, it maintains the integrity of the original code, making it easier to adopt, audit, and iterates at a lower cost.

More importantly, Jolt is not only faster but also simpler. Other solutions require zkVM designers to specify a circuit for each basic instruction of the virtual machine, whereas Jolt does not: in Jolt, each basic instruction can be specified with about ten lines of Rust code. No circuits, just ten lines of code.

What’s Next for Jolt?

We are already leading in speed. With further optimizations and feature additions, including recursion and zero-knowledge proofs—especially our planned transition from elliptic curve cryptography to lattice cryptography—we will achieve another order of magnitude improvement in speed later this year, let alone the post-quantum era.

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

But as Jolt continues to evolve—such as creating a fast and easy-to-use zero-knowledge proof virtual machine that can run on phones and laptops—developers will unlock更多应用，用于客户端和隐私保护。例如，手机上的隐私保护应用可以从难以维护、几乎无法运行，轻松实现开箱即用。

从长远来看，这些证明系统将成为世界数字基础设施的核心组成部分，类似于加密和数字签名。这种通用的加密压缩技术—任何人只需发送一个50千字节的证明文件，而非全部数据，即可证明自己掌握了满足特定属性的数GB数据—功能如此强大，以至于很难预测人们会用它开发出哪些应用。其可能性无穷无尽。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。