A high performance, homegrown Solana validator Developing the full node client Mithril Team: @7LayerMagik & @dubbel06
- Tweets 538
- Following 964
- Followers 2,751
- Likes 1,251
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.
1
7
1,589
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.
1
6
390
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.
1
8
943
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…
8
22
99
121,668
3/ Mithril’s performance has improved substantially. Mainnet block execution latency is roughly half what it was in the alpha release.
On a relatively small server, Mithril can execute full-CU blocks in under 400ms, helped by wins like better-parallelized account loading.
1
3
163
7/ Here’s a video of the tail end of this catch up process. In this run we fetched blocks from a @heliuslabs RPC endpoint to execute and get as close to the network tip as possible.
Any mismatches versus mainnet execution result in internal errors that halt a Mithril node.
2
1
43
3,892
6/ Once a node reaches the chain tip (most recent confirmed slot in our current setup), it enters a steady state where replay settles closer to slot speed (~400 ms/slot or ~2.5 slots/s ).
Even less bandwidth is needed at this stage, roughly 10 to 30 Mbit/s download currently.
1
49
4,347
5/ Here are some stats from the initial catchup period when Mithril needs to quickly execute blocks to reach the tip of the chain. Slots are replayed during this stage at ~3 to 10 slots/s depending on block sizes.
Download bandwidth is typically ~40 Mbit/s.
1
49
4,501
4/ With good but affordable hardware (16 GB RAM, newer Zen 4 Ryzen CPUs with 6+ cores, and a 1 TB+ PCIe 4.0 NVMe drive), Mithril can catch up quickly.
We expect requirements to drop as performance improves. Currently, mini pc's like the one below are excellent for Mithril.
4
1
77
18,742
2/ To sync Mainnet, Mithril downloads a snapshot (~100 GB). This is bandwidth-demanding, but home internet is sufficient to do so (though slower).
AccountsDB build takes as little as 10 minutes, and snapshot download + extraction are pipelined to overlap network and disk I/O.
1
63
6,677
1/ Two years ago, we set out to build a full node that could verify Solana Mainnet on modest hardware and home internet, making decentralization accessible.
Today we're releasing the Alpha version of Mithril, our Solana full node client in @golang, and it can do exactly that.
122
144
775
338,690
11/ Lastly, we couldn’t have done it without our amazing team and great collaborators. Special shout-outs go to Shaun (smcio on GitHub), our lead Mithril developer, and newer Overclock team member Palmer, whose performance tweaks this past week were outstanding.
1
23
797
10/ Ultimately, we expect to see Mithril verifying blocks very close to the tip of chain with commodity hardware.
If you want to follow our progress more closely, check out the Mithril Development channel in our discord or head to the Mithril github repo
github.com/Overclock-Validat…
1
1
15
1,110
7/ Below you can see Mithril running on a small server from @latitudesh, verifying blocks from Epoch 781.
- ~450 ms/block
- Peak ~8 GB RAM usage during the snapshot to AccountsDB building process
- Steady state RAM usage of ~3 GB during block replay
1
2
35
40,860
Do you have a sense of how much turbine retransmit, repair servicing, and gossip impact replay speed? At one Sol stake our replay times were a bit atrocious. We added a little bit of stake and are currently running Frankendancer (not sure if possible to see replay metrics now).
2
1
175
We were surprised to see that Overclock Diablo has a solid TVC rank given that it is only running with an EPYC 7443p cpu in Colombia at the moment.
EPYC 7443p's are a lower end CPU for MB these days and we are excited to see where things go when we receive our new hardware.
8
4
34
5,276
Furthermore, we aim to support geographical decentralization, particularly in Latin America, which has seen a recent increase in validators through the efforts of @JagPool_xyz and the @SolanaFndn .
Overclock Diablo is now the first validator in Colombia, situated in Bogotá.
5
2
101
To support recent efforts to battle test Frankendancer and eventually Firedancer on Solana Mainnet Beta, we have launched a second validator that will be running Frankendancer, named Overclock Diablo 👹
stakewiz.com/validator/64ngu…
8
1
28
1,502
Overclock is currently in the lead for the TVC day 1 validator competition 😎
("PERFECT RECORD" is not actually a validator, just an ideal benchmark). Follow the race from @jstrry's site here: app.vx.tools/
6
2
33
1,659
We have reached a major goal: Mithril's first matching BankHash with Mainnet-beta ✨
In Milestone 1 we worked on SVM conformance at the transaction level. With matching BankHashes, we're starting to see client conformance between Mithril and Mainnet-beta at the level of blocks.
5
20
81
10,066
3/7) Contrary to popular belief, more accessible verification of Solana is attainable.
Solana's validator & RPC nodes were designed for intensive, low-latency tasks, but certain sources of overhead can be minimized to achieve a more streamlined "verifying full node" design.
5
1
24
1,865
2/7) A nagging criticism of Solana has been the difficulty to verify it with a full node, a weak point in its decentralization.
A Solana full node typically requires a pricy datacenter server and sophisticated technical experience — a heavy ask for most blockchain users.
4
31
2,217
1/7) Today we're excited to shed light on Mithril, a Solana full node client in the Go programming language, being developed to make verification of the chain easy and affordable enough to do so from your home 🛖 or cloud ☁️
github.com/Overclock-Validat…
44
91
355
124,683
3/7) Contrary to popular belief, more accessible verification of Solana is attainable.
Solana's validator & RPC nodes were designed for intensive, low-latency tasks, but certain sources of overhead can be minimized to achieve a more streamlined "verifying full node" design.
1
70
2/7) A nagging criticism of Solana has been the difficulty to verify it with a full node, a weak point in its decentralization.
A Solana full node typically requires a pricy datacenter server and sophisticated technical experience — a heavy ask for most blockchain users.
1
77
This morning we migrated our validator to its new home in the Zag1 @digitalrealty datacenter in Zagreb, Croatia.
We wanted to help further geographical distribution and it is currently the only validator located in the beautiful country of Croatia.
validators.app/data-centers/…
4
2
15
1,628
in a clob you can market make with much less money, so you can support higher volumes with significantly lesser capital. tvl doesn't count how much capital they're using for that - it's explicitly meant for swaps
3
57
1.16 is based and it'll get even better.
core devs are goated when it comes to optimizing hardware usage
2
2
145
> You come to me with a full node which the average person can run for <$500 while maintaining a high TPS, I will support Solana.
you can run a performant node that stays at tip for 337$ @latitudesh
If you don't need to stay at the tip, you can do it for *much* cheaper
1
1
303
additionally, solana HAS considered other cryptographic primitives as well, such as KZG commitments in turbine, but guess what -> the constant proof size is not worth the performance against just using merkle trees
1
1
10
546
this is completely wrong. solana has the same features eth does, but they're feature gated because
1) demand for the feature (eth NEEDS L2s to function, so doesn't)
2) currently, it would hurt performance
everything eth gets from "zk" is because of 3 precompiled alt_bn128 calls
2
1
24
1,068