search

IntersectMBO / ouroboros-consensus

Implementation of a Consensus Layer for the Ouroboros family of protocols
https://ouroboros-consensus.cardano.intersectmbo.org
Apache License 2.0
31 stars 22 forks source link

Add an HFC query for which upcoming slots the node will lead #390

Open nfrisby opened 11 months ago

nfrisby commented 11 months ago

The Node Team, under our recommendation, has so far used a Debug* query in order to build a CLI query that computes the node's upcoming leadership schedule. This is a non-trivial calculation with various pitfalls, and so it should instead be implemented as a proper query in the ouroboros-consensus code base.

The design of such a query is unfortunately related to Issue #389. In Slack discussion with architecture stakeholders, we have already decided that the ideal behavior would be for the node to only predict slots for which the answer could not change under ordinary circumstances (ie a rollback of at most k blocks). Thus...

This Issue is to design and implement a new HardForkBlock (see comment below) query that returns the list of slot numbers with their corresponding UTC times such that BOTH this node's configured leadership credentials will be elected in those slots AND ALSO the slots' UTC times and those election predicates will be correct for any extension of the node's current immutable tip---ie the query's result must not be subject to a rollback of at most k blocks.

This is the first query with that constraint, other than the HFC queries which already involve a non-trivial mechanism to ensure it.

nfrisby commented 11 months ago

Esgen and I just now realized this, in general, may need to be a "cross-era query", which will need to be added to CanHardFork etc. Therefore this query should be a HardForkBlock query, not a ShelleyBlock query---otherwise the ShelleyBlock query would have to somehow know how to compute the leader schedule of the next era, which violates the HFC prinicpal that era's are not responsible for other eras.

Edit: it's cross era because, a ledger state in era F that determines the next epoch will be in era G will have to be used to answer a query about the leader schedule in the next epoch, which is determined by G. An era (F) is generally not supposed to know how to do that sort of calculation for the next era (G). So we'll need to add another InPairs to the CanHardFork class for this sort of thing.

amesgen commented 9 months ago

Also see #600 for some additional remarks