Need to access epoch nonce from ChainDepState

[Jimbo4350]

We need a way to access the epoch nonce from the ChainDepState while using TPraos and Praos

[nfrisby]

Copied from my Slack message:

What's the summary of the need for cardano-node to access it? Testing? Logging? etc? That'd inform how Consensus would add such an observer function to our API.

[Jimbo4350]

We get the ChainDepState from a query in the cli: https://github.com/input-output-hk/cardano-node/blob/902fc77dee9e0f40c36e2c8b905dc8d5c51e97d9/cardano-api/src/Cardano/Api/Query.hs#L337

It's used in various places in the cli e.g.

• https://github.com/input-output-hk/cardano-node/blob/f8550f7bf9fe5380e17b1ef14e9e1efc9c0e88db/cardano-cli/src/Cardano/CLI/Shelley/Run/Query.hs#L551
• https://github.com/input-output-hk/cardano-node/blob/f8550f7bf9fe5380e17b1ef14e9e1efc9c0e88db/cardano-cli/src/Cardano/CLI/Shelley/Run/Query.hs#L851
• https://github.com/input-output-hk/cardano-node/blob/902fc77dee9e0f40c36e2c8b905dc8d5c51e97d9/cardano-api/src/Cardano/Api/LedgerState.hs#L1337

[nfrisby]

It looks like nextEpochEligibleLeadershipSlots is the only one that uses the nonce from the ChainDepState. Is that right? @Jimbo4350

[nfrisby]

@nc6 assuming nextEpochEligibleLeadershipSlots is the only one, then I think what we need is a new class along the lines of "has Praos nonces".

If it's in Consensus, I imagine it'd be named LedgerSupportsNode.

Sound right? Or should it be in Ledger/is there already something like that in Ledger? Or maybe there are plans to lift this getMyLeadershipSlots function out of node and that's what we should be abstracting over?

[Jimbo4350]

nextEpochEligibleLeadershipSlots and currentEpochEligibleLeadershipSlots both use the epoch nonce.

If it's in Consensus, I imagine it'd be named LedgerSupportsNode

Yes I imagined a type class that had a method to retrieve the nonce.

Or should it be in Ledger/is there already something like that in Ledger?

So AFAIU the ChainDepState type family has been moved to consensus, so I would imagine the type class should live there as well. That is a design decision you will need to take up with the ledger team as I don't have all the context.

Or maybe there are plans to lift this getMyLeadershipSlots function out of node and that's what we should be abstracting over?

There is getLeaderSchedule in the ledger which I based my functions on. So far there are no plans to lift my functions out of the node into the ledger.

[nfrisby]

I'm at least going to begin with a focus on nextEpochEligibleLeadershipSlots. https://github.com/input-output-hk/cardano-node/blob/902fc77dee9e0f40c36e2c8b905dc8d5c51e97d9/cardano-api/src/Cardano/Api/LedgerState.hs#L1289

It's polymorphic over a type variable era, which will be one of the token empty types declared in cardano-node's Cardano.Api.Eras module. Consensus has plenty of era type variables as well, so it's easy to get mixed up, but those are instantiated by the cardano-ledger types, eg Cardano.Ledger.Alonzo.AlonzoEra.

I think step 1 will be to declare another family along side in cardano-node Cardano.Api.Eras.ShelleyLedgerEra that maps from the cardano-node era type variable to the protocol that it uses (it seems likely you already have this on your integration branch?). In particular, BabbageEra will be mapped to Ouroboros.Consensus.Protocol.Praos.Praos and all the other Shelley eras will be mapped to Ouroboros.Consensus.Protocol.TPraos.TPraos. That's step 1 because Consensus's Ouroboros.Consensus.Protocol.Abstract.ChainDepState type family is indexed over protocol, not over era (be it node's or ledger's). It's word soup, at this point, but I think ShelleyConsensusProtocol might be a good name -- I'll use that in the rest of this comment.

On the Consensus side, I think we'll define this:

data PraosNonces = PraosNonces {
    evolvingNonce       :: !Nonce,
    candidateNonce      :: !Nonce,
    epochNonce          :: !Nonce,
    -- | Nonce constructed from the hash of the Last Applied Block
    labNonce            :: !Nonce,
    -- | Nonce corresponding to the LAB nonce of the last block of the previous
    -- epoch
    previousLabNonce :: !Nonce
}

class ConsensusProtocol p => ProtocolSupportsNode p where
  getNodeNonces :: ChainDepState p -> NodeNonces
  
instance ProtocolSupportsNode TPraos
instance ProtocolSupportsNode Praos

I think if you add ProtocolSupportsNode (ShelleyConsensusProtocol era) to the context of nextEpochEligibleLeadershipSlots, then you'll be able to call getNodeNonces there and that'll unblock you.

[nc6]

I would be tempted to avoid going down this route, and instead add a specific query GetEpochNonce, which would be supported in all cardano eras. The chain dep state is only accessible through a Debug query, which we should really be avoiding using in production. It would also be better to avoid digging through the internals in such a manner.

[Jimbo4350]

add a specific query GetEpochNonce

This also works

[nfrisby]

At least nextEpochEligibleLeadershipSlots needs more than just the epoch nonce (at least its current code does). So GetEpochNonce wouldn't cut it.

---

Ah, I see now that the nextEpochEligibleLeadershipSlots call is being fed by QueryProtocolState and

toConsensusQueryShelleyBased erainmode QueryProtocolState =
    Some (consensusQueryInEraInMode erainmode (Consensus.GetCBOR Consensus.DebugChainDepState))

I suspect we'll need a broader plan for QueryLeadershipSchedule et al to eventually not rely on any queries that Consensus considers Debug* queries. I'd rather not make an hurried incremental attempt at beginning that now, involving serialization schemes etc, when I don't think I have the whole picture and no one who does has spare time.

So I'll prepare a PR that just adds the class for Jordan to use now. We can remove it later as part of the aforementioned plan.

[dcoutts]

I agree that "doing this properly" would mean not using debug queries to just grab the state, but introducing new queries. Probably those ought to be per-era queries, since it's not guaranteed that future eras are Praos and thus support all these things. The alternative is a query to actually calculate the leader schedule for the current / next era.