Enrich block bodies to contain Peras certificates

[amesgen]

To coordinate the end of a cooldown period, we need to be able to store certificates in blocks. As they are too large to be stored in headers (which would be preferable in an ideal world as they are a Consensus concern, not a Ledger concern), we store them in block bodies instead.

As the block body is nowadays purely managed by the Ledger, we should closely collaborate with them on this (we already talked to them at the Peras Paris workshop).

Status quo of block bodies

Some hints through the many layers of abstraction:

• In Consensus, a CardanoBlock is a HardForkBlock, which is an n-ary sum, with each summand being the block type of a particular era.

• Apart from Byron, all eras are Shelley-based eras, and use ShelleyBlock with different parameters.

  • proto is the Consensus protocol, which is either TPraos (transitional Praos, a legacy protocol) or Praos (the current protocol)
  • era is the Ledger era, ie (on a really high level) which features are supported by transactions, whose details are largely irrelevant for Consensus.

  See https://github.com/cardano-foundation/CIPs/blob/master/CIP-0059/feature-table.md for a reference.

• A ShelleyBlock contains a Ledger Block, which contains a header (instantiated by the Consensus layer) and a BlockBody, which is era-dependent. The most recent concrete instantiation is AlonzoBlockBody at the moment.

  Fundamentally, it contains nothing but a sequence of transactions.

Implementation approaches

1. We could adapt the BlockBody instance for the Dijkstra Ledger era (as that one is still experimental ATM) and add a Maybe PerasCert field to it. It also needs to count towards the hash.

   This means that Ledger needs to be aware of Peras certificates.

2. We could not modify the Ledger at all, and rather store the Peras certificate in ShelleyBlock in Consensus. This means we now need to define the hash of a block body ourselves, ie hashing the Ledger BlockBody hash together with the serialization of the (optional) Peras certificate.

3. Like 2, but add a new type parameter to Block (maybe consensusBlockBody).

4. No longer use Block in ShelleyBlock, instead, ShelleyBlock should look like this:

   data ShelleyBlock proto era = ShelleyBlock
     { shelleyBlockHeader :: !(ShelleyProtocolHeader proto)
     , shelleyBlockBody :: !(SL.BlockBody era)
     , shelleyBlockPerasCert :: !(StrictMaybe (PerasCert (ShelleyBlock proto era)))
     , shelleyBlockHeaderHash :: !ShelleyHash
     }

We can also coordinate with Leios a bit, as they will also need to store certificates in block bodies.

[agustinmista]

Some developments:

• [WIP] Enrich block bodies to contain Peras certificates IntersectMBO/ouroboros-consensus#1722 explores option (4), but it's deemed as not ideal given how it creates a responsibility mismatch between consensus and ledger.

  In particular, the block body size check currently lives in Ledger, and seems suboptimal to leave it in options (2)-(4) (where the Ledger is not aware of certificates).

• After meeting with the Ledger devs, we are now aiming to follow option (1). This requires a couple of changes to happen elsewhere:

  • Define concrete Peras certificates in a base package available to ledger. One idea is to put it under cardano-base/cardano-crypto-peras.
  • Enhance Dijkstra blocks in ledger with these certificates and adapt serialization (similar to what we already did for (4))
  • Instantiate the corresponding BlockSupportsPeras instances for these blocks in consensus. Might depend on Implement BlockSupportsPeras for all blocks (including HFC) #73 ?