The Obol Core Team has been heads-down the last few months building out our Distributed Validator Middleware Client and running internal devnets.

The time has come for Charon to be tested by a larger community of Node Operators. Today we are announcing Obol's first public testing effort on the Goerli testnet, which we are calling Athena, as part of our roadmap towards a mainnet-ready client.

Overview & tl;dr

• Testnet journey
• Future testnet efforts
• Mainnet readiness
• Disclaimers
• Testnet sign up form
• Discord community
• Hiring page

The Athena Journey on Goerli testnet

Distributed Validator Technology (DVT) allows one Ethereum validator to run across multiple machines. In theory, all of these machines could be controlled by a single entity, however, we aspire to use DVT amongst groups, where a combination of operators collaborate to run Ethereum validators. With that in mind, this and future testnet programs will require groups of humans to collaborate together to run nodes. This will be a larger overhead, but also something that is required to make Ethereum more resilient, and to promote decentralization. The Obol Network aims to foster trust minimized staking in groups, to enable people to create, test, run & coordinate distributed validators.

Taking part in this testing program will see you paired with other node operators around the world to work together, something I hope will result in a stronger, more interconnected Obol community.

Running distributed validators as part of a group means that there is at least one synchronous occasion where the group of operators have to come together and perform a Distributed Key Generation (DKG) ceremony. Other than that, all other activities should be completable in an asynchronous manner.

This journey on Goerli testnet will look like the following:

Phase I

The testnet intake form opens. This form will ask for information like your rough geolocation to pair you with other operators. You will need to run the Charon client briefly to generate an ENR private key for use in a scheduled Distributed Key Generation ceremony. We will ask for some personal information as part of this process to mitigate the chances of Sybil attacks. For this reason, please fill out the form only once. Furthermore, signing up for testing via the intake form does not guarantee selection.

Phase II

Once we have received our initial cohort of applications, the next phase will be to coordinate distributed key generation ceremonies amongst participants. Each selected testing applicant will receive communication from the Obol Core Team informing them of the cluster of operators they have been allocated to. These operators will have a 7-day window to coordinate a call or time that they will perform a DKG together. This process will only take a couple of minutes, assuming all goes well.

When all operators take part in a DKG the following information is produced:

• Every operator receives their private key shares for the distributed validator. Then, they load these files into their validator client.
• A cluster lock file is produced, which outlines all of the distributed validators this cluster will operate for. This file contains information used by Charon to coordinate a cluster, and will be used by the Core Team to verify that a distributed validator was actually created.
• Validator deposit files will be produced to activate the validator with the deposit contract.

One operator will have to upload the deposit files and the cluster lock file with the Obol Core Team via a second Typeform (which we'll share in due time), thus setting the stage for the distributed validator to be activated.

Phase III

As of writing, there are currently ~18,000 validators in the Prater activation queue. This means that each validator will need to wait approximately two weeks before being activated. Once the Obol Team receives the Distributed Validator deposit data from each operator's DKG ceremony, we will send that data to the deposit contract along with 32 ether to begin the process of activation.

While waiting in the activation queue, the node operators 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.

If all is going well and once the validator is activated, the distributed validator cluster will begin its operation. The intention is to run on testnet for 28 days.

Phase IV

After approximately a month of operation, we will consider this Athena testing effort to be complete. The final task for operators will be to be good stewards and to exit their validator from the network rather than just turning it off without exiting. All operators that successfully exit their validator will score higher on their performance than operators that fail to exit their validator properly.

At this point, the Athena testing program is complete. The Core Team will spend several weeks collating information and analysing the observed performance of all distributed validators. Performance will be scored and a comprehensive research post will be published outlining the strengths and weaknesses identified in the client and the entire UX flow of creating and running a distributed validator.

This date also coincides with the beginning of Dappcon (12-14 Sep) and EthBerlin (16-18 Sep). The Obol team will be sponsoring and presenting at both events and we intend to invite testing program participants to a wrap-up event during that week in Berlin. More details to follow.

Future Testing Efforts

The testing roadmap of Obol is outlined in more detail here. The immediate next testing goal is to run an attack testnet effort focused on finding more issues with Charon when it is under attack. This will be known as the Bia Attack Effort and will be rolled out in partnership with a bug bounty platform. After that, the intention is to run distributed validators at scale on the Gnosis chain, for a skin-in-the-game, higher load, and higher stakes public testing effort named Cerce.

Mainnet Readiness

The following is an outline of how the Obol Core Team is looking at mainnet readiness of Charon and its surrounding tooling and smart contracts. This list is not exhaustive and may be added to in the future.

• Public testing efforts completed on Goerli + Gnosis Chain (aka the happy path). The client should be stable and easy to use and debug, and a validator should be as profitable as a normal single instance validator.
• Attack testnet efforts and red/blue nets completed (aka the unhappy path). The client should be DoS resistant and impersonation resistant. Operators should be able to rotate Charon keys if needed/compromised. Validator exit should be easy in the scenario that a cluster is failing to stay online.
• Charon has been audited.
• Any custom smart contracts that surround the deposit contract are audited.
• The DV Launchpad is complete and operators can self-service their way through the entire flow of creating and activating a distributed validator.
• Charon performance monitoring is clear and accessible. Understanding what operator in a cluster is offline or under-performing should be easy to identify and rectify.
• Network upgrade resilience. Charon clients should be able to operate through a planned network upgrade such as the Capella hard fork without issue.
• LMD-GHOST protocol with proposer boost support. Currently, Charon's BFT consensus doesn't consider if a leader's proposed block is optimal with respect to the fork choice rule, to be fully mainnet ready, distributed validators should be cognizant of the 'proper' block to be proposed considering fork-choice. Not doing so could potentially allow a byzantine member of a DV cluster to attempt short re-orgs by convincing the cluster to propose a valid block that is not the most correct as per fork-choice. This could hamper the network stability, and the validator's profitability if it regularly proposes sub-optimal blocks that get forked out.
• MEV-Boost/PBS readiness. Related to block proposal challenges, being able to support blinded beacon blocks and MEV-boost or relayers is a requirement for mainnet readiness.
• Version negotiation. Charon clusters need to be able to coordinate their protocol upgrades smoothly, upgrading to the latest protocol spec supported by all nodes in the cluster once all clients are running a software version that supports the proposed protocol version.
• All duties are completed. Charon currently supports attestations and block proposals. Aggregations and both sync committee duties need to be complete for mainnet readiness. More to come on this in a future blog post.

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 effort, 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 with the expectation of any compensation.

Furthermore, testing participants will be grouped with other node operators to run distributed validators together as part of a team. If you do not intend to complete the testing program, it could make it impossible for your cluster operators to successfully complete the program without you. Please do not take part in the testing program unless you meaningfully believe you will be able to run a node for upwards of two months. Insufficient performance will put your reputation and inclusion in future Obol network activities at risk.

Sign up

If the above sounds good to you, and you are keen to get involved in Obol's first testnet, register your interest in the following Typeform and join our Discord. We will be in touch when the time comes to set up a distributed validator. Great to have you on board!