Skip to content

Back to the catalog

Fast post-quantum signature aggregation with lattice SNARKs
a16zcrypto.comarticle

Fast post-quantum signature aggregation with lattice SNARKs

a16z crypto announces Aerie, a lattice-SNARK system that aggregates Falcon-512/1024 signatures into one ~66 KiB proof. On an M4 Max laptop it handles 32,768 signatures in 0.65 s (~50k/s), verifies in 54 ms, and costs ~42 bytes per signature. It benchmarks against Orthus and Ethereum's leanVM hash-based XMSS aggregation, and argues that recursion-free lattice aggregation is simpler than hash-only designs. It also covers Falcon's hardware-wallet and side-channel constraints and why private payments need lattice encryption such as ML-KEM.

TL;DR Aerie aggregates Falcon signatures with lattice SNARKs at ~50k sigs/s on a laptop, and the post argues lattices beat hash-only designs for post-quantum blockchains.
Document

What it is

Aerie is a16z crypto's open-source (a16z/aerie) lattice-SNARK aggregator for Falcon-512 and Falcon-1024 signatures. It targets proof-of-stake chains that need post-quantum signature aggregation, which BLS cannot provide. The authors are Centelles, Dao, Thaler and Badakhshan. The post links a paper.

Numbers the summary lacks

  • Proof size: about 66 KiB, regardless of batch. That covers 32,768 Falcon-512 signatures or 16,384 Falcon-1024 signatures.
  • Salts are the hidden cost: Falcon's verifier hashes the message plus a 40-byte salt, so the aggregate must ship every salt. At 32,768 signatures that is about 1.3 MB, versus the 66 KiB proof. The ~42 bytes/signature figure includes the salts. Falcon-512 signatures are 666 bytes and Falcon-1024 signatures are 1,280 bytes.
  • Algorand's deterministic Falcon could drop the salts entirely and ship just the proof, with small changes to Aerie's salt and signature-encoding handling.
  • Single-core prover cost: about 8x standard Falcon verification time and 1.4x signing time.
  • Versus Orthus (fastest prior Falcon aggregation, same AVX-512 server, one core): proves 1.5x faster, verifies 38x faster, proofs 1.7x smaller.
  • Versus PSE's LaBRADOR-based Falcon aggregation: about 74 KB for 10,000 signatures, with verification taking seconds.
  • Versus leanVM:
  • XMSS: about 50,800 vs 1,770 signatures/s (29x).
  • Stateless hash-based signatures: leanVM aggregates about 820/s on the same laptop model, roughly 60x slower than Aerie.
  • The leanVM benchmark configuration caps each key at about 127,000 signatures.
  • Each leanVM proof covers only about 900 signatures, so a full slot needs recursive merging.
  • The Lean Consensus team's 2026 target is 1,000 signatures/s.
  • Correctness claim: Aerie proves everything a standard Falcon verifier checks, including canonical signature encoding. The page says prior Falcon aggregation work skipped that check, so its aggregates could accept signatures a standard verifier rejects.

How it works

Two things make it fast:

  1. Akita, a lattice polynomial commitment scheme built with LayerZero Labs, plus sum-check proving techniques from the Lattice Jolt work. These are described as highly parallel and GPU-friendly. The reported numbers use no GPU.
  2. Falcon verification involves almost no hashing. The hash takes only the message and salt, so the verifier computes the hashes itself and the proof covers only the algebraic checks. Hash-based schemes need hundreds of hashes per signature, and proving hashes costs over 100x native.

The result is one proof from a node holding the slot's signatures, with no recursion. Any node holding the same signatures can replace a failed aggregator.

Preconditions and caveats

  • Falcon only: ML-DSA is not supported yet, because its hash depends on the signature. It is planned, along with in-SNARK hashing to remove the salts and hybrid lattice plus elliptic-curve signatures. Those extensions may not reach 50k/s, but the authors expect headroom over 1,000/s.
  • Benchmark conditions: the headline figures are from an Apple M4 Max with no GPU. Comparisons with Orthus and leanVM were run on the same machine.
  • Falcon deployment constraints: signing is complex and was historically hard on hardware wallets. NIST plans to require fixed-point arithmetic in FN-DSA. One implementation signs Falcon-512 in about 11 kB of RAM. Side-channel hardening is still active work. The authors say they do not suggest every chain adopt Falcon.
  • Advocacy: this is the authors' own post and benchmarks. Their argument that recursion-based hash designs are riskier and that lattices are unavoidable for private payments (ML-KEM) is an opinion, and the promised fuller security case is not in this post. They concede no one can rule out new lattice attacks.

What to do

If you are evaluating post-quantum aggregation for a chain, treat the 1.3 MB salt overhead, or the deterministic-Falcon variant, as the real size figure. Check the paper and repo for the canonical-encoding handling and for reproducing the benchmarks.

Organisations named here

  • Aerie
  • Akita
  • Impagliazzo-Rudich
  • Justin Thaler
  • LaBinius
  • LaBRADOR
  • Lattice Jolt
  • Lean Ethereum
  • leanVM
  • Merkle puzzles
  • ML-DSA
  • ML-KEM
  • Orthus

Technologies named here

  • BLS signatures
  • Akita
  • Lattice Jolt
  • XMSS stateful hash-based signatures
  • Orthus
  • SPHINCS- variants light enough for a hardware wallet
  • Prior Falcon aggregation work
  • LaBRADOR-based Falcon aggregation
  • LaBinius
  • ML-DSA
  • ML-KEM
  • Algorand deterministic Falcon
  • FALCON
  • Ethereum
  • Solana
  • Ledger
  • Alpenglow
  • XMSS
  • SPHINCS
  • FN-DSA
  • NIST
  • Algorand

Techniques named here

  • SNARK-based signature aggregation
  • Recursive proof merging
  • Impagliazzo and Rudich result