Mithril Design Investigation

[coot]

Recently, we co-authored a CIP proposal, in particular this section.

We need to investigate in depth how the ouroboros-network needs to adapt to the proposed design. In particular:

• what is required to run a standalone diffusion which only has access ledger through n2c protocol? This includes what information we need from the ledger, how it can be obtained through n2c protocol, what information is needed from consensus or other places and whether we need it for mithril nodes
• Do we need to have the notion of big ledger peers for standalone Mithril nodes (I think we do, but it would be good to analyse why it's helpful in that setup)?
• Do we need/want to have the notion of bootstrap peeres for mithril nodes - we probably don't, if that's the case then how can we design outbound-governor for both cases: cardano-node and mithril-node.
• How to do churn, which will require new metrics to optimise the network graph.
• We don't need to have BlockFetchConsensusInterface, which includes readFetchMode and is used by outbound-governor.
• Similarly, we don't need LedgerPeerJudgement - how can we accommodate that in an elegant way

The above list is not exhaustive. I expect that we will learn more in the process, especially about the relations between things that pull some APIs.

The outcome of such an analysis could be some pseudocode and a proposal on how we can adapt the ouroboros-network to elegantly use it for: cardano-node and mithril-node.

[coot]

How to do churn, which will require new metrics to optimise the network graph.

In this context the question is how to decouple metric used by churn, so it's passed via Ouroboros.Network.Diffusion.P2P.ArgumentsExtra

[coot]

Let's also note that mithril-node will not use NonP2P diffusion, it will only support P2P diffusion.

[bolt12]

Please see #4987 (comment) where I have been working on this issue