LayerZero Labs’ Aerie research system processed a reported batch of 32, 768 Falcon-512 signatures in a 0.65-second batch-processing benchmark on an Apple M4 Max. That figure measures batch processing, not cryptographic proof generation. The researchers say generating the proof took about 4.3 seconds on one thread.
- Batch benchmark: 32, 768 Falcon-512 signatures processed in 0.65 seconds, using 16 worker threads and no GPU acceleration.
- Proof generation: About 4.3 seconds on one thread, according to the researchers.
- Standard aggregate: 1, 346 KiB, including salts and headers; the proof itself is about 66 KiB.
- Key caveat: A proposed shared-salt version could be smaller, but depends on separate policy and security assumptions.
Announced on Oct. 16, Aerie builds on LayerZero’s Akita proof system. The project announcement names contributors from LayerZero, a16z crypto research, Carnegie Mellon University and Imperial College London. Their work addresses a practical challenge for proof-of-stake networks: checking large batches of validator signatures efficiently while preparing for cryptography that can withstand quantum attacks.
Why aggregate validator signatures?
Validators use digital signatures to attest to network activity. Other participants check those signatures to confirm that messages were authorized by the relevant validators and have not been altered.
Ethereum uses BLS signatures, which can combine many signatures into a compact representation. The Aerie researchers describe BLS as a way to aggregate roughly 32, 000 validator votes. But BLS relies on cryptographic problems that sufficiently powerful quantum computers could attack. The post-quantum signature schemes under consideration do not offer the same native, BLS-style aggregation.
Aerie does not replace the signature scheme or make Falcon signatures natively aggregateable. Instead, it uses a proof system so a verifier can check that a batch of signatures has passed the required checks. The researchers describe the design this way:
“One proof covers the whole batch, with no recursion.”
Aerie aims to produce one proof for the batch, rather than create intermediate proofs and combine them in successive rounds. In the standard design, it also retains a salt value from each signature. The verifier uses those values to calculate associated hashes, while the proof handles the remaining checks. The salts are data used in verification, not signing keys.
What the benchmark measures
On an Apple M4 Max, the researchers report processing 32, 768 Falcon-512 signatures in 0.65 seconds with 16 worker threads. Peak memory use was 2.1 GiB. LayerZero describes the test as running on an Apple laptop without GPU acceleration. That makes it a CPU benchmark on a high-end machine, not evidence of performance on typical validator hardware.
A second workload processed 16, 384 Falcon-1024 signatures in 0.63 seconds, with similar memory requirements. The researchers describe Falcon-1024 as the higher-security option, with larger signatures and more computation than Falcon-512.
The 0.65-second result covers batch processing. The paper separately reports that generating a proof for either workload took roughly 4.3 seconds when restricted to one thread. These are different stages, so the sub-second figure should not be read as the time needed to produce a complete proof.
For the Falcon-512 batch, checking the aggregate reportedly took 54 milliseconds on one core, compared with 519 milliseconds to check the signatures individually. With 16 threads, the respective times were 11.6 milliseconds and 42.9 milliseconds.
These are promising results from the project’s researchers, not independently replicated performance figures. They do not show how Aerie would perform on different hardware, under live network conditions or as part of a complete validator workflow.
Aggregate size: what is included?
The standard aggregate for the 32, 768-signature Falcon-512 batch is reported as 1, 346 KiB, including salts and headers. The proof accounts for about 66 KiB. Retained salts make up most of the remaining data.
The researchers report an aggregate size of 42.1 bytes per signature, about 16 times smaller than the padded Falcon signatures it replaces. That ratio implies roughly 674 bytes per padded signature, though the comparison is approximate. Public keys and messages supplied separately to the verifier are excluded from the reported size measurements.
The roughly 66 KiB figure is also the estimated size of a separate shared-salt design. It is not the size of the standard aggregate. The smaller estimate depends on a separate signing policy and security assumptions. The researchers say the estimate does not establish that the design complies with that policy. Whether those conditions can be met in a real deployment remains an open question.
Comparisons come with caveats
Against Orthus, an earlier Falcon-aggregation system, the Aerie paper reports 1.5 times faster proof generation, 38 times faster verification and proofs 1.7 times smaller. The researchers also point out that Orthus’s workload omits signature-format checks performed by Aerie, so the ratios are not a clean, like-for-like comparison.
The paper also reports a roughly 29-fold throughput advantage over leanVM in the cited tests. The workloads differ: Aerie handled Falcon-512 signatures, while leanVM processed 900 XMSS signatures in 0.51 seconds on the same M4 Max, using all cores. A simple comparison of batch counts and processing times gives Aerie about 29 times as many signatures per second under those conditions. That is not a matched proof-generation comparison, and the signature families differ.
Verification paints a different picture. The cited leanVM proofs verified in 5.9 to 6.5 milliseconds on one thread. Aerie’s reported single-thread verification time was 54 milliseconds for its 32, 768-signature batch. These results are useful reference points, not a universal ranking, because the systems and workloads differ.
Post-quantum readiness is more than speed
The National Institute of Standards and Technology (NIST) lists ML-DSA and SLH-DSA among the digital-signature standards it finalized in August 2024. Falcon has a different status. NIST lists it as selected for ongoing standardization, not as a finalized standard on the same footing as ML-DSA and SLH-DSA. A fast benchmark does not determine which algorithm a network should adopt or whether its security and implementation requirements suit that network.
Ethereum’s post-quantum planning goes beyond choosing a signature scheme. A proposal for a deposit contract would accommodate variable-length cryptographic data and provide a way to retire new BLS deposits. The proposal’s GitHub record is described as a draft, with technical feedback and review still outstanding. It should not be mistaken for a deployed protocol change.
The Ethereum Foundation Protocol Cluster has set a December 2029 quantum-resistance target covering execution, consensus and data. The Foundation has described a quantum threat arriving in 2030 as a deliberately aggressive planning assumption, not a prediction that a capable machine will exist by then. Outside experts are expected to help reassess progress beginning in January 2027.
LayerZero says ML-DSA aggregation is working inside Aerie, but it has not provided exact performance figures or implementation details. For now, that remains a project claim, not a benchmark readers can evaluate. Related questions about LayerZero’s cross-chain security have also surfaced around Kraken’s decision to replace the protocol for kBTC with Chainlink CCIP, and Cardano’s plans involving LayerZero, USDCx and Midnight.
LayerZero’s Aerie announcement and research, NIST’s post-quantum cryptography program and the Ethereum Foundation’s protocol updates provide further context.
Key questions about Aerie
-
Does Aerie generate a proof in 0.65 seconds?
No. That is the reported time to process the signature batch. Proof generation took roughly 4.3 seconds on one thread.
-
How large is the standard Falcon-512 aggregate?
The reported aggregate is 1, 346 KiB, including salts and headers. The approximately 66 KiB figure is the proof component, not the complete standard aggregate.
-
Is the shared-salt version ready for deployment?
That has not been established. Its estimated size depends on a separate signing policy and security assumptions that require review.
-
Does Aerie outperform leanVM in every measure?
No. The reported batch-throughput figures favor Aerie, while leanVM’s cited proofs verified faster. The tests also use different signature families and workloads.
-
Has Ethereum adopted Aerie?
No adoption or live deployment is established by the reported benchmarks. Ethereum’s post-quantum planning is a separate effort.
Aerie’s reported benchmark offers a promising result for proving checks over large batches of post-quantum signatures. Putting it to work in consensus infrastructure will take more than raw speed. Proof-generation costs, retained data, security assumptions, standards status and performance on deployment hardware all need to withstand scrutiny.
