Dappnode Proposal for CSM and SDVTM integration

Answering the CSM and SDVTM integration RFP, here is Dappnode’s proposal:

Dappnode Overview

Dappnode is Free Open Source software with the purpose of making deploying, operating and maintaining web3 infrastructure accessible to anyone, regardless of their technical level.

Its design principles uphold self-sovereignty, privacy and ease of use.

In the spirit of highly enhancing the ease of use, the Free Open Source Software Dappnode also comes preinstalled in plug-and-play hardware under the name of “Dappnode Home”. This solution is a hardware + software bundle that users can purchase and start using right away.

The project was born in 2018 and has, since the start of Ethereum PoS, testnets been most likely the most used solution for home stakers to run validators.

Its users are then assumed to be enthusiasts, solo and home stakers, but also companies and infrastructure providers. Due to the open source nature of the software and the principles of privacy and self-sovereignty that drive the project, there is no telemetry and therefore the picture of Dappnode users is bound to be incomplete.

Dappnode’s approach on staking

Dappnode is a docker-based platform running on top of linux and entirely manageable by the user via GUI, without need of command line, docker knowledge, bash and other DevOps knowledge often associated with running infrastructure.

Dappnode’s UI connects to a Smart Contract repository on Ethereum in order to populate the “Dappstore”, making the usage of Dappnode independent of Dappnode’s team and unstoppable to the extent the Ethereum network is. Its UI displays the packages published in this repository and the user can install it with a couple of clicks and sometimes additional configuration parameters offered through a wizard.

It also offers handy tools to substitute aspects of managing infrastructure that would otherwise be handled by command line tooling: VPN access to the UI to cover remote access to the machine, Wifi Hotspot for access in proximity, access control via login pages and even decentralized auto-updates via processes that query the smart contract for updated packages and install them in order to reduce the complexity of maintenance for users.

Dappnode User base

Because Dappnode captures no telemetry by default in accordance with its principles of self-sovereignty, privacy and optionality, and it runs locally on users’ hardware, it is impossible to get a full picture of Dappnode’s user base.

There are, however, some proxy metrics that can be used to estimate its impact:

Github downloads: 93k downloads on Github - a number that in itself means nothing and can only be used as a reference when comparing with similar tools.

Validators with the word dappnode in its graffiti: Dappnode sets validating_from_DAppNode as a default graffiti, changeable at any point by the user. By searching the proposed blocks for validators that have used this graffiti we can assume that they were, at that point, validators running on Dappnode. Ethseer.io identifies right now around 3300 validators on Dappnode by this metric. Also using the graffiti we can see that validating_from_DAppNode is amongst the 25 most used grafittis:

It is also important highlighting that by this on-chain metric, the graffiti, a great deal of Gnosis Chain is run on Dappnode, as identified by not only the default graffiti but also other big validators identifying themselves as dappnode operators by using the word Dappnode in their graffiti string.

This could be particularly relevant as sometimes Gnosis Chain is seen as a less risky, less expensive gateway to ETH staking and might attract Node Operators that would be able to run Ethereum validators if it weren’t for the high economic barrier of entry. Since both SDVTM and CSM lower this barrier of entry, it is possible that some of these Gnosis Chain Node Operators convert to Ethereum validators with the Dappnode CSM & SDVTM integration.

Social metrics: Our community might also serve as one more data point to form a picture of the relevance of Dappnode: 15.5k followers on twitter and 5.8k discord users.

At the same time, there are a few teams and communities using Dappnode - Aragon, ENS, DVStakers, Kipu Nodes, Ethereum Mexico DVT… - to run infrastructure.

As stated above, the extent of Dappnode’s user base is unknown and undoubtedly larger, but also unquantifiable by design.

Proposal

Summary

The proposed integration is an end-to-end software integration solution with a focus on ease of use and minimizing errors during setup and operation. A new, unified UI will allow accessing information about and managing validators while using Dappnode’s preexisting capabilities of deploying the validator stack.

It includes changes in how Dappnode currently operates to accommodate Lido’s requirements and it puts together a flow that is aimed to be the easiest solution for participating in Lido’s SDVT and CSM modules, just like Dappnode currently aims to be the easiest solution to run a validator.

Integration overview

In the spirit of being an end-to-end solution for users, Dappnode aims for integration at the 4 described tiers in the RFP. Mostly the tiers describe CSM-related features, but we have included SDVTM in Tier 0.

Tier 0. Software Setup Helper - CSM & SDVTM

Dappnode already includes most of the capabilities described in the Tier 0 by default. The Lido module will piggyback on this implementation.

Dappnode will manage the setting up of CL and EL nodes, validator client and MEV-boost, as well as a web3signer and a UI to manage the keys and facilitate changes of consensus client.

Since all this functionality is already existing in Dappnode, it is possible that existing validators are already in operation using the system, so a keystore tag structure will be implemented for Lido validators so the FeeRecipient is fixed to Lido’s without user’s intervention. This facilitates the usage for the user and reduces possibility of error.

Dappnode currently offers users a choice of MEV Boost relays that might or might not coincide precisely with Lido’s allowed relay list. This relay list will be fetched and offered to the user, as well as relays not included in the list will be deactivated when there are Lido active keys in the web3signer.

We don’t consider the key creation suitable to be integrated in Dappnode because there exist perfectly viable tools that cover that need splendidly, but instead we prefer to guide users to use such tools (like wagyu.gg) and perform checks that the Withdrawal Key has been set correctly. This is a tried and tested approach as this is how currently Dappnode functions. Due to Dappnode’s nature of being a 100% online system, it would be not best practise to generate the keys and provide the mnemonic within itself.

Within the scope of Tier 0 would be the installation of extra software depending on the module (SSV or Obol for SDVTM) and most likely lido-specific software that would run adjacent to the validator infrastructure stack that offers handy functionality like automatic exit signing - minimizing again the chances for solo stakers to “forget” to check for exits and being penalized, as well as delaying the normal functioning of the Lido system.

Additionally, Dappnode already includes a configurable telegram bot for alerts that users could use to receive alerts when an exit is required. Integration of these alerts to the bot would be a mix between Tier 1 and 0.

Tiers 1 to 3 - CSM

Tiers 1 to 3 are not necessarily separated in Dappnode’s suggested implementation: a UI that can serve the 3 tiers of operation.

Users would log into this UI with a wallet access, which would then enable several displays of information and the possibility of interacting with the CSM, like alerting of exit requests or of bond disadjustments and need for top-up.

Tier 1. Operator Statistics Monitor mainly consists of “read” functions from the CSM - system information that can be retrieved without log in, and specific information for validators that would be available after log in. This Tier relates closely with the next one as information will be retrieved that needs user action.

Tier 2. Operator Manager. Helps the user interact with the CSM after logging in, being able to add bond, keys, claim reward and set up reward and manager addresses.

Tier 3. Full-featured operator UI. Because displaying information and allowing the user to interact with the CSM is no guarantee that the user is guided properly to join the steps, guiding flows and instructions will be provided along the way. The UI will include helpful explanations and user flows through modals for the most common actions (adding a validator - from adding bond to upload into the web3signer through guidance for key generation and sanity checks on such keys).

The integration in the existing Dappnode UI could also be considered Tier 3, since it is what enables the full flow without the use of command line.

In prevision for more Modules to be created, a potential implementation of how users would access Lido-related modules could be as follows:

Packages would be able to be found in the Dappstore, and a special section would be set up for Lido-specific packages.

The images below are meant to be illustrative and not binding to a particular design. The final deliverable might be different.

Expanding beyond Tier 3, it is important to consider that there is Dappnode hardware (Dappnode Home) that comes with the software pre-installed, meaning that simply by realizing this integration there will be a plug-and-play solution to run SDVTM and CSM. It is not the scope of this proposal to create Lido-specific hardware, but it is worth noting that after this integration is implemented there will be effectively an end-to-end solution.

Requested budget for the integration

The requested budget for the end-to-end integration is of 127,000 USD (payable as USDC or DAI), disbursed as different milestones are reached.

Timelines for the development

Milestones:

The milestones are formulated in terms of user-facing deliverables, being completed when the corresponding package or integration becomes available.

  1. Integration of a Lido section in the Dappstore - 2 weeks - 10%
  2. SDVTM - Obol - 4 weeks - 20%
  3. SDVTM - SSV - 4 weeks - 20%
  4. CSM - 12 weeks - 50 %

Note that milestone 1 will only be relevant whenever there’s any packages in the Dappstore to install, and hence it will be only completed in tandem with at least one of the rest of the milestones.

Maintenance and support

Dappnode has a thriving community and lots of existing users, as well as established channels for community support (and official support for hardware). Support will continue on these channels for users participating in the Lido CSM and SDVTM.

When it comes to the underlying infrastructure of EL and CL clients, Dappnode will continue to curate and update a list of packages that the users can use, as well as Obol and SSV.

Bugs and Defects - Dappnode will actively triage, assess, and deliver fixes for issues found in the parts developed by Dappnode.

Changes by Lido impacting the integration - Minor changes should be supported without issue —however, these changes will need to be assessed on a case-by-case basis. This is a good case for referrals as they keep the interests aligned long-term.

In cases where new updates need to be pushed to the Smart Contract for them to appear in the Dappstore or update the current versions installed by users, Dappnode will cover the cost of the smart contract interaction.

Other Considerations

There are two topics that are adjacent to this proposal, but so deeply intertwined that it would be an omission not to include them here.

Referral

As outlined in @Aleksandra_g ‘s thoughts on a Referral Program, we think that ecosystem partners facilitating the inclusion of Node Operators in SDVTM and CSM through integrations like the one outlined on this proposal but also this one and this one, are perfect candidates to incentivize through this referral program. While the definition of the CSM integration interfaces is an excellent document that sheds light on a lot of the intricacies of the CSM, it offers no guidance on how such a referral program should work.

We believe another interface should be prepared to include a referral identifier that can be injected by the integrator, and that the cost of the referral should never affect the Node Operator, echoing @Alexandra_g’s thoughts.

TeamStaking

Another Dappnode project with ties to Lido would be the #TeamStaking initiative. In Team Staking, we propose an end-to-end solution for teams and communities that includes everything needed for them to validate. The initiative bridges through diverse partners, including hardware, DVT software and liquidity. Given Lido’s dominance in the liquidity aspect, we would like to highlight that should the currently discussed proposal be accepted, participants in TeamStaking could opt in to SDVTM and CSM for the liquidity provision should the partner in question have a need for access to this liquidity:

When we are assessing the needs of the Team to provide them with the end-to-end solution, there might be the case where they either don’t have their own liquidity or they want to leverage the hardware with extra validators to increase the return of the initiative.

We will then assess their options and guide them to apply for SDVTM tests so they can get whitelisted, or to use CSM if they have a minimum amount of liquidity for a bond.

7 Likes

@Lanski thanks for the proposal! I believe it is great.

The only thing that worries me a bit is the price breakdown. For me, SDVTM integration is a bit overpriced, given the proposed target tier (0) of the integration. Also, I’m a bit concerned with the timings for the SDVTM integration. I’m wondering if Lido Section + Obol + SSV can be done in 4 weeks in total?

Hey there @dgusakov ! Thanks for your comments!
Let me address first the timing… and I admit I cheated a bit and included a bit of “retroactive funding” in here: As you know, we’ve been testing SDVT and we are close to something we like for our users. This means that probably it will take less than 4 weeks total. We would love to have the packages ready for the next iteration of SDVTM tests and we will very likely be able to.

Nevertheless I believe the SDVTM integration is deceptive, and ends up being a lot more work than an initial integration. With the high rate of iteration of Obol and SSV teams, we expect it to be a lot more complex than the initial integration. Breaking changes, hotfixes, performance improvements… in our experience, it is the ongoing work that helps keep the entire “fleet” of dappnode runners running smoothly over time - a “decentralized DevOps” work of sorts - that ends up consuming a lot more resources than expected. Bear in mind that when we commit to publishing a package in the dappstore and users start using it, there is an expectation that we will keep updating and maintaining and improving on that package and we commit and honour that. Recapping - in a sense I can understand your concerns about pricing - which are originated by me grouping the integration work with the maintance work. I remain open to discussion and would be more than happy to discuss a separation of the implementation cost from the maintenance cost.

If we dig a little bit deeper, I think a good funding mechanism for these maintenance costs is the referral program as broadly introduced by @Aleksandra_G, but it does not escape me that we would be cross-funding from CSM to SDVTM. Obviously, it would be a lot more aligned if SDVTM would also provide a source of revenue for Dappnode, but I have the feeling that this ship has sailed (correct me if I’m wrong!). If we look at a Lido integration as a whole instead of module-by-module, this cross-funding can make sense.

We fully endorse the integration of SDVTM and CSM modules with Dappnode. At Obol Labs, we’ve collaborated on various projects with Dappode, including the development of a Dappnode <> Obol package and Operation Solo Staker. Through these experiences, we can confidently vouch for their professionalism and dedication as a team.

Dappnode’s mission closely resonates with our own values of simplifying the lives of solo stakers. By providing an end-to-end solution with a unified UI, this integration will enable participation in Lido’s staking modules in a seamless and intuitive fashion, and we look forward to seeing it implemented.

5 Likes

Hey hey @Lanski I’m glad to tell that LEGO council approved the SDVTM part of the proposal!
Could you please provide the address to receive the grant in Ethereum mainnet and confirm the grant payment schedule below?

Milestone Timing Grant, DAI Payment schedule
Integration of a Lido section in the Dappstore (50% for SDVTM) 2 weeks 6,350 Upfront
SDVTM - Obol 4 weeks 25,400 50% upfront, 50% upon completion
SDVTM - SSV 4 weeks 25,400 50% upfront, 50% upon completion

CSM integration to be assessed when CSM specification is finalized.

6 Likes

Hey @Alex_L ! Thanks for reaching out with such great news! Makes sense to me to separate the different parts of the grant too.

The address to receive it would be our multisig: eth:0x53390590476dC98860316e4B46Bb9842AF55efc4

And the grant payment schedule looks good.

3 Likes

GM, the first part of the grant is sent, looking forward to seeing the integration goes live!

2 Likes