IntersectMBO / IntersectMBO/ouroboros-consensus

CSJ: Objectors should never become Jumpers

Open
#1,452 0 comments 0 reactions 0 assignees View on GitHub
Genesis
Dominant language
Haskell
Stars
67
Forks
43
Avg merge
5d 13h
Merged PRs (30d)
43

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.)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.