Building Jolt: A fast, easy-to-use zkVM

Today, a16z crypto research and engineering teams released an initial implementation of Jolt, a new approach to SNARK design that is already up to 2x faster than the state of the art, with more improvements still to come. See this post for a high-level overview to this body of work, as well as this post on SNARK design today and how Jolt breaks the mold; as well as this FAQ for technical specifics about Jolt’s architecture and performance compared to existing zkVMs.

Verifiable computing (colloquially mis-termed ZK) is an incredibly powerful technology, with applications to both blockchain and non-blockchain uses. It enables one computer (the verifier) to delegate computation to another, more powerful computer (the prover) and efficiently verify that the computation was performed correctly. 

In the crypto industry, applications of verifiable computing (specifically SNARKs, or Succinct Non-interactive Arguments of Knowledge) include:

• Layer 2 (L2) blockchains using SNARKs to guarantee the integrity of their state transitions
• Cross-chain bridges using SNARKs to prove deposits/withdrawals on one chain to another
• A “ZK coprocessor” (as defined by Axiom) using SNARKs to prove some off-chain computation over on-chain data that would otherwise be too costly to natively compute in a smart contract

Before and after Jolt | source: a16z crypto

There are many interesting and relatively unexplored non-blockchain use cases as well. For instance, a cloud provider could prove to its client that they correctly ran some computation delegated to its server. A software registry like npm or crates.io could prove that a binary was compiled from specific source code, mitigating the risk of software supply-chain attacks. Or one could prove their tool-assisted speedrun (TAS) of Super Mario Bros. breaks the world record (an idea RISC Zero has also written about). 

Many of these applications involve programs that are far too complex to translate into a circuit DSL (domain-specific language) – imagine, for instance, rewriting an entire compiler or NES emulator in Circom. But if the program compiles into an instruction set supported by a zkVM, no handwritten circuits or DSL translation is necessary: the programmer only needs to write a program in a high-level programming language of their choosing, and the zkVM handles the rest. 

The remaining challenge, then, is the performance of the zkVM prover: it needs to be fast enough to be useful. This is especially important for blockchain use cases, where prover time affects latency, which in turn affects user experience. 

Verifiable computing has long been touted as a potential end-game solution for blockchain scalability, but the technology has faced three barriers to adoption: 

• Performance: Proving the execution of a program introduces several orders of magnitude of overhead compared to native execution.
• Complexity: The complexity of SNARKs has raised concerns about the security of their implementations, which may secure billions of dollars in on-chain assets.
• Usability: Domain-specific languages (DSLs) like Circom require niche expertise inaccessible to most software developers. 

The development of zero-knowledge virtual machines (zkVMs) overcomes this third barrier of usability, because zkVMs allow developers to write programs in high-level programming languages like Rust or Go – without requiring any knowledge of the underlying SNARK that will prove its execution. But the improved usability of zkVMs has come at the cost of significant performance overhead (8 to 9 orders of magnitude) and complex implementations. 

Last year, the Jolt paper introduced a new paradigm for zkVMs that promised to overcome these two challenges – performance overhead and implementation complexity. Jolt emerged from a different theoretical lineage than STARK-based incumbents. By leveraging the Lasso lookup argument and other sumcheck-based techniques, Jolt makes it faster than ever to prove programs, and easier than ever to implement new VM instructions. 

Today, we are excited to release an open source implementation of Jolt for the RV32I (RISC-V 32-bit base integer) instruction set, delivering on the promises of the Jolt paper. 

• It’s fast: our implementation is over 5x faster than RISC Zero and up to 2x faster than the just-released SP1 on preliminary benchmarks. 
• And it’s (relatively) simple: the entire codebase is under 25,000 lines of Rust (less than half as much as comparable zkVMs), with individual CPU instructions implemented in as few as 50 lines of code.
  

Below, we share performance benchmarks that demonstrate Jolt as the new state-of-the-art zkVM. We also provide pointers for developers interested in building applications that use Jolt, as well as a preview of our roadmap for developers interested in contributing to Jolt itself – which we anticipate will get even faster and easier to use in the coming months.

The a16z crypto engineering team was founded on a firm belief in the value of open source. Building Jolt as an open source public good will accelerate the progress of zkVM research, SNARK research more broadly, and the web3 industry as a whole. Building cryptography in closed-source silos, where the code cannot be vetted by the public, often introduces trust to systems that are supposed to be trustless.

Performance

Historically, zkVMs have introduced about 8 orders of magnitude of overhead compared to native execution, making many applications of verifiable computing impossible. The current version of Jolt brings this overhead below 6 orders of magnitude.

And while we’ve already achieved state-of-the-art performance, Jolt’s underlying techniques (based on the sumcheck protocol) have not received as much engineering attention as their more popular counterparts (based on FRI). This suggests that there remains much more “juice to squeeze” from Jolt –– we already have several optimizations on the roadmap, and we expect there to be undiscovered opportunities as well.

Our a16z/zkvm-benchmarks repo benchmarks Jolt, SP1, and RISC Zero on a variety of Rust programs. The relative performance is similar across a broad range of identical RV32 programs. The charts will refer to a program which executes a chain of Sha2 hashes. 

The results of these benchmarks are shown below. Benchmarks were run on an AWS r7g.16xlarge ARM machine with 64 CPU cores and 512 GiB DDR5 RAM. All benchmarks are CPU-only. 

Systems using continuations face a tradeoff between prover time and proof size –- as the proof is split into more “shards” (or “segments”), the prover gets faster (due to parallelization between shards) but with a larger proof size before recursion. Proof size benchmarks are displayed below, where SP1’s results are parameterized by shard count: SP1(shard_count). RISC Zero has a fixed shard size so its shard count implicitly grows with program cycle count. RISC Zero supports recursion (SP1 and Jolt do not yet), but the benchmarks below examine its performance without recursion. We also do not use “precompiles”, so that benchmarks reflect the performance of the core zkVM proving system.

How to build on Jolt

To make Jolt as easy-to-use as possible, the Jolt SDK (built by a16z crypto Engineering Partner Noah Citron) provides simple wrappers around Jolt’s core functionality. All you have to do is:

Add the jolt_sdk::provable attribute to the function you’d like to prove

You’ll then be able use the build_* function to create a prover and verifier

Check out the full Fibonacci example (as well as others) in the repository.

For a deeper dive into the Jolt architecture, the Jolt Book (WIP) serves as living documentation of codebase and design choices not documented in the Jolt paper. In the coming weeks, we’ll be releasing more content geared towards developers interested in building on Jolt or understanding its internals.

What’s next

While Jolt is an important milestone for the zkVM space, we still have a long way to go. Taking a step back, our performance benchmarks indicate that the Jolt prover (on the M3 Max) proves a program as fast as a 100kHz processor – over twice the on-board computing power of the Apollo 11 mission. For a more humbling comparison, that’s about 150x slower than a TI-84 graphing calculator.

To get to calculator-level performance, we have our work cut out for us. We’re continuing to improve Jolt’s performance and usability so that it can provide the best possible developer experience. We’re excited about the following major tasks on the roadmap: 

Binius: Two recent works by Ben Diamond and Jim Posen introduce a multilinear polynomial commitment scheme that is especially useful for systems like Jolt, where committed values are small. Binius, combined with Justin Thaler’s small-field sumcheck algorithm, will significantly improve Jolt’s prover performance (we expect 5-10x). 

More instructions: The Jolt codebase currently implements the RISC-V 32-bit Base Integer instruction set (RV32I), but the Jolt construction is highly flexible. We plan to add support for the RISC-V “M”  extension for integer multiplication and division, as described in the Jolt paper. Further, Jolt can trivially support the 64-bit variant RV64IM. 

Continuations: Currently, Jolt can’t prove arbitrarily long computations due to memory constraints. We’ll use continuations to split a long computation into smaller chunks, each of which would be provable by Jolt. This will reduce memory usage and allow for additional parallelism when proving a single computation. 

Proof recursion: By composing Jolt with another proof system, we further reduce proof size and verifier time. For example, the Jolt verifier can be implemented in Circom to produce constant-sized Groth16 proofs that can be efficiently verified on-chain.

If you’re a Rust developer interested in working on one of these tasks, or you’re an application developer interested in building on top of Jolt, we’d love to chat — reach out to us with questions and feedback: @samrags_ @moodlezoup @eddylazzarin. The more developers who can improve Jolt performance will help the entire blockchain community, from infrastructure through app development.

***

Acknowledgements: The Jolt codebase was developed in close collaboration with the co-authors of the Jolt paper: Arasu Arun (NYU), Srinath Setty (Microsoft Research), and Justin Thaler (a16z crypto, Georgetown University). Special thanks to Arasu Arun for his many core contributions to the Jolt codebase, in addition to theoretical insights. The Jolt SDK, RISC-V tracer, and the zkvm-benchmarks repo were built by Noah Citron (a16z crypto). Thanks also to Tim Sullivan and Sonal Chokshi for editing this post, and Eddy Lazzarin for feedback. 

***

Michael Zhu is a research engineer for a16z crypto, writing open-source code in collaboration with the research team and helping portfolio companies on all things smart contract-related. Prior to joining a16z crypto, Michael led protocol development at 0x Labs, architecting smart contracts to facilitate peer-to-peer trading on multiple blockchains. Before that, he was a student at Stanford University, where he received BS and MS degrees in Computer Science.

Sam Ragsdale is an Investment Engineer for a16z crypto, where supports the investing process, collaborates with portfolio companies to make strong tech decisions, and engages with developer-facing products to understand the future of the space. Before a16z crypto, Sam worked in a similar capacity at Blockchain Capital, and as a Software Engineer at Google optimizing the lifecycle of advertising campaigns.

***

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investment-list/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures/ for additional important information.