Lido on Ethereum: Obol Network Testing V2

Over the past four months, Lido DAO contributors have worked together with the Obol Network team on the second round of testing Obol-based distributed validators (DVs) operated through the Lido Node Operator (NO) registry on Goerli.

42 new Node Operators participated in this round of testing, including solo stakers, community stakers, and other professional node operators, in addition to 12 Node Operators from within the current Curated Node Operator set. This round of testing follows the first Obol testnet pilot program, which included 11 existing Node Operators that participated in the Lido on Ethereum protocol.

The goal of this second testing round was to trial operating DVs through the Lido registry with community stakers and simulate what a practical small-scale initial implementation of DVs utilizing Obol’s technology may look like.

Each cluster successfully proposed blocks, showed strong attestation performance, and experienced limited, if any, downtime. Additionally, upon completion of the 59-day trial, all of the clusters successfully exited their validators.

Cluster Configurations

Participants in the testing round were split into 10 different clusters, which are visible on operators.testnet.fi/. The clusters consisted of three different types of threshold configurations: three clusters with a 3/4 threshold, four with a 5/7, and three with a 7/10 threshold.

The clusters participating in the trial included: Quadforce, Group2 Guardians, Dvt2-g3, Group 4, Group 5 Rangers, SevenNodes, Group 7, Clustery McClusterfaces, Group9 Hunter, and Mostly Harmless.

Each cluster had a “cluster coordinator”, a member of the cluster responsible for setting up a corresponding multi-sig wallet that served as the entry to the Lido Node Operator registry and facilitated the Distributed Key Generation (DKG) ceremony.

Of the 10 clusters, 7 clusters were led by existing Node Operators, and the remaining 3 were led by community stakers. After arranging the multi-sigs, cluster coordinators began the cluster setup process through the Obol Distributed Validator Launchpad. Each cluster operated 5 validators.

Distributed Validator Setup

Clusters were configured to match the appropriate cluster threshold size and set to generate 5 validator keys through Obol’s DKG implementation. This differed from the first Obol trial where the two clusters only spun up a single validator per cluster.

The validators were configured to use the Lido protocol Goerli Withdrawal Address and Fee Recipient address to ensure Execution Layer Rewards would flow to the EL Rewards vault as done on mainnet.

Obol’s implementation of DKG currently happens in a semi-synchronous manner. Once all clients in the cluster can establish a connection with one another and they each complete a handshake, the DKG is completed. During the initial ceremony attempts, clusters ran into a series of bugs as they attempted to execute the DKG. The Obol team quickly worked with the affected participants to rectify the issue and within days released v0.14.4, solving the issue and leading to successful DKG ceremonies for all 10 clusters.

Following the successful completion of the DKG ceremonies, the cluster coordinators submitted the deposit data for their 5 validators to the Lido registry. This was then verified by other members of the multi-sig and a motion to increase the clusters validator limit to 5 soon followed. Upon completion, deposits began to flow to the validators and they began attesting. In the days that followed however, another issue was identified related to unsuccessful block proposals across clusters.

The Obol team identified two issues that were causing missed proposals: 1. High bandwidth needs of the Obol wire format and 2. a change in the latest Teku image that asked for blocks in SSZ format before JSON format (SSZ was not supported by Charon at this time).

Over the next few days, Obol released v0.15.0, which introduced a more compressed format with lower bandwidth requirements as well as support for SSZ proposals. The v0.15.0 upgrade fixed the issues with block proposals and during the next two weeks each of the 10 clusters successfully completed at least one block proposal. Following the v0.15.0 upgrade no further issues with block proposals were identified.

Following successful operation of the clusters for the trial period (59 days), on the week of 5/21/23, the Lido x Obol clusters began to exit validators which proved to be a simple and efficient process. Cluster members broadcast partial signed exit messages to the other members of their clusters. When the cluster threshold was reached, the message was broadcast to the network and the validators successfully exited.

Upon completion of the trial, an internal competition was held between clusters to create a digital collectible that all members of the 2nd round of Lido x Obol DVT testing would receive. The following design from cluster “Dvt2-g3" was chosen as the winner of the competition.

Obol’s DVT implementation has made tremendous progress since the last round of testing; however, there are still a few features needed to run at scale in a Lido based implementation. Among these, support for blinded blocks (to enable MEV-boost support), the ability to add more validators to an existing cluster, and supporting validator exits across all Consensus Layer clients will be important features to test before scaled roll-outs of Obol based DVs begin.

Performance Stats

During the 59 day period that validators were online, the 10 clusters showed performance metrics generally in-line to slightly above that of other validators run on Goerli per Rated Labs data (note that average validator performance on Goerli is much lower than mainnet).

The high number of blocks missed during the trial are a result of the issues described above, which were resolved by the v0.15.0 upgrade.

Next Round of Testing & The Future of Lido DVT-powered Validators

With the successful implementation of Lido V2, focus is now shifting to the opportunities provided by the Staking Router.

Introduced in Lido V2, the Staking Router will allow for the modularization of the Lido protocol and provide new mechanisms through which Node Operators can run validators for the protocol. Potential modules include permissionless entry, DVT based modules, Validators as a Service, mixes of the aforementioned, etc. A diverse set of teams, including Obol Network, SSV Network, Dappnode, Avado, and others, are engaging with the Lido community to explore creating new methods for a new Node Operators to use the lido protocol.

From a DVT perspective, potential methods of participation (which would need to be assessed and voted on by the DAO first) could include limited trials of simple DV configurations on mainnet, more complex modules with native DVT-protocol mechanism integrations (including e.g. unique onboarding methods and economics), and migration of stake from the single-operator model currently utilized in the Curated Operator Set.

As these possible mechanisms are being investigated, further testnet activities will be happen. For Q3, there is definite community interest to see onboarding of additional non-existing Node Operators to DVT testnets, running DVT testing with all existing NOs, and trialing DVs in a secondary module on the Goerli testnet.

If you are interested in participating in future Lido on Ethereum DVT testnets, please use this form to express your interest. In the coming months next steps will be announced.

A number of important initiatives related to DVT and Community Staking are underway. If you are interested in becoming more involved in the Lido Community, see initiatives such as the Lido Community Lifeguards or send an email to [email protected] to explore other ways you can use and participate in the protocol.

Stay tuned to the Lido blog in the coming weeks for another blog post detailing the second round of testing with SSV Network and additional details about future Lido DVT testnets.

Lido x Obol Testnet Participants:

Group 1: HashQuark, DSRV, Stakely, Conqueror

Group 2: Kukis Global, Simply Staking, Mav3rick, SenseiNode

Group 3: Mahof, Cosmostation, GraphOps, Amonxx

Group 4: Cryptomanufaktur, Chorus One, Everstake, Blockscape, Nethermind, Luganodes, Erkan Efe

Group 5: Staking Facilities, Stakely, Kukis Global, Everstake, A41, Bellatora.co, D-Stake

Group 6: SenseiNode, Spacesider, Wallclimbr, Ugur | NodesKuge, Imperator.co, Secard, Kyne Software

Group 7: Chorus One, DSRV, Blockscape, P2P, Minivipers, P-OPS Team, alkadeta

Group 8: HashQuark, Simply Staking, Nethermind, Kukis Global, Staking Facilities, Cryptomanufaktur, Archimedes, H2O Nodes, Coinstamp, Talha

Group 9: Chorus One, DSRV, P2P, HashQuark, Everstake, Emre NOP, Farukyasar, Polkachu, wabut.club, Staking4all

Group 10: Luke, Eridian, Furkan Efe, NakoTurk, Obol Ar Line, Smart Node Capital, Sodiumstar, Swiss Staking, Yesaynow, Piconbello