Start your DV Node
Last updated
Last updated
Great job on completing the DKG! Now it's time to start your Distributed Validator (DV) node. This step is crucial as it prepares your node for validating over the long term. When you access the cluster details, you will see the "Start DV node required" status and the action required prompt as shown below:
Click on the Start your DV node button to proceed.
Once you click the button, you will have two options to choose from:
Full Node Setup:
use the default configuration provided by Obol. The CDVN repository is configured to sync an execution layer client (Nethermind) and a consensus layer client (Lighthouse) using Docker Compose.
Existing Beacon Node Setup:
you already have a beacon node running somewhere and you want to use that instead of running an EL (Nethermind) & CL (Lighthouse) as part of the example repo, you can disable these images.
Each option has its specific steps to follow.
Full Node Setup
Go to the charon-distributed-validator-node folder you created before
Copy .env.sample and rename it to .env
Configure MEV-Boost Relays (Optional but recommended):
Running a distributed validator cluster with a builder API enabled gives the validators in the cluster access to the builder network. This builder network is made up of "Block Builders" who work with MEV searchers to produce the most valuable blocks a validator can propose.
What is MEV-Boost? MEV-Boost allows you to access a competitive block-building market. With MEV-Boost, validators can access blocks from a marketplace of builders. Builders produce blocks containing transaction order flow and a fee for the block proposing validator. It is a product from Flashbots that allows validators to request blocks from multiple relays that communicate with these "Block Builders." The relay offering the most profitable block is chosen, and the validator signs and returns it to the relay for broadcasting to the wider network. This generally results in an increased APR for the validator as they receive a share of the MEV rewards.
For more information, visit the Flashbots MEV-Boost documentation.
To configure MEV-Boost:
Choose one or more relays from the list of available MEV-Boost relays.
Edit your .env file and add the relay URLs to the MEVBOOST_RELAYS variable. Use commas to separate multiple relays:
Note: Validators within the same cluster do not need to use the same relays.
Save your changes to the .env file
Delete lighthouse data if it exists, and spin up a Distributed Validator Node with a Validator Client
Open Grafana dashboard to monitor your node with this command
This command will open a dashboard that provides a comprehensive overview of your node's performance.
On this dashboard, you’ll find a wealth of useful information to track your DV node, but the most critical section is the table highlighted in purple.
Obol assigns a random identifier to each user. In this example, my identifier is innocent-teacher because I am listed in the first row, and my row is marked with a star in the highlighted column.
We encourage you to explore all the features of the Grafana dashboard. Among other insights, you can analyze your node’s relative latency compared to other operators and review various success metrics for each participant.
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)
Once you have completed the setup for either option, click the I started the DV node button to confirm.
Now, you can communicate with the other operators in your private Discord channel to monitor the progress and ensure everyone has completed their part.
This process ensures that your DV node is properly set up and ready for validating, moving you closer to full activation and earning rewards.
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)
