A high performance, homegrown Solana validator Developing the full node client Mithril Team: @7LayerMagik & @dubbel06
Joined May 2022
- Tweets538
- Following965
- Followers2.8K
- Likes1.3K
1/ Ed25519 verification is a major cost in Solana block replay. Mithril is written in Go, and the standard Go library wasn't enough for the throughput we wanted.
Today we're releasing narya-ed25519. 5.8× faster than crypto/ed25519 at 4.7 µs/sig (Zen5).
github.com/Overclock-Validat…
Overclock | Solana Validator retweeted
our very own chief caveman (@cavemanloverboy) spent some of the weekend fixing bugs and adding Harmonic support to the Mithril Solana validator client @OverclockSol
this block, broadcasted by the Temporal Topaz Validator, was produced on the HarmonicMithril client orbmarkets.io/block/46020788…
Harmonic remains committed to making Solana the most robust blockchain where any asset can be traded at the speed of light
We would be interested in getting the mechanism audited for everyone's benefit, but we need a sugar daddy for that
Overclock | Solana Validator retweeted
In order for 20 market makers to reliably quote JUST the S&P500 members at 10 quotes per second, the chain needs to support 100k oracle updates per second.
with the fd runtime, oracle updates execute with a mode of about 15 micros (load, execute, commit). verifying these signatures cost approximately 19 micros — more than the time it takes to execute — until now!!!
this optimization is a HUGE step toward making Solana the house of all finance.
Thank you to @Allnodes for giving us a free Ryzen server rental to test these Zen5 benchmarks on!
1/ Ed25519 verification is a major cost in Solana block replay. Mithril is written in Go, and the standard Go library wasn't enough for the throughput we wanted.
Today we're releasing narya-ed25519. 5.8× faster than crypto/ed25519 at 4.7 µs/sig (Zen5).
github.com/Overclock-Validat…
11/ Narya is alpha and unaudited, and the AVX-512 backend is opt-in rather than automatic. We differential-test against Go's stdlib and curve25519-voi, run the CCTV and Wycheproof suites, and fuzz, but it still needs independent review.
Apache-2.0, attributions in NOTICE.
10/ Regarding our work here, we want to say thank you to our AI overlords.
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.
9/ Across 8 cores we measured 1.217M signatures/s, short of 8× the single-core rate because all-core AVX-512 drops the clocks.
8/ For recurring keys it goes further, caching the decoded public key and then promoting hot ones to a precomputed table. With 64 promoted keys on the same Zen 5 host, n=64 measured 3.776 µs/sig, 7.3× stdlib. How much you get depends on key population and locality.
7/ You need several signatures in hand at once, which replay gives you. They don't have to be related, though: cold verification needs no cached or precomputed public-key state, so any unrelated signatures can fill the lanes.
6/ That independence is deliberate. The faster option is aggregate batch verification, folding every signature into one randomized equation, but it returns a single verdict for the whole set. A validator has to reject a transaction, not a block.
5/ Narya also vectorizes across signatures rather than within one: a whole signature per lane, eight per ZMM register, which is why everything in the code is named x8.
Every lane has its own equation, so you get eight separate verdicts, identical to verifying them individually.
4/ The backend we ship uses five 51-bit limbs instead. That leaves headroom for unreduced sums to feed straight into IFMA source operands, which the point formulas exploit constantly, saving a carry pass on nearly every one.
3/ We started from Firedancer's 2023 AVX-512 work, which represents a field element as six limbs of radix 2^43. We ported it to Go first and kept it as a correctness reference for differential testing.
github.com/firedancer-io/fir…
2/ Narya is a no-cgo Go library using AVX-512 IFMA assembly.
The numbers below are cold strict verification on 1232-byte messages, with no per-key state cached between calls. Most of the gain shows up once you have eight signatures, since that's what fills the lanes.
It will use more, but maybe around 8 GB. We will see if we need to change things to be competitive enough with the other validator clients though. A professional validator setup should use more substantial hardware regardless.
Okay, Mithril validator is running at less than 3GB RAM on the Alpenglow cluster with a small Ryzen. We just need some of your state compression ideas implemented so that we don't need to plug a NVME into the phone when we have Mainnet state to deal with. The massive 50k tps synthetic blocks on ag cluster will also be challenge for a phone...