Create a DV With a Group
This quickstart guide will walk you through creating a Distributed Validator Cluster with a number of other node operators.
Last updated
Was this helpful?
Version-v1.4.0 (current)
This quickstart guide will walk you through creating a Distributed Validator Cluster with a number of other node operators.
Last updated
Was this helpful?
A basic of Ethereum nodes and validators.
A machine that meets the for the network you intend to validate.
If you are taking part using a :
A computer with an up to date version of 's software and an internet connection.
If you are taking part using , or (CDVN) starter repo:
Ensure you have installed.
Ensure you have installed.
Make sure docker is running before executing the commands below.
In order to prepare for a distributed key generation ceremony, you need to create an ENR for your Charon client. This ENR is a public/private key pair that allows the other Charon clients in the DKG to identify and connect to your node. If you are creating a cluster but not taking part as a node operator in it, you can skip this step.
You should expect to see a console output like this:
Please make sure to create a backup of the private key at .charon/charon-enr-private-key Be careful not to commit it to git! If you lose this file you won't be able to take part in the DKG ceremony nor start the DV cluster successfully.
If instead of being shown your enr you see an error saying permission denied then you may need to to allow the command to run successfully.
For Step 2 of the quickstart:
Select the Creator tab if you are coordinating the creation of the cluster (this role holds no position of privilege in the cluster, it only sets the initial terms of the cluster that the other operators agree to).
Select the Operator tab if you are accepting an invitation to operate a node in a cluster, proposed by the cluster creator.
Collect addresses, configure the cluster, share the invitation
Before starting the cluster creation process, you will need to collect an Ethereum address for each operator in the cluster. They will need to be able to sign messages through MetaMask with this address. (Broader wallet support will be added in future.) With these addresses in hand, go through the cluster creation flow.
The following are the steps for creating a cluster.
Connect your wallet
Select Create a Cluster with a group then Get Started.
Follow the flow and accept the advisories.
Configure the Cluster
Input the Cluster Name & Cluster Size (i.e. number of operators in the cluster). The threshold will update automatically, it shows the number of nodes that need to be functioning for the validator(s) to stay active.
Input the Ethereum addresses for each operator that you collected previously. If you will be taking part as an operator, click the "Use My Address" button for Operator 1.
Select the desired amount of validators (32 ETH each) the cluster will run. (Note that the mainnet launchpad is restricted to one validator for now.)
Enter the Principal address which should receive the principal 32 ETH and the accrued consensus layer rewards when the validator is exited. This can optionally be set to the contract address of a multisig / splitter contract.
Enter the Fee Recipient address to which the execution layer rewards will go. This can be the same as the principal address, or it can be a different address. This can optionally be set to the contract address of a multisig / splitter contract.
Click Create Cluster Configuration. Review that all the details are correct, and press Confirm and Sign You will be prompted to sign two or three transactions with your MetaMask wallet. These are:
The config_hash. This is a hashed representation of the details of this cluster, to ensure everyone is agreeing to an identical setup.
The operator_config_hash. This is your acceptance of the terms and conditions of participating as a node operator.
Your ENR. Signing your ENR authorises the corresponding private key to act on your behalf in the cluster.
Share your cluster invite link with the operators. Following the link will show you a screen waiting for other operators to accept the configuration you created.
You can use the link to monitor how many of the operators have already signed their approval of the cluster configuration and submitted their ENR.
Once every participating operator is ready, the next step is the distributed key generation amongst the operators.
If you are not planning on operating a node, and were only configuring the cluster for the operators, your journey ends here. Well done!
If you are one of the cluster operators, continue to the next step.
Once all operators successfully signed, your screen will automatically advance to the next step and look like this. Click Continue. (If you closed the tab, you can always go back to the invite link shared by the leader and connect your wallet.) \
Copy and run the docker command on the screen into your terminal. It will retrieve the remote cluster details and begin the DKG process. \
Assuming the DKG is successful, a number of artefacts will be created in the .charon folder of the node. These include:
A deposit-data.json file. This contains the information needed to activate the validator on the Ethereum network.
A cluster-lock.json file. This contains the information needed by Charon to operate the distributed validator cluster with its peers.
A validator_keys/ folder. This folder contains the private key shares and passwords for the created distributed validators.
Please make sure to create a backup of your .charon/ folder. If you lose your private keys you won't be able to start the DV cluster successfully and may risk your validator deposit becoming unrecoverable. Ensure every operator has their .charon folder securely and privately backed up before activating any validators.
Now that the DKG has been completed, all operators can start their nodes.
With the DKG ceremony over, the last phase before activation is to prepare your node for validating over the long term.
Start by copying the appropriate .env.sample.<NETWORK> file to .env, and modifying values as needed.
Do not start this node until the DKG is complete, as the charon container will interfere with the charon instance attempting to take part in the DKG ceremony.
If at any point you need to turn off your node, you can run:
You should use the Grafana dashboard that accompanies the quickstart repo to see whether your cluster is healthy.
In particular you should check:
That your Charon client can connect to the configured beacon client.
That your Charon client can connect to all peers directly.
That your validator client is connected to Charon, and has the private keys it needs loaded and accessible. Most components in the dashboard have some help text there to assist you in understanding your cluster performance. You might notice that there are logs indicating that a validator cannot be found and that APIs are returning 404. This is to be expected at this point, as the validator public keys listed in the lock file have not been deposited and acknowledged on the consensus layer yet (usually it takes ~16 hours after the deposit is made).
Install the Obol DappNode package
Installing Sedge
First you must install Sedge, please refer to the to do so.
Check the install was successful
You will use the Launchpad to create an invitation, and share it with the operators. This video shows the flow within the
Go to the
If you are taking part in the cluster, enter the ENR you generated in in the "What is your charon client's ENR?" field.
Review the cluster configuration set by the creator and add your ENR that you generated in .\
For the to complete, all operators need to be running the command simultaneously. It helps if operators can agree on a certain time or schedule a video call for them to all run the command together.
The is configured to sync an execution layer client (Nethermind) and a consensus layer client (Lighthouse) using Docker Compose, further client combinations can be prepared using Sedge. You can also leverage alternative ways to run a node such as Ansible, Helm, or Kubernetes manifests.
Currently, the has defaults for the Holesky testnet and for mainnet.
Sedge generate
The following command generates the artifacts required to deploy a distributed validator on the Holesky network, using Teku as the validator client, Prysm as the consensus client, and Geth as the execution client. For additional supported client combinations, .
Sedge Import-key
Sedge Run
If you encounter issues with using Sedge as part of a DV cluster, consider consulting the directly, or opening an or if appropriate.
Use an ansible playbook to start your node. for further instructions.
Use a Helm to start your node. for further instructions.
Use Kubernetes manifests to start your Charon client and validator client. These manifests expect an existing Beacon Node Endpoint to connect to. for further instructions.
In a Distributed Validator Cluster, it is important to have a low latency connection to your peers. Charon clients will use the NAT protocol to attempt to establish a direct connection to one another automatically. If this doesn't happen, you should port forward Charon's p2p port to the public internet to facilitate direct connections. The default port to expose is :3610. Read more about Charon's networking .
If you have gotten to this stage, every node is up, synced and connected, congratulations. You can now move forward to to begin staking.
