Distributed Validator Key Generation
Contents
- Overview
- Actors involved
- Cluster Definition creation
- Carrying out the DKG ceremony
- Backing up ceremony artifacts
- Preparing for validator activation
- DKG verification
- Appendix
Overview
A distributed validator key is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus.
To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together. (4 randomly chosen points on a graph don't all neccessarily sit on the same order three curve.) To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a distributed key generation ceremony.
The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a cluster definition.
Actors Involved
A distributed key generation ceremony involves Operators
and their Charon clients
.
-
An
Operator
is identified by their Ethereum address. They will sign with this address's private key to authenticate their charon client ahead of the ceremony. The signature will be of; a hash of the charon clients ENR public key, thecluster_definition_hash
, and an incrementingnonce
, allowing for a direct linkage between a user, their charon client, and the cluster this client is intended to service, while retaining the ability to update the charon client by incrementing the nonce value and re-signing like the standard ENR spec. -
A
Charon client
is also identified by a public/private key pair, in this instance, the public key is represented as an Ethereum Node Record (ENR). This is a standard identity format for both EL and CL clients. These ENRs are used by each charon node to identify its cluster peers over the internet, and to communicate with one another in an end to end encrypted manner. These keys need to be created by each operator before they can participate in a cluster creation.
Cluster Definition Creation
This definition file is created with the help of the Distributed Validator Launchpad. The creation process involves a number of steps.
- A
leader
Operator, that wishes to co-ordinate the creation of a new Distributed Validator Cluster navigates to the launch pad and selects "Create new Cluster" - The
leader
uses the user interface to configure all of the important details about the cluster including:- The
withdrawal address
for the created validators - The
feeRecipient
for block proposals if it differs from the withdrawal address - The number of distributed validators to create
- The list of participants in the cluster specified by Ethereum address(/ENS)
- The threshold of fault tolerance required (if not choosing the safe default)
- The network (fork_version/chainId) that this cluster will validate on
- The
- These key pieces of information form the basis of the cluster configuration. These fields (and some technical fields like DKG algorithm to use) are serialised and merklised to produce the definition's
cluster_definition_hash
. This merkle root will be used to confirm that their is no ambiguity or deviation between definitions when they are provided to charon nodes. - Once the leader is satisfied with the configuration they publish it to the launchpad's data availability layer for the other participants to access. (For early development the launchpad will use a centralised backend db to store the cluster configuration. Near production, solutions like IPFS or arweave may be more suitable for the long term decentralisation of the launchpad.)
- The leader will then share the URL to this ceremony with their intended participants.
- Anyone that clicks the ceremony url, or inputs the
cluster_definition_hash
when prompted on the landing page will be brought to the ceremony status page. (After completing all disclaimers and advisories) - A "Connect Wallet" button will be visible beneath the ceremony status container, a participant can click on it to connect their wallet to the site
- If the participant connects a wallet that is not in the participant list, the button disables, as there is nothing to do
- If the participant connects a wallet that is in the participant list, they get prompted to input the ENR of their charon node.
- If the ENR field is populated and validated the participant can now see a "Confirm Cluster Configuration" button. This button triggers one/two signatures.
- The participant signs the
cluster_definition_hash
, to prove they are consensting to this exact configuration. - The participant signs their charon node's ENR, to authenticate and authorise that specific charon node to participate on their behalf in the distributed validator cluster.
- The participant signs the
- These/this signature is sent to the data availability layer, where it verifies the signatures are correct for the given participants ethereum address. If the signatures pass validation, the signature of the definition hash and the the ENR + signature get saved to the definition object.
- All participants in the list must sign the definition hash and submit a signed ENR before a DKG ceremony can begin. The outstanding signatures can be easily displayed on the status page.
- Finally, once all participants have signed their approval, and submitted a charon node ENR to act on their behalf, the definition data can be downloaded as a file if the users click a newly displayed button,
Download Manifest
. - At this point each participant must load this definition into their charon client, and the client will attempt to complete the DKG.