Staking Router Module Proposal: Simple DVT

Hello everyone again. I wanted to provide an update, following the Alan fork of yesterday, October 8th, 2024.

The fork has had a couple of road bumps, when a new node version, labelled v2.0.0-unstable.2 was released on the eve of the scheduled fork. This was an overly precautious code change, that was deemed necessary, but only proved to be “helpful”.

Our analysis of Simple DVT clusters performance showed that clusters where all 7 operators’ nodes used v2.0.0-unstable.0 reacted correctly to the fork, and performed essentially equally to clusters where all 7 operators had upgraded their nodes to v2.0.0-unstable.2.

Our analysis also shows that the entirety of Simple DVT Testnet #4 clusters were essentially not impacted by the fork, meaning, their performance was unaffected, except for an initial dip, due to the restart of the peer-to-peer network, and consequent need for nodes to discover peers over the network. Below is a screenshot of our metrics showing all clusters, except for one (Xeric Xenolith):

(Bear in mind, this is Holesky testnet, which tends to have lower performance in absolute terms, compared to Mainnet)

The reason for excluding such cluster is that is predominantly composed of Dappnode users, who also has a majority of operators using Nehtermind client. This cluster found out that an unexpected update to the Nethermind package for Dappnode was faulty, and this essentially ground the cluster to a halt.

The screenshot below show such cluster in isolation, and the period of inactivity is clearly visible:

A different kind of analysis is the impact the fork had on the machines running the SSV nodes, and most importantly, the resource usage. Our internal numbers show:

  • CPU: 75.62% decrease
  • RAM: 23.19% decrease
  • Receive bandwidth: 71.26% decrease
  • Transmit bandwidth: 70.47% decrease

Which is in line with what community member have observed in an independent study:
https://www.reddit.com/r/SSVnetwork/s/x5zjobdYq5

Furthermore, I want to clarify that unlike previous updates, this one involves a network fork so with regards to Mainnet and Lido’s ProSecCo policies, we could gradually rollout the new client version, but the fork does not allow for staged testing of all the features of the upgrade, as there’s no way around having the entire network being updated simultaneously.

And with respect to Mainnet, the dates have not been finalized yet, but we are expecting the tentative date to be shifted and the Mainnet fork to happen in the second half of November, instead.

Lastly, we’re in the final stages of the SSV spec and node audit. The specs audit is already completed, and we’ve received an initial report for the node audit, which we’ve reviewed and iterated on (no critical issues were found). We expect the full audit, as well as the finalized report to be ready within a week.

The preliminary audit report is going to be submitted to the ProSecCo committee for initial review, although not publicly available, until the final report is available.

In any case, given the aforementioned shift in the Mainnet fork timeline, there should be sufficient time for Lido and its community to review them before the Mainnet version is released.

2 Likes