Description
I suspect we should remove the (g) transition in the state diagram in the module header Haddock of Ouroboros.Consensus.MiniProtocol.ChainSync.Client.Jumping https://ouroboros-consensus.cardano.intersectmbo.org/haddocks/ouroboros-consensus/Ouroboros-Consensus-MiniProtocol-ChainSync-Client-Jumping.html#t:ChainSyncClientHandleCollection
Consider the following:
- the Dynamo is adversarial and sends a jump request
- an honest peer rejects that jump and becomes the Objector and fetches some headers
- soon after, an adversarial peer rejects that jump at an older point
The current CSJ logic will rotate out the honest Objector because we found a dissenting Jumping with an older intersection.
However, if the next Dynamo is not the honest peer that was previously the Objector, then those headers it fetched will be refetched, which is wasteful load on the honest upstream peers.
I'm therefore thinking that "once an HAA-satisfying peer is the Dynamo or an Objector, it will never be a Jumper again" should be an invariant, under the assumption that Devoted Block Fetch would never rotate out an HAA-satisfying Dynamo (which means that this Issue does not require removing the l
transition from Dynamo to Jumper).
(This issue is not a blocker for the "opt-in" first release of Genesis. It's about making the CSJ optimization "100%" optimal even in a corner-case scenario. Doing that seems simple enough to be preferable to recognizing and excluding that corner-case in our test suite.)
Metadata
Metadata
Assignees
Type
Projects
Status