Distributed Validator Chart

[OisinKyne]

🎯 Problem to be solved

We want a setup to manage the full lifecycle of (multiple) DV pods (charon+vc combos).

🛠️ Proposed solution

I think first thing to get right is a chart that handles one DV pod from end to end. We can install it multiple times.

We may make iterations of this design that get more end to end automated. Namely we might not put the operator private key in this chart to start, and we will stick to just the charon hot keys (ENRs) rather than the addresses that are typically metamask/ledger/soon safes etc. Instead we will take the public address for the operator and assume that user is interacting with the launchpad as normal.

The chart needs values for:

• The Ethereum address for their operator. i.e. the address on the launchpad it should look out for.

When installed, the chart should:

• Generate an ENR if one is not passed to it in a values file. Store it in a k8s secret.
• It should log the ENR public key in the templated notes.txt that helm outputs. Telling the user to submit this ENR public key in the cluster acceptance flow on the Launchpad.
• It should poll for cluster invites for the passed in operator address.
  • It potentially could check and ignore definitions where a matching lock file already exists.
  • It should look through all definitions, and see if it can find one where its generated ENR has been signed by its passed in operator address. That indicates that the user has completed the LP flow and used this Pod's ENR public key in sign up.
  • It should wait for the cluster definition to be fully signed by all operators, and be ready for DKG.
  • It should start a DKG process when the definition is ready.
  • It should retry the definition process if it exits with non-zero
  • It should store the dkg artifacts in a PV (using a PVC?)
  • It should start up the charon runtime container
  • It should start up a validator client containter

🧪 Tests

• Test steps or automation scripts are provided
• The chart is deployed to the test environment successfully

👐 Additional acceptance criteria

• The helm chart is published to this repository
• The chart docs are updated
• The chart is released to live environments (if applicable)
• Calling exit commands on the charon pod in this chart is documented

❌ Out of Scope

• For the first iteration, this chart won't handle the operator (cold key) phase
• For the MVP, this chart won't do validation of the execution layer side of these cluster invites, to assert, for example, that the fee recipient is a splitter the operator address is included in.

[OisinKyne]

@apham0001 lets chat about this on the next sync and see if its fleshed out enough to attempt.

[apham0001]

If the ENR is not provided by the user, we can generate it in an initContainer and store it in a Kubernetes Secret. We'll expose the public ENR in the Helm NOTES.txt, so the user can submit it to the Launchpad as part of the cluster registration process.

For the DKG process, we can use a post-install Helm hook that runs a Job. This Job will wait for the cluster invite, validate the ENR has been signed by the operator address, and run DKG once the definition is ready. It will output artifacts to a PVC, which the Charon containers can consume.

[bussyjd]

NOTE:
For operator addresses that are invited to several cluster:

Add an override for the cluster config has you are looking to join if you have several invites and start the most recent one as a default to start.
@LukeHackett12