Today, LayerZero launched their new chain, Zero, which incorporates several technological advancements—including a novel 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 "simple" virtual machine) that is fast, secure, and easy to use. It represents a new and state-of-the-art SNARK design methodology based on three years of development by a16z crypto, which we have open-sourced for anyone to use or further develop. But 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 what zkVM is. This type of virtual machine is often referred to as a "zk" virtual machine, but the more commonly used characteristic here is simplicity. While "zero knowledge" is crucial for privacy, "simplicity" means proofs that are short and easy to verify—two useful but distinct characteristics that are often confused. (Jolt already possesses simplicity and will soon achieve zero-knowledge proofs.) But why is zkVM so important? zkVM, and more broadly SNARKs (Simple Non-Interactive Knowledge Proofs), are crucial components of blockchain scalability, privacy, and security. These proofs, arguments, and zero-knowledge proofs (collectively known 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 taken a relatively complex approach to building zkVMs; this will be discussed in more detail below. However, Jolt focused from the outset on a radically different SNARK design approach, aiming for greater efficiency, usability, and performance. In short, zkVM is a way to prove that you have correctly run a computer program. zkVM's advantage over other SNARKs lies in its developer-friendliness. By leveraging existing computing infrastructure (such as the open-source LLVM compiler ecosystem), developers can utilize the power of SNARKs in their chosen programming language without needing a domain-specific language (DSL). This is quite similar to many modern cryptography fields today—we have standard, built-in libraries for encryption and digital signatures—which ordinary developers use every day without needing to understand their inner workings. Jolt provides developers with the same layer of abstraction: simply use existing programs and validate them without worrying about the interaction between them. This is essential for the widespread adoption of any new form of cryptography.Developers can focus on practical application. With Jolt, developers don't need any SNARK expertise; they can generate Jolt proofs using their existing computer code with the push of a button. However, even with Jolt's advancements, proving any moderately complex proof (e.g., an operation performed by a single standard CPU core in one second) still requires significant computational power. To generate complex proofs in a reasonable amount of time, multiple GPUs are needed. LayerZero ported the Jolt prover to CUDA with Zero: it combines Jolt's underlying highly parallelized algorithm with the parallel hardware of GPUs, achieving even greater scalability. LayerZero is committed to bringing Jolt to production-ready GPU proofs, including collaborating with us to develop GPU-friendly versions of the Jolt algorithm, which is crucial for improving the scalability of zkVM and proofs. Jolt itself is open source, so anyone can use it or build upon its innovative technology. Open source is the ultimate multiplier: publicly sharing results allows more people in the ecosystem to use, reuse, stress-test/audit/fix, improve, and innovate further. Investing in open-source projects by venture capital firms may seem unusual, but the structure of modern R&D dictates that most development work occurs either within companies—such as corporate labs in the past or foundation labs today—or in academia. Our goal in establishing the a16z cryptography research institute was to create an industry research lab and engineering team that connects academic theory with industry practice. As a venture capital firm, we can also fund projects that other institutions cannot…especially in reverse engineering. Supporting the reverse engineering approach to SNARK is particularly important to Jolt because it represents a significant “paradigm shift” from previous design methods. This design evolution has taken many years. The story of innovation is often about a shift in architectural design. To understand the major changes Jolt made to the SNARK design approach, we must go back more than 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 elsewhere. These early proofs—step-by-step logical derivations—were recorded in formal languages or formulas so that anyone could verify them. For example, a mathematician can write a proof in a "book," and then another mathematician can read the book word for word to verify it. This traditional concept of static written proof is a manifestation of the famous "P vs. NP" complexity class NP.It is worth noting that this traditional method of proof is sequential and requires taking turns: it is static, not interactive. Fast forward to 1985, when 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 it was accepted only after being rejected multiple times.] The core idea of this interactive method is that, for example, if two mathematicians are exchanging ideas, they do not need to wait for one to write down a proof before trying to persuade 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 this type of interactive proof—compared to the traditional static proofs pioneered by the ancient Greeks—was not fully recognized until five years later in 1990. At that time, Carsten Lund, Lance Fortnow, Howard Karloff, and Noam Nisan proposed a summation verification protocol: an algebraic method for interactive proof systems. Building on Adi Shamir's subsequent work, this quickly led to the fundamental conclusion that "IP = PSPACE"—a technical statement that encapsulates the intuitive statement: if provers and verifiers can interact—that is, engage in challenge-response as in traditional proof systems (assuming a lying prover won't be "caught" by a challenge they can't answer)—then we can verify more complex statements much faster than the static, written proofs of ancient Greek tradition. In other words, the interactive property gives us a significant advantage in proof systems. The sum-check is the core of translating this advantage into efficient verification—it allows verifiers to verify claimed results without reconstructing the entire computational process to be proven. A few years later, Joe Kilian proposed building concise zero-knowledge proofs based on probabilistic verifiable proofs (PCP). In PCP proof theory, the prover (imagine an ancient Greek mathematician, only now a computer) writes a simple proof in a "book," but with highly redundant formatting. It's worth noting that this redundancy means the verifier doesn't need to read the entire book: the verifier only needs to randomly select a fixed number of proof locations—such as three "words" from the book—to determine the validity of the entire proof with high confidence. However, the problem lies in the length of the PCP proof itself, despite its low verification cost. Therefore, Kilian demonstrates how to combine PCP with cryptography, allowing the prover to "commit" to completing this "long book," then only revealing a few selected words along with a brief cryptographic acknowledgment.The final proof in the Kilian protocol was essentially just these few words (plus some cryptographic authentication data)—but enough to convince the verifier that the entire book was valid. These proofs were still interactive at the time. Micali later demonstrated how to transform Kilian's PCP-based interactive proofs into non-interactive proofs by applying the Fiat-Shamir transformation. In short, the Fiat-Shamir transformation "eliminates" the verifier's random challenge, allowing the prover to generate the challenge themselves and output the entire proof at once. Looking at the history and evolution of proof systems, we've seen a progression from static to interactive, then 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 proofs, Micali obtained what we now call the first SNARK construction. However, in these early PCP-based SNARKs, the prover's workload was enormous—computationally time-consuming—making them impractical. Yet, the design of SNARKs has remained largely unchanged for decades. Even as the industry attempts to move away from PCP-based SNARK design methodologies, designers still use related concepts (such as "linear PCP"), which are essentially variations of PCP heuristics. While these methods do produce SNARKs with extremely short proofs, they do not produce the fastest SNARKs for provers. SNARK designers have consistently failed to return to their fundamental source—the checksum protocol—to achieve the faster, more user-friendly provers that are now achievable with modern computing. To take a step back: to adopt checksum protocols earlier requires examining the history and evolution of SNARKs outlined above in a non-linear way. The industry underwent the following shift in the development of (a) interactive proofs → (b) PCP → (c) concise interactive proofs → (d) early SNARKs: In the transition from (a) interactive proofs → (b) PCP, the main challenge was how to remove interaction from the proof system while maintaining verification conciseness. This led designers to abandon checksum protocols (i.e., the interactive part). However, when transitioning from (b) PCP to (c) concise zero-knowledge argument, interaction reappears… Ultimately, it is removed through the Fiat-Shamir transformation, thus achieving the transition from (c) concise interactive argument to (d) early SNARK. In hindsight, examining all these steps linearly from (a) → (b) → (c) → (d), we can clearly see that the SNARK designers actually omitted interaction twice—once from (a) → (b) and again from (c) → (d).But if we're going to use Fiat-Shamir to eliminate interactions… we should skip the intermediate step (b), the probabilistically verifiable proof! Skipping this intermediate step (b) is the key insight behind the Jolt approach, which builds SNARKs directly from interactive proofs—going straight to summation verification. Why didn't more people turn to a design approach based on summation verification protocols earlier? Early SNARK designers probably didn't because PCP and SNARKs seem superficially similar, as they both implement the concept of concise verification. As for subsequent developments, the architecture—and the misunderstandings—may persist. For us, investing significant engineering and research resources in the summation verification-based zkVM Jolt was a contrarian bet, as it ran counter to the paradigm that had dominated the SNARK space for decades. Jolt's SNARK design approach (which itself is based on batch evaluation and memory checking mechanisms such as Twist + Shout) is based on interactive proofs and summation verification protocols. Now, a few years after we started building Jolt, others are starting to adopt summation verification protocol approaches in their designs. So, what are the key features of Jolt in today's zkVM? Jolt maximizes the repetitive structures 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 "pre-compiled" implementations (similar to ASIC accelerators for specific subroutines) to achieve reasonable performance. Jolt abandons these pre-compilations because they repeat the mistakes of SNARK design methods prior to zkVM: they are more prone to bugs and harder for developers to use because they require experts to design such specialized SNARKs. Jolt focuses on democratizing SNARKs. Validating the correctness of CPU execution is the core value of zkVM—and a major breakthrough in the developer experience—because it allows the reuse of existing, enhanced general-purpose computing infrastructure. Global computing infrastructure is built to support CPUs, and Jolt fully leverages the inherent "structure" of CPU execution, maximizing simplicity and performance. Jolt prioritized usability and production-grade performance from the outset: developers can directly validate existing applications; even for rapid validation, no code modifications are required.Unlike other solutions that force teams to refactor applications around "pre-compiled" or special APIs to achieve acceptable performance, Jolt maintains the integrity of the original code, making it easier to adopt, audit, and iterate at a lower cost. More importantly, Jolt is not only faster but also simpler. Other solutions require zkVM designers to specify a circuit for every basic instruction of the virtual machine, while Jolt does not: in Jolt, each basic instruction can be specified in about ten lines of Rust code. No circuits, just ten lines of code. We are already leading in speed. With further optimizations and the addition of features, including recursion and zero-knowledge proofs—especially our planned shift from elliptic curve cryptography to lattice cryptography—we will achieve another order of magnitude speed improvement later this year, not to mention the post-quantum era. Jolt enables more applications. For blockchain, the long-awaited scalability and decentralization will become much easier to deploy. Zero-knowledge proof aggregation is available out of the box, eliminating the need for months or even years of cryptographic engineering. But as Jolt further develops—for example, by creating fast and easy-to-use zero-knowledge proof virtual machines that can run on phones and laptops—developers will be able to unlock even more use cases in terms of client-side and privacy protection. For instance, privacy-preserving apps on phones could easily go from being difficult to maintain and nearly impossible to run out of the box. In the long run, these proof systems will become a core component of the world's digital infrastructure, similar to encryption and digital signatures. This universal cryptographic compression technology—where anyone can prove they possess gigabytes of data satisfying specific properties by sending a 50-kilobyte proof file, rather than the entire data—is so powerful that it's difficult to predict what applications people will develop with it. The possibilities are endless. [Block unicorn]