In order to maintain security and sybil-resistance, charon clients need to be able to authenticate one another. We achieve this by giving each charon client a public/private key pair that they can sign with such that other clients in the cluster will be able to recognise them as legitimate no matter which IP address they communicate from.
Authenticating a distributed validator client
Before a DKG process begins, all operators must run
charon create enr, or just
charon enr, to create or get the Ethereum Node Record for their client. These ENRs are included in the configuration of a Distributed Key Generation ceremony.
The file that outlines a DKG ceremony is known as a
cluster-definition.json file. This file is passed to
charon dkg which uses it to create private keys, a
cluster-lock.json file and
deposit-data.json for the configured number of distributed validators. The
cluster-lock file will be made available to
charon run, and the validator key stores will be made available to the configured validator client.
charon run starts up and ingests its configuration from the
cluster-lock.json file, it checks if its observed/configured public IP address differs from what is listed in the lock file. If it is different; it updates the IP address, increments the nonce of the ENR and reissues it before beginning to establish connections with the other operators in the cluster.
Distributed Validator Clusters are permissioned networks with a fully meshed topology. Each node will permanently store the ENRs of all other known Obol nodes in their node database.
Unlike with node databases of public permissionless networks (such as Go-Ethereum), there is no inbuilt eviction logic – the database will keep growing indefinitely. This is acceptable as the number of operators in a cluster is expected to stay constant. Mutable cluster operators will be introduced in future.
At boot, a charon client will ingest its configured
cluster-lock.json file. This file contains a list of ENRs of the client's peers. The client will attempt to establish a connection with these peers, and will perform a handshake if they connect to establish an end to end encrypted communication channel between the clients.
However, the IP addresses within an ENR can become stale. This could result in a cluster not being able to establish a connection with all nodes. To be tolerant to operator IP addresses changing, charon also supports the discv5 discovery protocol. This allows a charon client to find another operator that might have moved IP address, but still retains the same ENR private key.