Overclock Validator's narya-ed25519 Cuts Solana Signature-Verify Tile Count

Overclock Validator, the community team behind Mithril (Solana's Go-based validator client), published narya-ed25519 on July 26, a pure-Go, no-cgo library that verifies Ed25519 signatures 5.8 times faster than Go's standard cryptography package. An Anza engineer who reviewed the work says it cuts the number of parallel signature-verification tiles Solana needs to sustain one million transactions per second from 72 down to roughly 8, and is actively porting the library into both Agave and Firedancer.

"Ed25519 verification is a major cost in Solana block replay," Overclock wrote in their July 26 announcement. "Mithril is written in Go, and the standard Go library wasn't enough for the throughput we wanted."

The Verify-Tile Problem at 1 Million TPS

Every transaction on Solana carries at least one Ed25519 signature, and block replay must verify each one before a transaction can be accepted or rejected. Agave and Firedancer distribute this work across dedicated CPU tiles (isolated processes pinned to single cores), and the number of tiles required grows directly with transaction throughput.

When Kevin F. Bowers first demonstrated 1.2 million TPS transaction ingestion at Breakpoint 2022, the benchmark used 72 parallel verify tiles to absorb the signature load. Four years on, Anza engineer cavemanloverboy put the implication plainly in a July 26 post: "with the improvements the Mithril team has found during their client development work, 1M TPS ingestion can be done on ~8 verify tiles. This, in my opinion, eliminates the need to consider FPGA sigverify."

FPGA-based signature verification (using field-programmable gate arrays to accelerate the elliptic curve arithmetic in dedicated silicon) had been an active scaling option considered for handling the verification load at high throughput. The software result from narya makes the hardware path less necessary, according to cavemanloverboy, who added that he is working to upstream the improvements into Agave and Firedancer's respective crypto libraries as soon as possible.

AVX-512 IFMA: Eight Signatures per CPU Register

Modern AMD Zen 4 and Zen 5 processors ship with AVX-512 IFMA (Integer Fused Multiply-Accumulate) instructions that operate on 512-bit registers. Each such register fits eight independent 64-bit lanes simultaneously. Narya exploits this by placing one complete Ed25519 verification equation per lane: all eight signatures run through their elliptic curve arithmetic concurrently, each returning its own verdict.

That design is specifically suited to validator use. Aggregate batch verification (a faster mathematical approach that folds multiple signatures into a single randomized equation) returns one combined verdict for the entire group. A validator using aggregate batching cannot selectively reject one invalid transaction while accepting the rest.

Narya's lane-parallel approach produces eight fully independent results, behavior identical to checking signatures one at a time, at drastically lower cost per signature.

Benchmark Numbers: 4.7 µs vs 27 µs on Zen 5

The GitHub repository publishes benchmarks run on an AMD Ryzen 7 9700X (Zen 5) at GOMAXPROCS=1, using cold verification on 1,232-byte messages (the conditions typical of Solana block replay, where keys are not cached between calls).

Most of the gain appears once eight signatures are in hand, since that fills all eight AVX-512 lanes. Batches larger than eight add only incremental improvement under cold conditions; the fundamental limit becomes lane count rather than computation per lane. For workloads with frequently recurring signers (a common pattern in Solana, where validator vote accounts appear in nearly every block), narya offers a precomputed public-key cache that pushes throughput further: 3.776 microseconds per signature with 64 promoted keys, or 7.3 times the standard library baseline, per the repository benchmarks.

Across multiple cores, Overclock measured approximately 978,000 signatures per second on six physical cores. On eight cores the aggregate reached 1.217 million signatures per second, though all-core AVX-512 activity lowers CPU clock speeds, so the multi-core result falls short of a linear 8x scale.

Technical Roots: Firedancer's 2023 AVX-512 Design

Narya builds on prior work from Firedancer. The Firedancer team's 2023 AVX-512 IFMA implementation represents field elements as six 43-bit limbs per element (radix 2^43, or r43x6). Overclock ported that design to Go as a correctness reference for differential testing, then developed a production backend using five 51-bit limbs (radix-51, or r51). The r51 representation leaves space for unreduced sums to feed directly into IFMA source operands, avoiding a carry reduction pass on most arithmetic steps, producing a steady throughput gain across the inner loop.

The Firedancer design vectorizes within a single signature's field arithmetic; narya vectorizes across signatures, one complete signature per lane. The two approaches target different architectures and can coexist. Per narya's documentation, no code was copied; both share mathematical constants and design lineage under Apache-2.0.

Hardware Requirements and Alpha Status

The AVX-512 IFMA backend is confirmed on AMD Ryzen Zen 4 and Zen 5 hardware. Intel Ice Lake Server and newer are expected to work based on emulation testing, but narya has not yet benchmarked on Intel silicon. There are no Xeon or EPYC performance measurements in the current release.

The backend is opt-in rather than automatic. By default, narya uses a portable pure-Go implementation; to activate the AVX-512 path, operators set OVERCLOCK_ED25519_BACKEND=r51 or call SetBackend("r51") in code. The library is alpha and unaudited. It contains approximately 4,500 lines of hand-written assembly, per the narya repository. Before release, Overclock ran the CCTV corpus (914 vectors), the Wycheproof suite (133 EdDSA vectors), RFC 8032 known-answer vectors, and Firedancer regression vectors, alongside cross-library differential checks against curve25519-voi. The differential fuzz soak reached 4.6 million executions against a target of one billion, sufficient for the current opt-in release but not yet the full soak the team considers sufficient for automatic backend dispatch. The library is Apache-2.0.

Development involved extensive AI tooling. "AI was deeply involved in the R&D (Codex, ChatGPT Pro, Claude) and helped explore code, analyze profiles/math, generate hypotheses and tests, write docs, and implemented all the code including assembly," Overclock wrote in their announcement thread. Human review, differential tests, vector validation, and native hardware gates were applied to all outputs.

Into Agave and Firedancer

Narya was built to solve Mithril's throughput problem, but its reach may extend further. With an Anza engineer actively working on integrating the approach into both Agave and Firedancer, a library that began as a community validator project targeting Go may improve signature verification throughput across the two dominant Solana client implementations, reducing verify-tile counts and freeing hardware headroom currently consumed by signature work.

As we covered in June, Mithril became Solana's fourth independent validator client when it produced blocks on the Alpenglow community test cluster (the first Go implementation to do so). narya-ed25519 extends that work from consensus participation into the lower-level cryptographic infrastructure that every client in the network depends on.