Article Author: a16z crypto

Article Translated by:Block unicorn

Preface

Today, LayerZero launched their new chain, Zero, which incorporates several technological advances—including a brand new zero-knowledge proof method that decouples 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 precisely, a “concise” virtual machine) that is fast, secure, and easy to use. It represents a brand new, state-of-the-art SNARK design approach developed over three years by a16z crypto, which we are open-sourcing for anyone to use or further develop. However, the birth of Jolt is actually a story that has been brewing for decades.

Why are zkVM and SNARK design so important?

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

These types of virtual machines are usually referred to as “zk” virtual machines, but the more commonly used feature here is conciseness. While “zero-knowledge” is crucial for privacy protection, “conciseness” means that proofs are short and easy to verify—two useful but distinct features that are often confused. (Jolt currently exhibits conciseness and will soon achieve zero-knowledge.)

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

Due to traditional design architectures and other reasons, the industry has so far approached building zkVMs in a rather complicated manner; this will be elaborated on in more detail below. However, Jolt has focused from the outset 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 have correctly executed a computer program. The advantage of zkVM over other SNARKs is its developer-friendly nature. By leveraging existing computational infrastructure (such as the open-source LLVM compiler ecosystem), developers do not need to use domain-specific languages (DSLs) to harness the power 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 every day without needing to understand how they work internally. Jolt provides developers with the same abstraction layer: simply use existing programs and validate them without worrying about the interaction between the two. This is a prerequisite for any new cryptographic application.

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

However, even with the significant advancements made by Jolt, proving any proof of moderate complexity (for instance, a single standard CPU core executing operations for one second) still requires substantial computational power. To generate complex proofs in a reasonable timeframe, multiple GPUs are required. LayerZero has ported the Jolt prover to CUDA and launched Zero: it combines the highly parallelized algorithms underlying Jolt with the parallel hardware of GPUs, achieving higher-order scalability.

LayerZero is committed to bringing Jolt to production-grade GPU proofs, including developing a GPU-friendly version of the Jolt algorithm in collaboration with us, which is crucial for improving zkVM and proof scalability.

Open-source Research and Development

Jolt is open-source, so anyone can use or build upon its innovative technology. Open-source is the ultimate multipler: sharing outcomes openly enables more people in the ecosystem to use, reuse, stress-test/audit/fix, improve, and innovate further based on this.

Venture capital funding open-source projects may seem unusual, but the structure of modern research and development dictates that most development work either happens in-house—such as in past corporate labs or today’s foundation labs—or occurs in academia. The purpose of establishing the a16z crypto research institution is to create an industry research lab and engineering team that connects academic theory with industrial practice. As a venture capital firm, we are also able to fund projects that other organizations cannot fund... especially in the case of reverse investment.

Supporting the reverse design methodology for SNARKs is especially important for Jolt, as it represents a significant “paradigm shift” that is fundamentally different from traditional design approaches. This design evolution has taken years.

Innovation stories are often about architectural design shifts

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

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

It’s worth noting that this traditional proof method is sequential and requires turn-taking: it is static rather than interactive.

But fast forward to 1985, Shafi Goldwasser, Silvio Micali, and Charles Rackoff proposed the concept of interactive proofs (“IP”). [*In fact, their paper was proposed a few years earlier, but was accepted after being rejected multiple times.] The core idea of this interactive proof method is that, for example, if two mathematicians are communicating, they do not need to wait for one to write down the proof and then convince the other. Instead, they can ask questions in real-time; in other words, they can explore the essence of the proof through interaction.

The immense power of these types of interactive proofs—compared to the traditional static proofs pioneered by the ancient Greeks—was not fully recognized until five years later in 1990, when Carsten Lund, Lance Fortnow, Howard Karloff, and Noam Nisan proposed summation check protocols: algebraic methods for interactive proof systems. Along with Adi Shamir's subsequent work, this quickly led to the foundational conclusion "IP=PSPACE"—a technical phrase that encapsulates the following intuitive statement:

If the prover and verifier can interact—i.e., engage in a challenge-response manner as in traditional proof systems, (assuming a lying prover will not be “caught” by challenges they cannot answer)—then, compared to the ancient Greeks' traditional static written proofs, we can quickly verify more complex statements.

In other words, the interactive property gives us a tremendous advantage in proof systems. And the sum-check is central to turning this advantage into efficient verification—it allows the verifier to validate the claimed results without needing to reconstruct the entire computation process being proven.

A few years later, Joe Kilian proposed building concise zero-knowledge proofs starting from probabilistically checkable proofs (PCP). In the proof theory of PCP, the prover (think of them as an ancient Greek mathematician, except now they are a computer) writes a regular proof in a book, but the format is highly redundant. Notably, this redundancy allows the verifier to avoid reading the entire book: they just need to randomly sample a fixed number of proof locations—such as three "words" in the book—to confidently determine if the entire proof is valid.

However, the issue is that the PCP proofs themselves are lengthy, even though the verification cost is low.

Therefore, Kilian demonstrated how to combine PCP with cryptography, allowing the prover to "commit" to this "long book," then only publicly reveal a few sampled words, along with a brief cryptographic certification. The final proof in Kilian's protocol is essentially 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 were still interactive at that time.Later, Micali showed how to apply the Fiat-Shamir transformation to convert Kilian's PCP-based interactive proof into a non-interactive proof. In short, the Fiat-Shamir transformation "removes" the verifier's random challenges, allowing the prover to generate challenges themselves and output the entire proof in one go.

The Lasting Impact of Legacy Architecture

Looking through the history and evolution of proof systems, we have experienced an evolution from static to interactive, then to probabilistic and non-interactive (PCP), and back to interactive (as seen in Kilian), and finally back to non-interactive (as seen in Micali). SNARKs appeared at the tail end of this evolution: by applying the Fiat-Shamir transformation to Kilian's interactive proof, Micali achieved what we now refer to as the first SNARK construction.

However, in these early PCP-based SNARKs, the workload of the prover was formidable—the computation took too long—making them difficult to deploy in practice.

Nonetheless, the design of SNARKs has retained its approach for decades. Even when the industry attempted to move away from PCP-based SNARK designs, the designers continued to use related concepts (such as “linear PCP,” etc.), which are in fact just variants of PCP heuristic techniques. Although these methods did indeed yield extremely short proofs for SNARKs, they did not lead to the fastest SNARKs for provers.

SNARK designers have never returned to their fundamental source—the sum-check protocol—to obtain the faster, easier-to-use proofs that are now possible with modern computation.

Stepping back, adopting the sum-check protocol earlier would have required a nonlinear examination of the history and evolution of SNARKs outlined above. From (a) Interactive Proofs → (b) PCP → (c) Concise Interactive Proofs → (d) Early SNARK development, the industry has witnessed the following shifts:

In the transition from(a) Interactive Proofs → (b) the shift to PCP, the major challenge was how to remove interaction from the proof system while maintaining the conciseness of verification. This prompted designers to abandon the sum-check protocol (i.e., the interactive part).

However, when transitioning from (b) PCP to (c) Concise Zero-Knowledge Proofs, interaction reappears…and ultimately, it is removed again through the Fiat-Shamir transformation, achieving the transition from (c) Concise Interactive Proofs to (d) Early SNARKs.

In hindsight, viewing all these steps linearly from (a) → (b) → (c) → (d) makes it clear that SNARK designers effectively omitted interaction twice—once from (a) → (b) and again from (c) → (d).

But if we intend to use Fiat-Shamir to eliminate interaction… we should directly skip the intermediate step (b), namely the probabilistically checkable proofs! Skipping this intermediate step (b) is the key insight behind the Jolt method, which builds SNARK directly from interactive proofs—going straight tothe sum-check verification.

Why have more people not shifted earlier to design methods based on the sum-check verification protocol? Early SNARK designers may not have done so because PCP and SNARK appear quite similar on the surface, as both achieve the concept of concise verification. As for subsequent developments, the architecture—and misunderstanding—may persist.

For us, investing substantial engineering and research resources into a sum-check-based zkVM like Jolt is a reverse bet, as it goes against the paradigm that has dominated the SNARK field for decades.

‘Jolt Inside’

The SNARK design methodology of Jolt (which is based on batch evaluation and memory checking mechanisms, such as Twist + Shout) is based on interactive proofs and summation check protocols.

Today, several years after we started building Jolt, others have also begun to adopt the summation check protocol approach in their designs. So, what notable characteristics does Jolt exhibit in today's zkVM? Jolt maximizes the repetitive structure 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 rely heavily on “precompiled” (similar to ASIC accelerators for specific subroutines) to achieve reasonable performance. Jolt rejects these precompilations, as they replicate the pitfalls of SNARK design methods that preceded the emergence of zkVMs: requiring experts to design such specialized SNARKs, they are more prone to bugs and harder for the broader developer community to use. Jolt focuses on making SNARKs accessible.

Verifying the correctness of CPU execution is at the core of zkVM’s value—also a significant breakthrough for developer experience—because it allows for the reuse of existing, enhanced general computation infrastructure. The global computational infrastructure is built to support CPUs, and Jolt exploits the inherent “structure” of CPU execution, maximizing both conciseness and performance.

From the beginning, Jolt has prioritized usability and production-grade performance: developers can directly verify existing programs; even for rapid verification, there’s no need to modify any code. Jolt does not force teams to restructure applications around “precompilation” or special APIs to achieve acceptable performance like other solutions; instead, it maintains the integrity of the original code, making it easier to adopt, easier to audit, and have lower iteration costs.

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

What’s Next for Jolt?

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

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

But with Jolt’s further development—for example, creating a fast, easy-to-run zero-knowledge proof virtual machine for phones and laptops—developers will unlock more use cases in client and privacy protection. For instance, a privacy-preserving application on a phone can become easily usable out of the box, which used to be difficult to maintain and nearly impossible to operate.

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 only needs to send a 50 kilobyte proof instead of all the data to prove they possess several GB of data satisfying specific attributes—provides such powerful functionality that it is hard to predict what applications people will develop with it. The possibilities are endless.

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