a16z Releases Lattice Jolt: 3x Faster Proofs and Quantum-Resistant

Author: a16z crypto

Compiled by: Deep Tide TechFlow

Deep Tide Introduction: zkVM has long been criticized for "slow proofs and large sizes." This time, a16z replaced elliptic curves with lattice cryptography, directly making proofs 3x faster and reducing proof size to under 100KB. This is currently the only post-quantum scheme that can beat traditional elliptic curve schemes in speed, with direct implications for on-chain verification costs and privacy applications.

Today we are officially releasing Lattice Jolt, the latest version of our open-source zkVM (zero-knowledge virtual machine). Jolt was already the fastest and simplest zkVM, and its architecture remains unchanged. But the underlying cryptography has been swapped: from elliptic curves to lattice cryptography. This single change brings three things at once:

• Jolt becomes post-quantum secure.
• Prover and verifier speeds improve by 2-3x.
• Lattice Jolt achieves the shortest proofs among all post-quantum zkVMs: currently under 100 KB, with further compression possible. Proofs need to be posted on-chain and transmitted across networks, so smaller proofs mean lower verification costs.

These features cover all use cases of zkVM. The same prover can handle billions of CPU cycles on a GPU and prove millions of cycles on a phone. In both cases, developers write ordinary programs, without needing to hand-write circuits that require specialized knowledge. This is why we call Jolt a "universal SNARK."

But the bigger story is what Lattice Jolt means for SNARK design and adoption. Currently, almost all post-quantum SNARKs in production are hash-based. Lattice Jolt proves that lattice-based SNARKs can be faster and more compact. Digital signatures are undergoing the same transition: hash-based schemes are the conservative choice, but lattice-based schemes are what the world is deploying at scale. We expect SNARKs to follow the same path, and the second half of this post explains why.

Replacing Elliptic Curves with Lattices

Jolt's previous polynomial commitment scheme was called Dory, and it was the only component in the entire system that relied on elliptic curve cryptography. Lattice Jolt replaces Dory with Akita, a brand-new polynomial commitment scheme based on the Module-SIS lattice assumption. Lattice Jolt is based on this standard, well-studied assumption, targeting full 128-bit security.

Module-SIS and its sibling Module-LWE belong to the same family of assumptions that the world's digital infrastructure is migrating toward. These assumptions underpin not only the digital signature standard ML-DSA but also the key establishment standard ML-KEM, which is already the most widely deployed post-quantum primitive globally.

Akita's development and implementation were led by researchers and engineers at LayerZero, with participation from researchers at Carnegie Mellon University, the University of Southern California, and our engineering and research team at a16z crypto.

Why Lattice Jolt Is Faster

Lattice Jolt is not just post-quantum secure; it is faster than the elliptic curve version it replaces.

The speedup comes mainly from a simple reason. Elliptic curves force Jolt to work over a 256-bit field, while lattice cryptography achieves the same level of security over a 128-bit field. The main work of the Jolt prover is field element multiplication (essentially multiplication of very large numbers), so halving the number size makes each multiplication several times faster.

Jolt with Dory was already fast: our last performance update showed that Jolt could prove about 700,000 RISC-V (RV64IMAC) cycles per second on a laptop, and subsequent optimizations pushed the curve-based Jolt past 1 million cycles per second.

Lattice Jolt can prove over 2 million cycles per second on the same machine.

For most of the past six months, we spent time not only developing Akita and integrating it into Jolt but also rewriting the Jolt codebase from scratch. Jolt already ran reasonably well on GPUs, but this rewrite made GPU implementations easier to build and optimize.

The first result is an Apple Metal implementation, bringing massive acceleration to Apple hardware. (Metal is Apple's framework for running code on the GPUs built into devices like MacBooks and iPhones.)

• GPU-accelerated Lattice Jolt can prove over 10 million RV64IMAC cycles per second on a MacBook.
• Pure CPU Lattice Jolt can prove over 2 million cycles per second on the same machine.
• Even the curve-based Jolt now runs at about 4 million cycles per second on a MacBook with Metal.

In other words, a single release took Jolt on a MacBook from about 1 million cycles per second (curve-based, pure CPU) to over 10 million cycles per second (lattice-based, with Metal).

Putting these numbers in context: four years ago, when we first wrote about SNARK prover overhead, proving a computation was millions of times more expensive than executing it directly. Lattice Jolt brings that overhead down to about 10,000x. This is not the end; there is still room for optimization at both the engineering and protocol levels.

Proof size matters as much as prover speed. At under 100 KB, Lattice Jolt's proofs are already much smaller than other post-quantum zkVMs, whose proofs range from over 200 KB to about 600 KB or more.

Switching to lattices also improved Jolt's already excellent memory footprint: prover space usage dropped from about 300 bytes per cycle to 200 bytes per cycle. This means you can prove millions of RISC-V cycles on a phone.

A companion paper will be released soon, adding zero-knowledge to Lattice Jolt, a property needed for privacy applications.

Why Lattices Over Hashes

For years, the SNARK community's attention (and essentially all production deployments) has been on hash-based SNARKs as the route to post-quantum security.

But there has also been a continuous line of research on lattice SNARKs and lattice commitments, including LaBRADOR, Greyhound, LatticeFold, SuperNeo, and Akita's direct predecessor Hachi. Lattice Jolt builds on this research, bringing the lattice commitment layer into a high-performance zkVM architecture while proving that lattice-based SNARKs are unmatched in speed and compactness.

This should not be surprising. As mentioned, the same pattern has already played out in digital signatures.

Cryptographers have constructed signatures based on many assumptions. Hash-based signatures are often considered the most conservative choice: their security assumptions are simple and old. But the world is largely moving to lattice-based signatures because they are shorter and faster:

• ML-DSA signatures are about a few KB.
• The NIST-standardized hash-based alternative SLH-DSA is several times larger.
• For encryption and key exchange, the situation is even clearer: there is no hash-based option at all (there are proofs that this is impossible), and post-quantum deployment is overwhelmingly lattice-based. ML-KEM (the primary key establishment standard finalized by NIST in 2024) is already deployed by default in mainstream browsers and messaging apps, and used in a large number of TLS connections on the internet.

The analogy between SNARKs and signatures is not superficial. A digital signature is essentially a proof of knowledge of a private key for an authorized message. SNARKs extend this paradigm from a narrow statement to arbitrary computation. So it would be strange if the long-term cryptographic landscape for SNARKs were completely different from that of signatures and encryption.

There is also a misconception worth clarifying: hash-based SNARKs are often said to be a conservative post-quantum choice because "they only rely on hash functions." This is only true if the underlying hash function is non-algebraic.

Today, most hash-based SNARK deployments rely on SNARK-friendly algebraic hash constructions (such as Poseidon) to cheaply prove that hashes are evaluated correctly. This is especially important for recursion (here recursion means proving that you hold a valid SNARK proof). These constructions have more structure than standard hash functions, and their cryptanalysis is still immature.

In short, we do not have confidence in the security of algebraic hash functions. Despite this, they are still widely used in production SNARK systems today. (However, there is a sign of progress: the Ethereum Foundation recently announced it will abandon their use.)

Algebraic hashes are not the only hidden assumption in deployed hash-based SNARKs: many systems have historically used speculative proximity-gap bounds to set concrete security levels, rather than using fully proven bounds. Some of the strongest believed bounds were later shown to be incorrect.

Even avoiding the above speculative hash-based SNARKs, their security targets are often below 128 bits, because full 128-bit security would incur significant performance overhead. Why? Hash-based SNARKs cannot achieve 128-bit security over a 128-bit field, because their soundness error scales as n/|F|, where n is roughly the size of the statement being proven and |F| is the field size. Thus, proving a billion-step statement over a 128-bit field would lose about 30 bits of security, bringing it below 100 bits. In contrast, Lattice Jolt's soundness error scales as log(n)/|F|, preserving almost full 128-bit security over the same field (the small log(n) loss can be recovered through standard techniques).

Ironically, some systems marketed as "conservative" post-quantum choices actually rely simultaneously on algebraic hash functions, speculative proximity-gap bounds, and security targets below 128 bits. So while hash-based SNARKs are an important direction, they are not automatically the low-risk option many assume.

One Jolt, Three Foundations: Curves, Lattices, and Hashes

We have always believed that Jolt should not be tied to a single cryptographic foundation. We should have mature and high-performance SNARKs based on curves, hashes, and lattices. Different assumptions and performance characteristics will suit different scenarios.

But if digital signatures are any guide, lattice-based SNARKs will become the most widely deployed post-quantum choice.

Jolt is in an unusually advantageous position for this transition. The original Jolt design exploited properties of elliptic curves that are particularly useful for commitments, including fast commitment to sparse vectors. Lattice commitments have the same property: committing to a vector is cheap when most entries are zero or small, and Jolt commits almost exclusively to such vectors. This property allowed us to replace Dory with Akita while keeping the rest of Jolt unchanged.

We will build a hash-based version of Jolt. But compared to curve-based and lattice-based Jolt, the hash-based version is less space-efficient, has larger proofs, and comes with various complications. This is because the most promising hash-based SNARKs work over binary fields. This number system is convenient for proving hash evaluations but does not match how CPUs do arithmetic. This mismatch makes proving ordinary CPU multiplications expensive. Even so, the ecosystem should have zkVMs under every major assumption family, just as in digital signatures.

A Universal SNARK

Lattice Jolt satisfies everything builders want from a zkVM at once: post-quantum, transparent, fast, compact, and space-efficient. It brings the lattice SNARK research line from LaBRADOR to Hachi into a production-grade zkVM, without giving up any of the advantages that made Jolt fast in the first place.

Our goal is not only to open-source the most performant zkVM for anyone to use, but also to drastically reduce the need to hand-tune SNARKs for specific applications. This does not require Jolt to be as fast as hand-tuned provers. That would be an impossible goal, akin to requiring a CPU to match a dedicated ASIC on every task. It only requires Jolt to be fast enough to provide an acceptable user experience.

For "small" statements related to client-side proving (where hand-optimized circuits dominate today), the key criterion is generating a proof on a phone in about one second or less. Jolt is already close to achieving this, and there are many acceleration schemes in progress.

The era of lattice SNARKs has arrived.