Store latest cert on chain

[agustinmista]

The voting rules need access to the latest Peras certificate stored on chain. That is, the certificate with the highest round number. To give them access to it, there are a couple of issues that need to be addressed:

1. To coordinate the end of a cooldown period, Peras certificates will (sometimes) appear in the block body of blocks starting with Dijkstra (cf. Add Peras certificate to the block body IntersectMBO/cardano-ledger#5439). This means that BlockSupportsPeras (and the plumbing defined by Implement BlockSupportsPeras for all blocks (including HFC) #73) will have to be extended with a getter to extract these certificates. Something like:

class ... => BlockSupportsPeras blk where
  ...
  getPerasCertInBlock :: blk -> Maybe (PerasCert blk)

Defaulting to Nothing for any block type that doesn't support Peras.

2. We need to extend the PerasCertDB API with a method:

data PerasCertDB m blk where
  ...
  getLatestCertOnChain :: STM m (Maybe (WithArrivalTime (ValidatedPerasCert blk)))

(The implementation of this method can probably be copied from that of getLatestCertSeen

3. We need to find a way to inject some sort of callback that updates the latest cert on chain in the PerasCertDB whenever a new block containing a Peras certificate becomes old enough*. For this, we could add:

data PerasCertDB m blk where
  ...
  setLatestCertOnChain :: WithArrivalTime (ValidatedPerasCert blk) -> STM m () 

And hook it up to the routine that copies blocks from the volatile to the immutable DB (see comment below first), see O.C.Storage.ChainDB.Impl.Background.copyToImmutableDB.

[*] The concrete definition for "old enough" is not very clear at this point, as it might depend on the concrete parameterization being used. One starting point could be the boundary between the volatile and immutable DBs, though it remains to be seen if crossing this boundary would always happen early enough so that every latest coordination cert stored on chain is visible to the voting rules before evaluating if nodes should resume voting.

[tbagrel1]

Why should we update latestCertOnChain only when a block is old enough? The CIP defines

latestCert : Certificate → List Certificate → Certificate
latestCert c = maximumBy c Certificate.roundNumber

latestCertOnChain : T → Certificate
latestCertOnChain = latestCert cert₀ ∘ mapMaybe Block.certificate ∘ preferredChain

which relates to the actual preferred chain, with no mention of age for it? 🤔

BTW, we should remember that latest here means having the largest round number, it doesn't depend on the time of inclusion of the said certificate on the chain.

N.B.: per the Agda spec, it seems we need some concept of "root" certificate (here cert₀)

[agustinmista]

@tbagrel1 That's a fair question. As per the design document, nodes would should enough time after a cooldown period (c * perasCooldownRounds for some c > 0) before they can resume voting. Waiting for the cert to become immutable would enforce they all agree on the same cert by construction, but the CIP indeed doesn't seem to care about where in chain this certificate comes from (and the condition above is already covered by the voting rules).

So, now it's unclear to me whether (depending on the concrete parameterization) these certs will be mostly found on the immutable or volatile suffix. I'm also not too sure I fully understand the implications of having nodes anchoring to a certificate that could be potentially rolled back and how we should deal with those rollbacks under the hood. We should ask someone about this 😄

N.B.: per the Agda spec, it seems we need some concept of "root" certificate (here cert₀)

This should already be handled in the voting rules view by providing both input certs wrapped in a WithOrigin. From there, the rules should be able to bootstrap from the case one or both certificates are missing (relaxed conditions in the presence of Origin, indicating we only have the virtual "root" cert).