CLI tooling: Byron, Shelley and onward

[deepfire]

Context

We need means to manipulate secrets/certificates/genesis files (henceforth referred to as key material).

General scope

0. Generation/derivation of all sorts of necessary key material.
1. Support for all necessary iterations of the system -- Byron and Shelley for now, the former in both the Legacy and PBFT variants.
2. Support for migration of key material between iterations of the system.
3. Transaction manipulation and submission.
4. Update system support.
5. Support for delegation & staking.

Terminology: Legacy vs. PBFT

• delegator :: Genesis keys. Referred to as delegation issuer keys in Legacy.
• delegate :: Operational keys of core nodes used for block minting and proposal signing. Referred to as richmen keys in Legacy.
• VSS :: Publicly Verifiable Secret Sharing Scheme algorithm used in Ouroboros Classic/Byron Legacy.

Future work

0. More transaction-related things: creation, pretty-printing.
1. Update system:
   • stimuli (proposals and votes): creation, pretty-printing, submission.
   • querying the node for the update system state.
2. Staking (https://github.com/input-output-hk/cardano-node/issues/139):
   • stake pool lifecycle
   • lightweight delegation

History of implementation

https://github.com/input-output-hk/cardano-node/pull/28

0. Generation of key material (genesis, keys) for new Byron Legacy clusters.
1. Generation of key material (genesis, keys) for new Byron PBFT clusters.
2. Migration of Byron Legacy key material (genesis, keys) to the Byron PBFT iteration. So far this appears to consist of:
   • Deserialisation of the delegate keys in the old format, as defined by the Bi instance for the legacy UserSecret data type
   • Reserialisation of the delegate keys in a new format, which, while not yet decided, has a candidate format of just a CBOR serialisation of SigningKey.
   • Cutting VSS out of the genesis file:
     • vssCerts from the top level,
     • vssMaxTTL and vssMinTTL from the protocolConsts section
3. Pretty-printing of the key material.

https://github.com/input-output-hk/cardano-node/pull/95

0. Separate, non-genesis keypair generation for Byron/PBFT.
1. Non-HD address printing for a given keypair.
2. Genesis hash printing.
3. Byron genesis delegation: generating delegation certificates for a given pair of genesis/delegate keys.

https://github.com/input-output-hk/cardano-node/pull/135 & https://github.com/input-output-hk/cardano-node/pull/147

0. Raw TX submission over local node submission protocol.
1. Genesis UTxO expenditure.

Notes

• DELEGATE-SECRETS-INCOMPATIBLE-BYRON-LEGACY-PBFT: as @dcoutts mentioned

  VSS, the Ouroboros classic randomness MPC algorithm, is not used after the PBFT hard fork.

  Therefore, the delegate secrets will no longer contain the VSS keypair, which makes them incompatible between the Legacy and PBFT iterations of Byron. This needs to be accounted for with regards to both the generation and migration aspects.

  • The compatibility was implemented in the new codebase.
• SECRET-SERIALISATION-INCOMPATIBLE-BYRON-LEGACY-PBFT: Byron Legacy is using cardano-binary for secret serialisation, whereas Byron PBFT uses CBOR. This needs to be accounted for with regards to both the generation and migration aspects.
  • This does no longer appear to be a problem, since the underlying encoding that cardano-binary uses in the Bi typeclass is CBOR, which means there's only a thin compatibility layer that needs to be reimplemented. The thin compatibility layer for Byron Legacy delegate key roundtripping was reimplemented.
• GENESIS-INCOMPATIBLE-BYRON-LEGACY-PBFT: Byron Legacy carries the VSS certificates, which aren't generated by the Byron PBFT genesis generator.

[disassembler]

Short term requirements look like what we need from my end.

[kevinhammond]

Still open?

[Jimbo4350]

Closing as we are currently redefining scope