a16z Launches Lattice Jolt: 3x Faster Proofs with Post-Quantum Security

Author: a16z crypto

Compiled by Deep潮 TechFlow

Shenchao Summary: zkVM has long been criticized for being too slow and producing overly large proofs. a16z has now replaced elliptic curves with lattice-based cryptography, tripling proof generation speed and reducing proof size to under 100 KB. This is currently the only post-quantum solution that outperforms traditional elliptic curve schemes in speed, directly impacting on-chain verification costs and privacy applications.

Today, we are officially launching Lattice Jolt, the latest version of our open-source zkVM (zero-knowledge virtual machine). Jolt was already the fastest and simplest zkVM available, and its architecture remains unchanged. However, the underlying cryptography has been replaced: from elliptic curves to lattice-based cryptography. This single change brings three key benefits:

• Jolt becomes post-quantum secure.
• The speed of prover and verifier has increased by 2-3 times.
• Lattice Jolt has the shortest proofs among all post-quantum zkVMs: currently under 100 KB, with further compression possible. Since proofs must be posted on-chain and transmitted across networks, smaller proofs reduce verification costs.

These features cover all use cases of zkVM. The same prover can handle billions of CPU cycles on a GPU and millions of cycles on a smartphone. In both cases, developers write ordinary programs without needing to manually design circuits requiring specialized expertise. This is why we say Jolt is a “universal SNARK.”

But the bigger story is the significance of Lattice Jolt for SNARK design and adoption. Currently, nearly all post-quantum SNARKs in production are hash-based. Lattice Jolt demonstrates that lattice-based SNARKs can be faster and more compact. A similar shift is underway in digital signatures: hash-based schemes are the conservative choice, but lattice-based schemes are what the world is increasingly deploying at scale. We expect SNARKs to follow the same path—this blog’s second half explains why.

Jolt's previous polynomial commitment scheme was Dory, the only component in the system relying on elliptic curve cryptography. Lattice Jolt replaces Dory with Akita, a novel polynomial commitment scheme based on the Module-SIS lattice assumption. Lattice Jolt achieves full 128-bit security based on this standard and well-studied assumption.

Module-SIS and its counterpart Module-LWE belong to the same family of assumptions, and the world's digital infrastructure is transitioning toward this family. 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.

The development and implementation of Akita are led by researchers and engineers from LayerZero, in collaboration with researchers from Carnegie Mellon University and the University of Southern California, as well as our engineering and research team at a16z crypto.

Lattice Jolt is not only post-quantum secure—it's also faster than the elliptic curve version it replaces.

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

Jolt with Dory is already fast: our last performance update showed Jolt achieving 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’ve not only been developing Akita and integrating it into Jolt, but also completely rewriting the Jolt codebase. While Jolt previously performed well on GPUs, this rewrite makes the GPU implementation easier to build and optimize.

The first achievement is the Apple Metal implementation, which delivers significant acceleration on Apple hardware. (Metal is Apple’s framework for executing code on the GPU built into devices like MacBook and iPhone.)

• GPU-accelerated Lattice Jolt can prove over 10 million RV64IMAC cycles per second on a MacBook.
• A pure CPU Lattice Jolt can prove over 2 million cycles per second on the same machine.
• Even the curved version of Jolt now runs at about 4 million cycles per second on MacBooks with Metal.

In other words, a single release increased Jolt on MacBook from approximately 1 million cycles per second (curve version, CPU-only) to over 10 million cycles per second (grid version, with Metal).

Put 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 running it directly. Lattice Jolt has reduced this overhead to about ten thousand times. This is not the end—the potential for optimization at both the engineering and protocol levels still remains.

Proof size and prover speed are equally important. At under 100 KB, Lattice Jolt’s proofs are significantly smaller than those of other post-quantum zkVMs, which range from over 200 KB to around 600 KB or more.

After switching to Grumpkin, Jolt’s already excellent memory usage has improved further: the prover’s space usage has decreased from approximately 300 bytes per cycle to 200 bytes. This means you can prove millions of RISC-V cycles on a smartphone.

A companion paper will soon be released, adding zero-knowledge capabilities to Lattice Jolt—a feature essential for privacy applications.

For years, the SNARK community’s attention—and virtually all production deployments—have focused on hash-based SNARKs as a pathway to post-quantum security.

However, there has consistently been a line of research on lattice SNARKs and lattice commitments, encompassing LaBRADOR, Greyhound, LatticeFold, SuperNeo, and Hachi—the direct precursor to Akita. Lattice Jolt builds on this research by introducing a lattice commitment layer into high-performance zkVM architectures, while demonstrating that lattice-based SNARKs are unmatched in speed and compactness.

This shouldn’t be surprising. As mentioned earlier, the same pattern has already occurred with digital signatures.

Cryptography has seen many signature schemes built on various assumptions. Hash-based signatures are often considered the most conservative choice, as their security assumptions are simple and well-established. However, the world is increasingly moving toward lattice-based signatures, as they are shorter and faster:

• ML-DSA signatures are approximately several KB.
• The NIST-standardized hash-based signature alternative, SLH-DSA, is significantly larger.
• For encryption and key exchange, the situation is clearer: there is no viable hash-based scheme available (it has been proven impossible), and post-quantum deployment is overwhelmingly based on lattices. ML-KEM (the primary key establishment standard designated by NIST in 2024) is already natively deployed in mainstream browsers and messaging apps, and is widely used in TLS connections across the web.

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 any computation. Therefore, it would be strange if the long-term cryptographic landscape of SNARKs were fundamentally different from that of signatures and encryption.

There is also a misconception worth clarifying: Hash SNARKs are often described as a conservative post-quantum choice because “they rely only 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 efficiently prove that hashes have been correctly evaluated. This is especially important for recursion—where recursion refers to proving that you hold a valid SNARK proof. These constructions have more structure than standard hash functions, and their cryptographic analysis is still immature.

In short, we lack confidence in the security of algebraic hash functions. Nevertheless, they are still widely used in production-grade SNARK systems. (However, there is a promising sign: the Ethereum Foundation recently announced it will be abandoning their use.)

Algebraic hashing is not the only hidden assumption in deployed hash-based SNARKs: many systems have historically used speculative proximity-gap bounds to establish specific security levels, rather than fully proven bounds. Some of the strongest of these bounds were later found to be incorrect.

Even avoiding the aforementioned hash-based SNARKs, their security targets are typically below 128 bits, as full 128-bit security incurs 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 approximately the size of the statement being proven and |F| is the field size. Thus, proving a statement of one billion steps over a 128-bit field results in roughly a 30-bit security loss, bringing it below 100 bits. In contrast, Lattice Jolt’s soundness error scales as log(n)/|F|, preserving nearly full 128-bit security over the same field (the minor log(n) loss can be recovered using standard techniques).

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

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

However, when measured by digital signature usage, lattice-based SNARKs will become the most widely deployed post-quantum option.

Jolt is uniquely positioned to benefit from this transition. The original Jolt design leverages properties of elliptic curve commitments that are especially useful for sparse vectors, enabling fast commitments. Lattice commitments share the same property: the cost of committing to a vector is low when most of its entries are zero or small, and Jolt commits almost exclusively to such vectors. This property allows us to replace Dory with Akita while keeping the rest of Jolt unchanged.

We will build a hash-based version of Jolt. However, compared to curve-based and lattice-based versions of Jolt, the hash-based version is less space-efficient, produces larger proofs, and faces various complexity issues. This is because the most promising hash-based SNARK work operates over binary fields. Such a number system facilitates proving hash evaluations but does not align with how CPUs perform arithmetic. This mismatch makes proving ordinary CPU multiplication expensive. Nevertheless, the ecosystem should support a zkVM under each major assumption family, just as it does in the domain of digital signatures.

Lattice Jolt fulfills all builders' needs for a zkVM: post-quantum, transparent, fast, compact, and space-efficient. It brings the lattice SNARK research roadmap—from LaBRADOR to Hachi—into a production-grade zkVM without sacrificing any of the advantages that originally made Jolt so fast.

Our goal is not only to open-source the highest-performance zkVM for anyone to use, but also to significantly eliminate the need for hand-tuning 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 demanding that a CPU match the performance of a dedicated ASIC on every task. It only requires Jolt to be fast enough to deliver an acceptable user experience.

For the "small" statements related to client proofs—where hand-optimized circuits currently dominate these scenarios—the key criterion is generating proofs in under one second on a mobile device. Jolt is already close to achieving this, and numerous acceleration approaches are actively underway.

The era of zk-SNARKs has arrived.

This content is for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors regarding these matters. Any reference to securities or digital assets is for illustrative purposes only and does not constitute investment advice or an offer to provide investment advisory services. Furthermore, this content is not directed at any investor or potential investor and must not be used under any circumstances as a basis for making an investment decision in any fund managed by a16z. (Offers to invest in a16z funds are made solely through such fund’s private placement memorandum, subscription agreement, and other related documents, which should be read in their entirety.) Any investments or portfolio companies mentioned or described do not represent all investments made by a16z-managed vehicles, and no assurance is given that these investments will be profitable or that future investments 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 permitted a16z to publicly disclose, and unpublicized investments in listed digital assets) is available at https://a16z.com/investments/.

The charts provided in this document are for reference only and should not be used as the basis for any investment decision. Past performance is not indicative of future results. This content reflects conditions as of the stated date. Any forecasts, estimates, forward-looking statements, goals, outlooks, and/or opinions expressed in these materials are subject to change without notice and may differ from or contradict opinions expressed by others. For additional important information, please see https://a16z.com/disclosures.