Fast post-quantum signature aggregation with lattice SNARKs

Most major blockchains besides Bitcoin run on proof of stake, where validators vote on each block by signing it. Signature aggregation is what makes large validator sets practical. Ethereum uses BLS signatures, whose algebraic structure lets it combine tens of thousands of validator signatures every slot into a single group element. Solana, where validator votes have made up about three-quarters of all transactions, is adopting BLS aggregation too, as part of its Alpenglow upgrade.

But as useful as BLS is, it is not post-quantum — and in fact, no known post-quantum signature scheme aggregates this way. Post-quantum signatures are also 10 to 100 times larger than today’s elliptic-curve signatures, so without aggregation these signatures will bloat blocks — limiting throughput and raising the cost of running a node. This matters as blockchains carry a growing share of the world’s payments, from stablecoin transfers to payments made by AI agents.

SNARKs (Succinct Non-interactive Arguments of Knowledge) fix these issues: The “aggregate signature” becomes a single succinct proof that every signature in the batch verifies. The prevailing SNARK-based approach, central to Ethereum’s roadmap, pairs hash-based signatures with hash-based SNARKs. But this approach is slow because hash-based signatures are expensive to prove: A single laptop can’t keep up with a full slot of signatures, which is one reason Ethereum’s design splits the work across many provers and recursively merges their proofs.

That’s why today we’re releasing Aerie, which takes the opposite approach by aggregating lattice-based signatures using lattice-based SNARKs. Aerie supports Falcon, a lattice-based signature scheme that NIST has selected for standardization, in both its Falcon-512 and Falcon-1024 variants.

Aerie numbers at a glance

Aerie is fast enough that a single laptop can aggregate roughly an Ethereum slot’s worth of signatures on its own:

• Fast to prove: On an Apple M4 Max laptop, without GPU acceleration, Aerie aggregates 32,768 Falcon-512 signatures in 0.65 seconds, or over 50,000 per second. For comparison, the Lean Consensus team’s 2026 plan targets 1,000 signatures per second.
• Compact in size: About 42 bytes per signature, roughly 16x smaller than Falcon-512 signatures and about 30x smaller than Falcon-1024 signatures.
• Fast to verify: Verifying the proof takes 54 milliseconds on one core, 10x faster than checking the signatures one by one.

A simpler design space

Aerie’s speed also makes a simpler aggregation design possible.

In Ethereum’s current plan, each proof from leanVM (the zkVM being developed as part of Lean Ethereum to aggregate hash-based signatures) covers only about 900 signatures. Covering a full slot therefore takes rounds of recursive merging, and each round can’t start until the previous round’s proofs arrive.

Recursion also adds risk: It is intricate and bug-prone, and each recursive step proves statements about the very hash function used to make the proofs non-interactive. So the security of the resulting proofs can’t be established even in the random oracle model.

With Aerie, a node that has collected a slot’s signatures produces one proof directly, with no intermediate proofs and no recursion. This approach:

• leaves more time in each slot for collecting votes and propagating the block;
• opens aggregation to more participants; and
• simplifies recovery: If an aggregator fails, any node holding the same signatures can produce a replacement proof.

What makes Aerie fast?

Two things, both rooted in lattices.

The first is Akita (the lattice-based polynomial commitment scheme we built with LayerZero Labs), together with the sum-check-based proving techniques we developed on the road to Lattice Jolt. These techniques are highly parallel and well suited to GPUs, so Aerie has plenty of room to get even faster.

The second reason Aerie is fast is the relative lack of hashing in lattice signature verification. Hash-based signatures are verified by evaluating hundreds of hashes per signature. Aggregating them means proving all of those hash evaluations — and hashing is expensive to prove, typically adding over 100x overhead relative to computing the hash natively.

Lattice signatures are verified differently. The core checks are algebraic, and hashing plays only a small role: a handful of hash evaluations per signature, not hundreds.

Why Falcon signatures?

Falcon takes the lack of hashing especially far. It’s a hash-and-sign scheme whose hash takes only the message and a salt as input. So if the aggregate includes each signature’s salt, the verifier can compute every hash itself, and the proof needs to cover only the algebraic checks. That’s a big part of Aerie’s speed, and why we started with Falcon.

Falcon is also compact: Falcon-1024 reaches NIST’s highest security level with signatures about half the size of ML-DSA-44’s, the lowest-security ML-DSA parameter set.

We’re not suggesting every blockchain adopt Falcon. Its signing algorithm is complex, and it has historically been hard to fit on hardware wallets, relying on floating-point arithmetic and tens of kilobytes of working memory. Side-channel hardening is still an active area of work.

But these drawbacks are being addressed rapidly. Recent research has shown how to implement Falcon signing with fixed-point arithmetic instead of floating point, and NIST now plans to require this approach in the FN-DSA standard. A new implementation also cuts Falcon-512 signing to about 11 kB of RAM, small enough for the secure elements in hardware wallets. For both reasons, Falcon is far easier to deploy than it was even a year ago.

Hardware wallets are a challenge for stateless hash-based signatures too: The SPHINCS- variants light enough for a hardware wallet take from 47 seconds to over six minutes to sign on a Ledger secure element.

For chains that weigh Falcon’s trade-offs and choose it — as Solana is exploring and Algorand has deployed — Aerie offers a fast path to aggregation.

We’re also working on extensions that require proving some hashing: supporting ML-DSA, whose hash depends on the signature itself; and removing Falcon’s salts from the aggregate by proving its hash inside the SNARK. Recent advances like LaBinius offer paths to proving those few hashes efficiently. And we’re extending Aerie to hybrid signatures that pair a lattice signature with an elliptic-curve-based one, an important form of defense-in-depth. These extensions may not reach 50,000 signatures per second, but we still expect plenty of headroom over the 1,000 per second Ethereum has targeted.

The security case for lattices

There’s an active debate about lattice versus hash-based cryptography in blockchain design, sharpened by speculation about what AI might mean for cryptanalysis. We’ll make the full case for embracing lattices in a future post. The short version is this: No one can promise that new attacks won’t be found on lattices, or on any other cryptography. But speculative cryptanalytic risk must be weighed against the clear and present risks built into more complicated systems.

As noted above, Ethereum’s planned hash-only signature aggregation design relies on SNARK recursion, with the coordination overhead, bug surface, and unestablished security that come with that approach.

Hash-only designs also lean on non-standard constructions: Ethereum’s planned consensus and account signatures are custom schemes outside NIST’s standards, with the underlying hash still undecided. This limits support from hardware wallets for individual users, and from the hardware security modules and custody systems that institutions rely on.

Relying exclusively on hash-based cryptography may appear safer, but in designs like these, it can lead to more brittle systems. What matters is the security of the whole system. We believe a full embrace of lattice cryptography makes blockchains more secure and more functional, not less.

The privacy case for lattices

Private payments need encryption, not just signatures and proofs: Recipients must learn about the notes sent to them, viewing keys must grant read access, and encrypted mempools must hide transactions until they’re ordered.

Private payments matter to cypherpunks and financial institutions alike, and Ethereum already plans for them. The Ethereum Foundation’s strawmap, a draft long-term roadmap for its base layer, lists a private L1 with shielded transfers among its five “north stars,” alongside a hash-based post-quantum L1. Those two goals are in tension: Shielded transfers need encryption, and encryption is exactly what hashing alone cannot provide.

Those two goals are in tension: Shielded transfers need encryption, yet encryption is exactly what hashing alone cannot provide.

A classic result of Russell Impagliazzo and Steven Rudich shows that public-key encryption cannot be built from hash functions in a black-box way. The best hash-only alternative, Merkle puzzles, gives honest users only a quadratic advantage over attackers, and this is optimal: No protocol can do better when hashes are modeled as random oracles. Even advocates of hash-only designs acknowledge this.

So a private Ethereum, like any chain that supports private payments, will depend on structured cryptography somewhere in its stack — and in practice, that means lattices. ML-KEM, a lattice scheme, is NIST’s primary post-quantum encryption standard and is already deployed across much of the internet.

Are there workarounds? One proposed solution is to keep encrypted notes off-chain, so fewer ciphertexts sit in public forever. But this doesn’t avoid encryption: The notes must still reach their recipients encrypted, over messaging apps and other channels that are already moving to ML-KEM. And off-chain delivery has trade-offs of its own: a channel that must stay available, can observe metadata, and whose failure can leave recipients unable to find and spend their funds.

For post-quantum blockchains with privacy, then, avoiding lattices in signatures and proofs doesn’t actually remove the dependence on lattices; it just gives up the performance and simplicity lattices offer — the costs, without the benefits. So the real question isn’t whether to rely on lattices, but whether to forgo their benefits for a false sense of security.

More details on Aerie: proof size and performance

An Aerie proof is about 66 KiB, whether it covers 32,768 Falcon-512 signatures or 16,384 Falcon-1024 signatures. That’s on par with the most compact prior lattice-based approach: PSE’s benchmarks of LaBRADOR-based Falcon aggregation report about 74 KB for 10,000 signatures, though verification there takes seconds rather than milliseconds.

Because Aerie’s verifier computes each signature’s hash itself, it also needs each signature’s 40-byte salt. For large batches, the salts dominate: 32,768 of them take up about 1.3 MB, versus 66 KiB for the proof. Even so, the aggregate costs only about 42 bytes per signature, 16 times smaller than Falcon-512 signatures (666 bytes) and nearly 30 times smaller than Falcon-1024 signatures (1,280 bytes).

Some deployments avoid the salt cost entirely. Algorand’s deterministic Falcon makes signing deterministic, which lets it replace the random per-signature salt with a fixed value. Aggregating its signatures would need no salts at all, just the 66 KiB proof, with small changes to how Aerie handles the salt and signature encoding.

Measured against Falcon itself, Aerie’s prover is also cheap: On a single core, proving takes only about 8 times as long as standard Falcon verification of the same signatures, and 1.4 times as long as signing them.

 

Compared with Orthus, the fastest prior Falcon aggregation scheme, Aerie (on one core of the same AVX-512 server):

• proves 1.5x faster,
• verifies 38x faster, and
• produces proofs 1.7x smaller.

Moreover, Aerie proves everything a standard Falcon verifier checks. Prior Falcon aggregation work did not: It left out the check that each signature is canonically encoded, so its aggregates could accept signatures that a standard Falcon verifier would reject.

We also compared Aerie with leanVM, which aggregates XMSS signatures, the stateful hash-based scheme Ethereum plans to use for consensus. On the same machine, Aerie aggregates 29x as many signatures per second (about 50,800 versus 1,770).

Stateful signatures like XMSS work well at the consensus layer, where each validator signs at most one message per slot, so the slot number itself can serve as the signing state. But they pose large risks at the execution layer: A user who signs from two devices, or restores a wallet from a backup, can reuse signing state and thereby let attackers forge signatures under their key. That’s why Ethereum plans a stateless hash-based scheme for account signatures. And stateless hash-based signatures are even costlier to aggregate: In leanVM’s latest published benchmarks, on the same laptop model, it aggregates them at about 820 per second, roughly 60x slower than Aerie. (The benchmarked configuration also caps each key at about 127,000 signatures; configurations that allow far more cost more at key generation but aggregate just as fast.)

***

The code is at a16z/aerie, and the paper is here.

Aerie is joint work by Alberto Centelles (Imperial College London), Quang Dao (Carnegie Mellon University), Justin Thaler (a16z crypto), and Mohammadtaghi Badakhshan (LayerZero Labs).