ouroboros-consensus

ouroboros-consensus copied to clipboard

The ChainSyncClient keeps following all candidate chains that we could theoretically still switch to, e.g., longer chains, forks that don't fork off more than k blocks in the past, but also less interesting candidates, e.g., a chain that is behind ours or a recent fork that is shorter than our chain.

In the decentralised era it will become more important to disconnect from such less interesting candidates. They should be degraded from hot to warm nodes.

To detect such nodes, introduce a new thread that watches all chain sync candidate chains and the current chain, so that it can give each candidate chain a "pointlessness" score, which can be used by the P2P governor to cycle out the nodes corresponding to the most pointless candidate chains. By having access to all candidate and the current chain, we have a better, global view of the node.

Let's make this a new thread as the ChainSyncClient is already complex enough.

@njd42 @coot Now that the P2P governor is has been realized, does this idea still appeal to you?

In particular, I wonder if the existing logic for churning peers already renders this idea moot? If so, we can close this Issue.

I chose the "Help needed" status because it's blocked by my question to Networking in the preceding GitHub comment.

Such nodes would: a) never be the first to supply a new header; b) never be first to be asked to get a block - so never first to supply a block. As such they would rank towards the bottom in the churn process and therefore get churned out.

If that is sufficient, we already run a mechanism that will discard them (over time) [unless they are in local root peers - they are not subject to that assessment]

We also don't want to prioritise disconnecting from short forks which might win or lose. Churn works on a larger time scale so that we can accommodate shorter diruptions which naturally occur in the system.

@nfrisby from our perspective this can be closed.