Spike on generic exits

[xenowits]

🎯 Problem to be solved

We need to do a technical spike to figure out possible approaches to support generic exits (see PRD).

🛠️ Proposed solution

Spike to see if we can craft a generic solution to the problem of exiting distributed validators. The output of this spike should be a design doc containing the research findings.

Note that we also have a design doc that could be useful for this spike.

🧪 Tests

None

[gsora]

Document detailing a generic approach is available here: https://docs.google.com/document/d/1f5k0IduzndNBWldmfcGhyxxiWjVjo4CeqTOFg0-py4M/edit#heading=h.mssb0822zapb

[gsora]

The charon exit submit-partial-exit command

This Charon command is a middle ground between a lido-dv-exit-style deployment and full manual exit through the beacon node.

charon exit submit-partial-exit submits a partial exit for a specified validator through the CLI, and uses Obol API as its aggregation point -- just like lido-dv-exit.

An accessory command, charon exit full-exit will download the full exit message from Obol API if available, and broadcast it.

Both commands need a beacon node to function, because they need to:

• fetch the validator index during submit-partial-exit
• broadcast the full exit message during full exit

The commands by design don't allow for multiple validator to be processed at the same time, but their composable nature allow for building simple automation scripts.

Exiting a validator would work like this:

• user A invokes charon exit submit-partial-exit --beacon-node http://beaconnode-address 0xabcd...
• waits until threshold operators also ran the same command
• any user runs charon exit full-exit --beacon-node http://beaconnode-address 0xabcd...