charon get command

[OisinKyne]

🎯 Problem to be solved

We want to return information to the charon node operator about the running cluster in a manner easier than opening the cluster-lock.json. This will become more important as we move to mutable cluster state and have a no longer human readable data file.

We need to develop getters for key lock file information. Ideally, it can be supplemented with access to a CL (and maybe one day an EL) to provide additional information and filtration.

🛠️ Proposed solution

• [ ] Approved design doc: TODO, notes below for now
• [ ] Core team consensus on the proposed solution

Describe the solution to be implemented

[Wishlist first draft]

• charon get operators
  • lists the operators (in a table?) based on what we have, either ENRs, addresses, peer index
  • If possible, the adjective-noun names we derive for those ENRs.
  • (Low priority future expansion, if we want to ENS resolve them provided an rpc address)
• charon get validators
  • pubkey
  • fee recipient
  • [requires not split keys] withdrawal address
  • [requires CL] state
  • [requires EL, low priority future add-on] address balances
• charon info (?)
  • Neat summary of full cluster details? (in a manner that could describe e.g. a 1k key cluster)

Open questions

• Should we make a get operator <id> or stick to the plurals for now, and only add commands that summarise all operators? same for get validator(s)

🧪 Tests

• [ ] Tested by new automated unit/integration/smoke tests
• [ ] Manually tested on core team/canary/test clusters
• [ ] Manually tested on local compose simnet

[gsora]

Neat summary of full cluster details? (in a manner that could describe e.g. a 1k key cluster)

This is a slippery slope, we risk filling the terminal with lots of information that nobody ends up really using.

charon get validators

The current iteration of this command supports a flag to print validator addresses in plaintext, to allow for scripting.

WDYT about porting over that functionality?

or stick to the plurals for now

If we make the CLI output easily manageable through shell piping, I would stick with plurals.