Validator’s Note 10 — How to Start Running a Distributed Validator with Obol
Disclaimer: This article is for informational purposes only and should not be taken as financial advice. No information contained within this article is a recommendation to invest in any of the assets mentioned. All investors are advised to thoroughly conduct their own research before making any financial decisions.
Distributed Validator Technology (DVT) is quickly gaining traction, as it not only enhances the decentralization of staking infrastructure but also improves its resilience. DVT essentially enables a group of individuals or operators to collectively run validators for Ethereum on a cluster of nodes. This ensures that the validator can continue operating even if one of the nodes is offline or faulty!
Obol, a well-known project delivering on its promises to make DVT a reality, recently announced their Mainnet Alpha launch. DSRV has been working with Obol since last year on Athena, its first public testnet, and we’ve since maintained an ongoing interest in DVT. From the Athena Testnet to the Bia Testnet (both based on Goerli), we now welcome Alpha– Obol’s successful Mainnet launch.
This Alpha release is focused on testing features on the Ethereum mainnet with selected trial validators, with 25 more clusters to be added in time. DSRV participated as an Alpha launch partner in two multi-org clusters: the first alongside Obol, @Sassal0x and Everlasting; the second with ether.fi, Allnodes, Chainnodes, and Cosmostation.
Let’s have a closer look behind the scenes at our work as an Obol operator.
Before Entering
There are a few different ways to implement DVT. Obol implements DVT via Charon clients and DKG (Distributed Key Generation). Charon is a middleware client that sits between a normal validator client and its associated beacon node, and enables any existing Ethereum clients to operate together as part of a DV (distributed validator). By communicating with other operators, Charon clients are able to reach consensus and behave jointly as a single validator. DKG is implemented in order to split the validator key into several parts so that no one can sign with the validator key unless a quorum (2/3) of partial signatures is collected.
How to Get Started
At this point, you can gather that starting a DV requires an additional step: forming a cluster with other nodes to jointly run a validator and generating keyshares of the validator key.
At Obol, this key creation process is called a DKG Ceremony, and is a prerequisite to running a new validator. And after this, we must wait (as usual) until the validator is activated.
Let’s walk you through this entire process in a bit more detail (using our first DV as an example).
Part 1. DKG Ceremony
- Preparation
First, we had to prepare an ENR (Ethereum Node Record) in addition to our Ethereum account. In a nutshell, an ENR is a kind of address that can be used to represent a node. Charon clients use this info to identify and connect to each other such that they can form a cluster.
2. Joining a DV Cluster
Once this was done, we joined a DV cluster. This essentially entailed listing key info such as our ENR and Ethereum account, and waiting for other operators to join. Once all members of the cluster joined, we were able to create a cluster-definition.json file, which is then used as input for the DKG ceremony.
3. Running a DKG Ceremony
After the cluster was formed, we began the DKG ceremony using our ENR and cluster-definition file. While the DKG requires all operators in a cluster to be active at the same time, the ceremony itself can be run asynchronously. As long as operators leave their machine running once activated, the DKG will be executed once every party onboards. We received the files below when the DKG ceremony was completed.
cluster-lock.json: This contains the information needed by Charon to operate a distributed validator cluster with its peers.deposit-data.json: This contains the information needed to activate the distributed validator on the Ethereum network.validator_keys: This folder contains the private keyshares and passwords for each member of a DV.
We also had to verify that the data in deposit-data.jsonandcluster-lock.json were the same across all operators, as well as safeguard the validator_keys from others.
4. Starting Charon and the Validator Client
The next step was running .charon and validator_keys on the Charon and validator client.
Part 2. Validator Activation
Once the DV was set up and 32 ETH deposited, it took about 26 hours to be activated. This process looks the same for regular validators. To summarize:
- 32 ETH was deposited on the DV. At this time, the status of our DV changed to deposit.
- There was then a wait of 2048 blocks + 64 epochs to ensure the fund was not re-orged. After 14 hours, our DV status changed to pending.
- While the deposit was recognized by the Beacon Chain, as only 6 validators can be activated per epoch, the rest must wait in a queue. The wait differs depending on the number of total deposits. Our DV took 12 hours to become active.
Conclusion
One key thing we noticed when running a DV is that communication within the cluster is critical. Although DVT grants validators more fault tolerance, we still had to maintain our connection with the other operators to share any issues that arose. For instance, if only two operators within a cluster of four update their clients, the validator will not be able to do its job.
Both our DVs are now running on Mainnet– you can view Validator 556545 and Validator 559135 here. While they haven’t proposed blocks yet, they’ve maintained excellent effectiveness rates of 99% and 100% respectively. And there you go! Thanks to the Obol team and their streamlined launchpad, we were able to complete this process quite easily. Excited to see what comes next for Obol!
Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)
Jinhong Choi, Software Engineer, DSRV Validator Team (Twitter @_Gnong)
Edited by
Domitille Colin, Brand Communications Manager (Twitter @domitille_marie)
