Background
As most of our user base is already aware, we’ve been unable to expand our ETH2 infrastructure services of running beacon nodes and validating beyond the use of Prysmatic Labs’ Prysm client. While we all appreciate Preston Van Loon and the team’s work to be the first ETH2 client with a functional WebUI that really lowers the barriers to entry to staking, the health and even the actual rollout of ETH2 depends on client diversity. Without this diversity, a single bug or breaking change in the primary client (currently this is still Prysm) will result in a large proportion of the network going offline, making it vulnerable to attack and breaking into different chains, or even stoping production of blocks altogether. So to make the network more resilient, we need more clients and to have a relatively even distribution of each different client for maximum network resiliency. It is for this reason that each time you run through the ETH2 Launchpad, it will suggest a different validator client and include a relevant guide near the end of the process to setup your new validator on a new client.
Issue
Here at DAppNode we have our own ethos and goals which include helping to truly decentralize the next iteration of Ethereum. So far, we are working to decentralize staking away from larger centralized stake pools and exchanges that offer staking services for their clients. To do this effectively and not scare off the much larger share of the community who are tech-savvy, but not programmers or familiar with Linux, or comfortable doing work on a headless (no GUI) machine with all interface through command line interfaces, the team made a decision to try to simplify and help lower barriers to entry for all users by creating DAppNode, and the WebUI that allows most users to install a handful of chains and validate more than one type of asset, without ever touching command line. The users don’t have to know how docker needs to be installed, or how any of the many core apps work under the hood (All core packages remain open source, so anyone with the desire can dig in and still see everything). Instead of needing to type out commands to install a new package and find that package on GitHub or IPFS, all the user needs to do is go to the DAppStore, click on a package and then click install to fully install the package and get it ready to run. Another click and you can see live logs, etc. This really lowers the barriers to entry compared to running a headless linux box, since you no longer need to write your own custom config files for each package you run; simply fill out the form in the WebUI and the config file is populated and loaded into the program. The commitment to this goal of lowering the technical barriers to entry are fundamental to the project’s success, and by extension even the Whole Ethereum Ecosystem, as we are some of the infrastructure providers for ETH2. Unfortunately, by sticking to this goal so tightly for the last year, we’ve come to realize some of our hopes aren’t materializing as quickly as expected; mainly that the dev teams behind the alternative ETH2 clients such as Teku, Nimbus, and Lighthouse would have integrated a simple WebUI for key/wallet management, similar to Prysm’s webUI that has more features than just key/wallet management. We saw this addition of a webUI as a need before we could integrate the other clients into our stack, since going without such a WebUI would require more advanced knowledge for setup than just using the DAppNode web interface, something that would now raise the barriers to entry. At this point it’s become clear we must charge on ahead without waiting for the respective dev teams to integrate such webUIs to their clients.
Proposal
For this reason I propose the first major grant(s) of the newly created DAppNode DAO to fund our own devs and builders to integrate these alternate clients into the DAppNode Stack. I propose that the MVP (minimum viable product) of each client should have a simple webUI that allows for keystores to be easily uploaded to the client’s wallet and be properly password protected with a different password than was used to secure the keystore. I believe that this MVP would be sufficient to getting those who want to run alt clients ASAP their opportunity to do so. The next step after the MVP would be to improve the client’s UI, but more importantly, we need to have someone with Grafana experience either create a new dashboard to monitor validator performance, or fork the wonderful Grafana Dashboards built by metanull-operator for prysm to work with the various new clients we add.
Lanski will be following up this post (after he returns from Holiday) with an in-depth situation report so we can determine exactly what work we need done for each grant/client. But in the meantime let’s get some discussion going on this topic, and soon we will be able to vote on it and create the grants needed to bring ETH2 client diversity to DAppNode.