a16z releases Lattice Jolt: proves speed increased by 3 times, and can resist quantum attacks.

CN
PANews
Follow
1 hour ago

Author: a16z crypto

Translation: Deep Tide TechFlow

Deep Tide Introduction: zkVM has always been criticized for "slow proof and large size." This time, a16z replaced elliptic curves with lattice cryptography, directly increasing proof speed by three times and reducing proof size to below 100KB. This is currently the only post-quantum solution that can surpass traditional elliptic curve schemes in speed, directly affecting the on-chain verification cost and privacy applications.

Today we officially release Lattice Jolt, which is the latest version of our open-source zkVM (Zero Knowledge Virtual Machine). Jolt is already the fastest and simplest zkVM, and its architecture has not changed. However, the underlying cryptography has been replaced: from elliptic curves to lattice cryptography. This change brings three things:

  • Jolt becomes post-quantum secure.
  • Both prover and verifier speeds increase by 2-3 times.
  • Lattice Jolt becomes the shortest proof among all post-quantum zkVMs: currently below 100 KB, and can be further compressed. Smaller proofs lead to lower verification costs when proofs are to be put on-chain and transmitted across networks.

These features cover all use cases of zkVM. The same prover can handle billions of CPU cycles on a GPU and can also prove millions of cycles on a mobile phone. In both cases, developers write ordinary programs without having to handcraft circuits that require specialized knowledge. That's why we say Jolt is the "versatile SNARK."

But the bigger story is the significance of Lattice Jolt for SNARK design and adoption. Almost all commercially deployed post-quantum SNARKs in the market are based on hashes. Lattice Jolt demonstrates that lattice-based SNARKs can be faster and more compact. Digital signatures are undergoing the same transition: hash schemes are a conservative choice, but lattice schemes are the ones being deployed globally at scale. We expect SNARKs to follow this path, and the second half of this blog post will explain why.

Replacing Elliptic Curves with Lattices

The polynomial commitment scheme prior to Jolt was called Dory, which was the only component of the entire system relying on elliptic curve cryptography. Lattice Jolt replaced Dory with Akita, a brand new polynomial commitment scheme based on the Module-SIS lattice assumption. Lattice Jolt is based on this established and well-researched assumption, corresponding to complete 128-bit security.

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

The development and implementation of Akita were led by researchers and engineers from LayerZero, along with researchers from 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 only post-quantum secure; it is also faster than the replaced elliptic curve version.

The acceleration mainly comes from a simple reason. Elliptic curves force Jolt to operate in a 256-bit field, while lattice cryptography can achieve the same level of security in a 128-bit field. The main task of the Jolt prover is domain element multiplication (essentially multiplication of very large numbers), so halving the digital size speeds up each multiplication several times.

With Dory, Jolt was already quite 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 version of Jolt over one million cycles per second.

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

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

The first result is the Apple Metal implementation, which brings tremendous acceleration to Apple hardware. (Metal is Apple's framework designed to execute code on the built-in GPUs of 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 version of Jolt can run at about 4 million cycles per second on a Metal-enabled MacBook now.

In other words, in a single release, Jolt on the MacBook increased from around 1 million cycles per second (curve version, pure CPU) to over 10 million cycles per second (lattice version, with Metal).

Putting these numbers in a broader context: four years ago, when we first wrote about the costs of SNARK provers, proving a computation was millions of times more expensive than running it directly. Lattice Jolt has brought this cost down to about ten thousand times. And there's still room for optimization at both the engineering and protocol layers.

Proof size and prover speed are equally important. At under 100 KB, Lattice Jolt's proofs are already much smaller than those of other post-quantum zkVMs, where proofs range from over 200 KB to about 600 KB or more.

After switching to lattice, Jolt's already excellent memory usage improved further: the prover's space usage decreased from about 300 bytes per cycle to 200 bytes. This means you can prove millions of RISC-V cycles on a mobile phone.

A companion paper will be released soon, which will add zero-knowledge properties to Lattice Jolt, a required attribute for privacy applications.

Why Choose Lattices Instead of Hashes

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

However, there has always been a continuous line of research on lattice SNARKs and lattice commitments, covering LaBRADOR, Greyhound, LatticeFold, SuperNeo, and the direct predecessor to Akita, Hachi. Lattice Jolt builds on this research, introducing lattice commitments into high-performance zkVM architectures while proving that lattice-based SNARKs are unmatched in both speed and compactness.

This should not be surprising. As mentioned before, the same pattern has happened in digital signatures.

Cryptographers have constructed signatures based on many assumptions. Hash signatures are often considered the most conservative choice: their security assumptions are simple and old. However, the world is primarily moving towards lattice signatures because they are shorter and faster:

  • ML-DSA signatures are about a few KB.
  • The NIST standardized hash alternative SLH-DSA is several times larger.
  • For encryption and key exchange, the situation is even clearer: there are fundamentally no hash schemes available (proving that it is impossible), and post-quantum deployments overwhelmingly rely on lattices. ML-KEM (the main key establishment standard determined by NIST in 2024) has been deployed by default in mainstream browsers and communication applications, used in a large number of TLS connections on the web.

The analogy between SNARKs and signatures is not superficial. Digital signatures are essentially a proof of private key knowledge of an authorized message. SNARK extends this paradigm from a narrow statement to arbitrary computations. So if the long-term cryptographic landscape for SNARKs is completely different from that for signatures and encryption, it would be strange.

There is also a misunderstanding worth clarifying: hash SNARKs are often referred to as the conservative post-quantum choice because "they only rely on hash functions." This is only true when the underlying hash function is non-algebraic.

Today, most hash-based SNARK deployments rely on SNARK-friendly algebraic hash constructions (like Poseidon) to prove that the hash was evaluated correctly at low cost. This is particularly 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 cryptanalysis is still immature.

In short, we have no confidence in the security of algebraic hash functions. Nevertheless, they are still widely used in production-level SNARK systems. (However, there has been a notable sign of progress: the Ethereum Foundation recently announced plans to cease using them.)

Algebraic hash is not the only hidden assumption in deployed hash-based SNARKs: many systems have historically used speculative proximity-gap bounds to set specific security levels instead of using fully proven bounds. Some of the strongest bounds have later been proven incorrect.

Even discounting the above speculative hash-based SNARKs, their security objectives are often below 128 bits because full 128-bit security comes with significant performance overhead. Why? Hash-based SNARKs cannot achieve 128-bit security in a 128-bit field because their reliability error scales by n/|F|, where n is roughly the size of the proven statement, and |F| is the field size. Therefore, proving a statement with a billion steps in a 128-bit field loses about 30 bits of security, making it below 100 bits. In contrast, Lattice Jolt's reliability error scales by log(n)/|F|, almost retaining full 128-bit security in the same field (a small log(n) loss can be recovered with standard techniques).

Ironically, some systems marketed as "conservative" post-quantum choices actually rely simultaneously on algebraic hash functions, speculative proximity-gap bounds, and target security levels below 128 bits. Therefore, while hash-based SNARKs are an important direction, they do not automatically become 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 apply to different scenarios.

But if we take digital signatures as a reference, lattice-based SNARKs will become the most widely deployed post-quantum choice.

Jolt is in a uniquely advantageous position in this transition. The original design of Jolt leveraged the particularly useful properties of elliptic curves for commitments, including fast commitments to sparse vectors. Lattice commitments have the same properties: when most entries of a vector are zero or small, the cost of committing to that vector is low, and Jolt almost exclusively committed 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. However, compared to the curve-based and lattice-based versions of Jolt, the hash-based version has poorer space efficiency, larger proofs, and various complexities. This is because the most promising hash-based SNARK works over binary fields. This numeral system facilitates proving hash evaluations but does not match the arithmetic ways of the CPU. This mismatch makes proving ordinary CPU multiplication expensive. Even so, the ecosystem should have zkVMs under each major assumption family, just like in the field of digital signatures.

Universal SNARK

Lattice Jolt simultaneously meets all the builders' needs for zkVM: post-quantum, transparent, fast, compact, and space-efficient. It brings the lattice SNARK research pathway from LaBRADOR to Hachi into production-grade zkVMs while not sacrificing any advantages that made Jolt fast initially.

Our goal is not just to open source the most performant zkVM for anyone to use, but also to significantly eliminate the necessity for manual tuning of SNARKs for specific applications. This does not require Jolt to be as fast as manually tuned provers. That is an impossible goal, like requiring a CPU to match specialized ASICs on every task. It only requires Jolt to be fast enough to provide an acceptable user experience.

For "small" statements related to client proofs (where manually optimized circuits currently dominate in these scenarios), the key criterion is generating proofs on mobile phones in about a second or less. Jolt is already nearing this goal, with many acceleration solutions underway.

The era of lattice SNARKs has arrived.

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

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink