Key links

• DKG Tutorial Video
• Submit files form - to be completed by the cluster captain after a successful DKG ceremony.
• Quickstart Guide Repo
• Link to join the Discord

Overview

First of all, thank you! We have been overwhelmed with the interest in Obol’s first public testing effort on Görli, called Athena, with more than 4,500 respondents across 40+ countries. The goal of this testing program is to collect public network performance data on Charon, our Distributed Validator Technology (DVT) middleware. With this level of interest in testing Charon we are confident that we'll make the Obol Network more robust, bringing forward our goal of fostering trust minimized staking through multi-operator validation

As a reminder, these are the different phases for Athena. They each correspond to a specific step required to successfully run a DV through Charon, and roughly match our Quickstart guide.

• Phase I: Testing Registration and ENR Generation (Concluded)
• Phase II: Coordination of Distributed Key Generation (DKG) Ceremonies
• Phase III: Validators Activation and Operation
• Phase IV: Validator Exits, Athena Completion & Performance Analysis

For the remainder of this post, we’ll cover the details of Phase II & III

Phase II: Coordination of DKG Ceremonies

Charon can be used by groups of people (typically 4 to 10) to run distributed validator clusters together. The main synchronous event in the lifecycle of a distributed validator is the key generation ceremony. This process creates key shares in a secure manner with no single party ever knowing the full private key. Every operator in the cluster needs to take part in this ceremony to receive their key shares.

To scale this coordination effort, we will offer two tracks for coordinating these ceremonies.

Tracks

Communities

We realize that trusting individuals you have never met before to run a DV together can be daunting. We also acknowledge that many strong Ethereum communities already exist and we want to capitalize on them. This is why we will start the rollout of these ceremonies by organizing DKG workshops with the communities you told us you belong to in the sign up process (e.g. Node Operator Association, Lido, EthStaker, Rocketpool, SheFi, She256, Bankless etc.)

In these workshops, we will cover Step 1 to 3 of setting up a DV as per Obol’s Quickstart. Most of you will have already completed Step 1 of this process when registering your interest in the Athena signup typeform. You will be grouped with operators with a similar profile to yourself, and at the end of the workshop you will have a chance to decide whether you wish to follow through and activate your DV on testnet as a team.

To take part in your community’s workshop, just stay tuned to your community’s Discord where we’ll announce dates and logistics.

Self-organized

We like to think about the operators in this track as adventurers since you will directly choose who you will be grouped with in the cluster. One way to think about this is to run a cluster with your friends. Another way is to self-organize into clusters with like-minded people.

In both cases, you coordinate on your own and we’ll verify your cluster validity before activating it through the deposit files submitted by the Cluster Captain, who will be particularly important in this track (more on this below). Indeed, Captains will also have to perform Step 2 of the quickstart before coordinating the DKG (Step 3) with their clusters.

The Obol Team will open dedicated Discord channels to facilitate this coordination and be present on Discord to answer questions related to the DKG. You can find an overview of the DKG process in this video:

Concepts

Artifacts created

When all operators have taken part in the DKG, the following information is produced:

1. Every operator receives their private key shares for the distributed validator which can then be loaded into their validator client.
2. A cluster-lock file is produced, which outlines all of the distributed validators this cluster will operate. This file contains information used by Charon to coordinate a cluster, and will be used by the Obol Team to verify that a distributed validator was properly created.
3. A validator deposit data file will be produced, this file contains the information needed to activate the validator on the validator launchpad.

Cluster Captains

One operator per cluster will be (self-)designated as this cluster’s captain. This person will have the important responsibility of uploading the deposit and the cluster lock files with the Obol Team to allow us to validate the cluster and activate the validator. They can do so in this typeform:

Cluster Captains will also be the accountable point of contact for their cluster for the duration of the testing program.

Requirements

Please remember that taking part in this testing will require you to;

• Run Obol’s Charon client, along with Goerli consensus, execution and validator clients for 30 or more days.
• Exit this validator from the validator set upon testing completion.

Phase III: Validators Activation and Operation

Once the Obol Team receives the distributed validator deposit data from each Cluster Captain, we will send that data to the Eth2 deposit contract along with 32 ether to begin the process of activation.

Since this is a manual process, we will submit validators for activations in waves, likely once a week. Once submitted, the validator then needs to go through the activation queue which can take up to a few days, as of writing.

While waiting for activation, the node operators (via their Cluster Captain) will receive periodic check-ins from the Core Team to ensure that they will be ready to validate for this validator once it becomes active. Operators will be asked to confirm that they have testnet beacon clients synced, and that they have opened the required ports to the public internet for each Charon node to communicate with one another.

All going well and once the validator is activated, the distributed validator cluster will begin its operation. The intention is to run this testing effort for 28 days.

Conclusion

As we close Phase I of our testing efforts and move into Phase II & III, we are excited to have you with us on the Athena Journey. While human coordination can be an overhead, it is required to make Ethereum more resilient.

Let’s build Distributed Validators around the globe together!

Disclaimers

Charon is an early alpha client software and is not ready for use on mainnet. It currently needs to become more user-friendly, resilient and battle-tested. If you opt to take part in this testing, it is to improve a core technology in the battle to keep proof of stake Ethereum decentralized. Applicants should not take part in this testing program with the expectation of any compensation.