Simple DVT: SSV Testnet #3 Results

Last week, the Lido x SSV Simple DVT testnet officially ended, with the aggregate validator set surpassing all of the minimum requirements to move forward to mainnet!

This was the 3rd Lido x SSV trial allowing Node Operators to use the Lido Node Operator registry with SSV-based DVT on testnet.

In the coming weeks, a proposal to the DAO is expected with the suggested list of participants to move forward to the mainnet Lido Simple DVT Module using SSV’s technology.

Read on to learn more about the testnet, the strong performance of SSV based validators, and the process regarding how to become a Node Operator on mainnet using the Lido Simple DVT Module!

What is Simple DVT?

The Simple DVT Module (SDVTM) is the second mainnet Lido protocol module, added following an on-chain Aragon vote in February 2024. The module provides the first opportunity for solo and community stakers to participate in running validators using the Lido protocol by leveraging the established design of the Curated Operator Module and DVT solutions provided by Obol and SSV Network.

According to the proposal, the module would be initially capped at 0.5% of total Lido stake (with the option to be increased via DAO vote) and is expected to allow for the addition of  over 250 net-new Node Operators to the protocol in the first six months post-launch.

The SDVTM is intended to be wound down within 3 years, during which time more scalable DVT modules with permissionless elements are expected to have been added to the protocol.

To learn more about the SDVTM, read the recent blog post here.

Lido & SSV Testnet: Overview

Participant Distribution

The 3rd Lido x SSV Testnet started in late November 2023 on the Holesky testnet, with 163 total participants including over 60 solo stakers & community stakers, as well as 90+ and professional node operators. Participants were split into 32 clusters of 7, with an effort to minimize geographic related latency and achieve a diversity of infrastructure types (e.g. bare metal servers, home machines, and public cloud).

Each cluster included a member of the Lido Curated Operator Set (many of which had participated in prior Lido x SSV testnets) to ensure an experienced participant in each cluster. In addition, an effort was made to include participants that had indicated significant experience with SSV based DVT during their applications. At the aggregate level, participants ran nodes from 32 countries across North & South America, Europe, Asia, and Australia.

The Process

Participating clusters started the process by submitting a verified “Individual Manager Address'', used for signing messages in the Protofire Safe and SSV webapp, and an optional “Individual Reward Address'' that participants could choose to receive validator rewards in lieu of their Individual Manager Address.

Next, clusters proceeded with choosing a “Cluster Coordinator”, a participant that would be responsible for creating their Safe multi-sig and initializing the Distributed Key Generation (DKG) ceremony for each cluster. Each cluster’s SAFE consisted of a 5/7 threshold, and represented their cluster in the Lido Node Operator registry on Holesky.

Once completed, Cluster Coordinators created their respective cluster Safes and their Node Operator entries were created. Thus began the node setup process. In SSV, each participant is responsible for running an SSV Operator (which also acts as their validator client) as well as a DKG Node. Due to the early-stage nature of the Holesky testnet, MEV-Boost was not initially supported, requiring participants to directly connect to the Titan relay via their CL client.

Importantly, this testnet was the first where SSV’s DKG tool was tested at scale, with Lido as the first staking protocol to coordinate SSV DKGs with over one-hundred sixty participants, and presented the first opportunity for many participants to utilize DKG via SSV. One of the benefits of SSV’s DKG format is the ability to generate keys via DKG as needed. Cluster Coordinators were responsible for initializing the DKG to their cluster participants. As long as each member of the cluster had their DKG node running, the coordinator was able to run the DKG command to generate the first 5 keys.

Once done, the Cluster Coordinator then started the process to register the validators to the SSV smart contracts for their cluster participants to sign in the Safe, which also included setting a spend approval for SSV tokens and updating of the cluster Fee Recipient to the Lido Execution Layer Rewards Vault on Holesky.

When the clusters completed the signing process and verified the correct validators were registered to their respective clusters, they proceeded with starting the process of submitting their validator keys to the Lido Node Operator registry, which then also required verification from the cluster participants.

Soon after, the Lido Simple DVT Module Committee on Holesky raised the key limits for the clusters, and their validators were activated. During the following weeks, performance metrics across Uptime and Attestation Effectiveness showed generally promising results, and clusters proceeded with DKGs and registration for 50 total validators.

During this time, it was noted that Block Proposal Success Rate for certain clusters was performing below average. The issue was traced to two factors: 1. The early adoption of Holesky by builders and 2. Geographic latency issues for clusters with infrastructure located far away from the relay locations. As the Holesky testnet matured, Flashbot’s provided MEV-Boost support and participants were asked to enable MEV-Boost with the Flashbots, Eden, and Titan relays. A notable improvement in Block Proposal Success Rate was observed, and cluster key limits were raised to 100 total validators.

In late February, clusters were asked to upgrade their nodes for the Deneb hardfork on Holesky. Following the fork, a deterioration in overall Holesky validator performance was observed, as can be seen in the screenshot below. Following the fork, minor issues were identified with Nimbus, Teku, and Prysm, and along with an improvement to the SSV client in v1.3.2 update, performance was restored and network-wide trends saw gradual improvement.

In early March, the SSV team identified a number of improvements they wanted to make to their DKG tool. After discussion amongst Lido DAO contributors as well as the SSV Testnet Participants, it was determined that the testnet would be extended to use the updated version of the DKG tool.

All clusters upgraded to v.2.0 of the DKG node, and 31 of the 32 clusters ran an additional DKG process for 20 validators which were successfully submitted and registered to the SSV and Lido protocols. The one cluster that didn’t perform the DKG ceremony was due to a Node Operator losing their operator private key (however due to the threshold configuration, this cluster was still able to exit their validators). Once the 31 clusters completed the DKG, registration, and key submission process, it was determined that only two clusters would proceed with the remainder of the process (receiving deposits to the validators and awaiting activation), while the remaining clusters proceeded to exit and remove their validators from the SSV protocol due to the extended entry queue on Holesky.

The two clusters that kept their validators running saw the 20 validators successfully activate and good performance was observed. Soon after, all 32 clusters had successfully exited their validators and successfully tested the rewards claiming flow.

Lido & SSV Testnet: Performance Results

SSV Cluster Aggregate Results

The aggregate testnet results for Lido x SSV clusters surpassed all of the Minimum Testnet Characteristics outlined in the Simple DVT Module Proposal by far! This included a 98.58% Uptime, 94.38% Block Proposal Success Rate, and 80.65% Attestation Effectiveness (all metrics per Rated).

Given the successful metrics, the SSV trial passed all of the requirements for SSV Network based DVT to move forward to the mainnet Simple DVT Module!

Cluster Results

At the cluster level, 30/32 clusters surpassed the Uptime Benchmark, 32/32 surpassed the Attestation Effectiveness benchmark, and 31/32 surpassed the Block Proposal Success rate benchmark.

All in, 90.6% of clusters, or 29/32, surpassed all of the observed required benchmarks.

Upon analysing the participants and infrastructure types prevalent across the clusters that did not surpass all of the benchmarks, a number of factors were observed:

1. Hardware Type

Clusters with a higher number of participants utilizing home-based hardware or low-performance VPS offerings generally saw lower performance results. This is likely due to bandwidth constraints and higher resource consumption on certain nodes that had non-Lido related stakers utilizing these operators to run their validators.

2. MEV & Relays

As mentioned earlier in the report, MEV & Relays did play a role in impacting Block Proposal Success Rate in certain cases. Early in the testnet, some issues were observed where validator clients did not always properly fall back to proposing a “vanilla” block in cases where the relay did not provide bids from builders. While the introduction of MEV-Boost generally improved performance, the change in configuration did cause issues for some clusters where participants did not perform the adequate updates.

Participant Performance

While specific participant performance will not be discussed in this blog post, there is an important point to note: participants in clusters that did not reach the minimum performance benchmarks are not automatically excluded from moving forward to mainnet.

In many cases, these clusters contained a majority of Node Operators who were highly cooperative with their clusters, responsive to updates and testing requirements and whose nodes were performant.

The LNOSG will meet in the coming weeks to examine the quantitative performance results of the trial at the aggregate, cluster, and participant level and will also have the opportunity to examine the qualitative metrics obtained via survey and notes from the trial from the Lido DAO and SSV contributors.

Following that, a forum post will be made on the Lido Lido Research Forum to propose the clusters and participants to move forward to mainnet in Cohort 1 and Cohort 2. Each participant will receive an email with individual feedback noting the proposed assessment and inviting them to participate in the cluster formation discussion and also optionally in the next testnet if they so choose.

The Road to Mainnet

Following the proposal on the forums by the LNOSG of mainnet participants suggested to move forward, the DAO will have 7 days to discuss the proposal and state any objections. For those participants not proposed to move forward to mainnet, another Lido x SSV testnet will begin in late May/early June, wherein they are invited to participate once again.

If no objections to the proposal arise, clusters will begin the coordination process by signing their agreement to the Operating Rules on-chain, setting up their nodes, followed by the Simple DVT Module Committee commencing Easy Track motions (which can be rejected by LDO token holders) to register the SSV clusters to the Lido Simple DVT Module registry.

When the steps above are completed and SSV clusters are added to the registry, the Simple DVT Module Committee will raise key limits for the SSV clusters to 5, and a 30 day monitoring period will begin.

Following this monitoring period, performance will be shared with the DAO. If the results show strong performance, cluster key limits will be raised again and additional clusters will be added to the module.

Testing Continues: Lido x SSV Testnet #4

The next Lido x SSV Network testnet is expected to commence in late May or early June. The requirements to participate are provable experience running an SSV Operator. All solo stakers, community stakers, and professional node operators are invited to apply.

Please fill out this form if you are interested in participating!

Appendix: SSV Testnet #3 Participants

• Cohort 1: blockscape, bobby wen, HashKey Cloud, Hellman, Luganodes, OKX Pool & Staking group, Tessier-Hashpool Ltd.
• Cohort 2: Blockshard, Infer, Kukis Global, LiveRaveN, RomanK, ShardLabs, Spire Blockchain
• Cohort 3: CVJoint, Deutsche Telekom MMS, Foundry, LIVE🟢NODE, ParaFi Technologies LLC, SRC Technology, Stardust Staking
• Cohort 4: lux8.net, Republic Crypto, RockawayX, Serenita, Sjors, StakingCabin, DragonStake.io
• Cohort 5: Allnodes, Mav3rick|BeeHive, ShardLabs, smartinvest.eth, StakeValid, STAKECRAFT, yesaynow
• Cohort 6: ipetkov.eth, KhunChan, Lanski, Lydia Labs, Pacobits, RockLogic GmbH, stakelab.zone
• Cohort 7: A41, Coinstamp, Dashing Brand, Forbole, KysenPool, Nodeinfra, StakeWithUs, TytyNode
• Cohort 8: Anonstake, antotg, CryptoManufaktur,  Scott Tan | Node3.tech, Spire Blockchain, Swiss Staking, Tessier-Hashpool Ltd.
• Cohort 9: 01node, Chainode Tech,  Enigma, iicc, jayjay, kjnodes, Stakin OÜ
• Cohort 10: Colossus, Crouton Digital, Kukis Global, Lanski, Meria, Republic Crypto, Sam | Stakesaurus
• Cohort 11: ChainOps - Aleksandr, StakingCabin, Kiln, MIDL.dev, Polkachu, selim (archimedes), Spire Blockchain
• Cohort 12: Cosmostation, DSRV, Eridian, Luciola, marko, Nodes.Guru, Spacesider
• Cohort 13: 2nh, BlockPI Network, BlockVision,  Lydia Labs, OranG3cluB, Rockx, Validation Cloud
• Cohort 14: Astro-Stakers, IONode Online, Mav3rick|BeeHive, Orion, Scott Tan | Node3.tech, SenseiNode, [NODERS]TEAM
• Cohort 15: 🅰🅻🅴🆇ⒾⓉ, Chainlayer, Deutsche Telekom MMS, Intersecting Sulphide, Matrixed.Link, Stakin OÜ, Swiss Staking, Vladcrypto
• Cohort 16: Anonstake, Cryptonative Systems, DragonStake.io, GNST,  RockawayX, Simply Staking, Zim
• Cohort 17: Eridian, Launchnodes, Moonlet, Openbitlab, Serenita, Staking4All, VARL
• Cohort 18: 2xStake, Chainode Tech, D-Stake, Everstake, kxinon, Lightning Strike,  POSTHUMAN validator
• Cohort 19: blockblaz(g11tech), Ebunker, KingSuper.org, Luganodes, Neuler, StakeWithUs, XHash
• Cohort 20: DSRV, Liquify LTD, longgeek, Nethermind, Node Guardians, Stakely, swiftstaking
• Cohort 21: Chainlayer, iicc, Irina, Lanski, LIVE🟢NODE, Nodes.Guru, SNC
• Cohort 22: Blockpower, blockscape, Cosmostation, Dora Factory, Goooodnes, htx-pool, Sam | Stakesaurus
• Cohort 23: Chainnodes, Epoch Forge, ipetkov.eth, Piconbello, starnodes, STAKR.space, Stakely
• Cohort 24: Chainbase Staking, Girnaar Nodes, LinkRiver, Pier Two, Sigma Prime, Spacesider, Thunderhead
• Cohort 25: dimasik, Ellipfra, GBeast, H2O Nodes, InfStones, Prime Cut, Spectrum Staking
• Cohort 26: 01node, B62Node, Colinka | BeeHive, jayjay, Nethermind, RockLogic GmbH, Sjors, nodeproxyz
• Cohort 27: Avaunt Staking, gavryushev, Hayhouse Projects, hukutu4.eth | BeeHive, p2p.org, Pier Two, Validation Cloud
• Cohort 28: 0xFury, Birkoff, CryptoManufaktur, CVJoint, mattstam, Michael, Tessier-Hashpool Ltd.,
• Cohort 29: Ellipfra, farukyasar, Gateway.FM AS, keklodoq, Liquify LTD, Piconbello, tRDM | Nodera, Cryptomanufaktur
• Cohort 30: ChainUp, Forbole, Hashkey, Lavender.Five Nodes, Luganodes, marko, nodeADDICT
• Cohort 31: Eridian, HashKey Cloud, H2O Nodes, Lev, Node Guardians, ParaFi Technologies LLC, SRC Technology
• Cohort 32: A41, Anvil Finance, ChainUp, Hellman, LinkPool, Pacobits, Protofire