Hi @Tane - thank you for taking the time to review the proposal – I really appreciate the detailed questions!
- How can we mitigate the risk of DVT protocols have?
I will weigh in here from my perspective and would also ask for @mol_eliza from the Analytics Workstream to add his thoughts as well, especially on the side of insurance.
Risk mitigation is at the forefront of all of the processes related to Simple DVT. This starts with the LNOSG participant evaluation and proposal to the DAO, with clusters containing a healthy mix of client types utilized, geographic and infra hosting diversity, as well as the semi-random combination of participants that seeks to limit the impact of potential sybils or NOs with malicious intent. This continues on with key generation and security, wherein each validator key is generated via Distributed Key Generation ceremonies, with no one Node Operator ever having the full pk available.
One of the main focus areas here is related to software updates of the SSV client and Obol’s Charon middleware. This is likely the highest-risk activity, as it is the time most likely to introduce a new bug onto mainnet that could cause downtime/slashing. The expected flow for all SSV or Obol software updates includes: 1. Making sure the new versions are tested in different combinations on testnet before mainnet, 2. Starting with <= 1/3 of mainnet clusters updating to the new version and operating without issues for at least a week, and 3. Slowly rolling out the updates to the remainder of clusters over time.
This later process is being utilized now with Obol mainnet, where NOs are still using v0.19.1, but will slowly start the update process once we’ve activated validators on v0.19.2 in the ongoing Obol testnet.
Finally, all significant updates for Obol and SSV are expected to be audited and shared/communicated within the Simple DVT thread for review from the community (of which you can already see examples within).
From my opinion, DVT lowers risks vs. normal single NO validator setups. The combination of thresholds with differing client and hosting types in conjunction with DKG mitigates many of the most common risks related to downtime/slashing, and from a software perspective the security focused cultures of contributors from Lido, Obol, and SSV are very concentrated on making sure that harmful bugs don’t make it into production.
If you have any other suggestions or feedback related to this, I would love to discuss in more detail.
- What would be the targeted revenue for DVT NOs?
Thanks for the question – I think one of the most important parts of the proposal is raising share to make sure that the economics are better for participants in a way that is sustainable for them to continue running these validators on a multi-year time frame.
The proposal mentions an average reward rate per validator of ~ $30 (this assumes $3000 ETH and a 3% staking rewards rate). For the normal Simple DVT clusters, the proposal suggests the 72 clusters that would be running in this configuration would split half (2%) of the 4% target share, evenly divided by Obol and SSV clusters. At today’s number of validators, that would be ~ 80 validators per cluster.
Considering that NOs in Simple DVT do not put forward a bond, it feels like a reasonable target in terms of the rewards, especially for solo and community stakers, while still balancing the amount of risk that any one cluster with mixed participant types might present. When considering e.g. the cost of the highest model Dappnode at €1,920, a participant could pay for their entire fixed cost of operation with rewards to spare in year-one.
- How will we choose ANO?
ANOs will be chosen through a review process by the Lido Node Operator Subgovernance group using data from mainnet and testnet. This will include performance metrics gathered from Obol and SSV at the participant level, as well as qualitative comments such as response times within their clusters, ability to self-diagnose and recover from issues, and general knowledge around DVs and validators more broadly which can be assessed via their participation and cluster threads.
Next, the LNOSG will form clusters of these participants, balancing client types, geo location, and their hosting types. Once this done and reviewed by the sub-committee on a call (the introduction and conclusion of which would be posted publicly to the forum), the clusters and participants would be proposed to the DAO for final review.
If the proposal is accepted by the DAO, I would expect this process to take place sometime between late June to mid-July. Once the clusters are proposed, there is a week discussion period for the DAO to make comments and signal for any potential changes.
- Where does 3.5% of share come from then?
The share would come from net-new stake, unless otherwise cycled (withdrawn and re-deposited to the protocol). In other words, it’s intended to be incremental to the existing stake. Because the SDVTM is the module with the lowest amount of share in the protocol, new deposits will be routed to it assuming there is available capacity (i.e., available and depositable keys). This is also partially the reason why the addition of Super Simple DVT clusters makes sense, as new stake is currently being put into the Curated Module, as there is no available capacity due to the lower key limits in SDVT clusters (especially as they are only currently in the early stages of the scaling process).
Hopefully this answered your questions - if you have any follow ups or other comments please let me know!