ChainSync: MsgRollForward tip slot can be behind header slot

[paolino]

Summary

While implementing a ChainSync client, I observed that the tip parameter in MsgRollForward can have a slot number lower than the header being delivered. Is this expected protocol behavior?

Observed Behavior

Debug tracing shows:

headerSlot=SlotNo 103120911 tipSlot=SlotNo 103120911
headerSlot=SlotNo 103120959 tipSlot=SlotNo 103120911
headerSlot=SlotNo 103120971 tipSlot=SlotNo 103120959
headerSlot=SlotNo 103120985 tipSlot=SlotNo 103120971
headerSlot=SlotNo 103121010 tipSlot=SlotNo 103120985

The pattern shows that tipSlot consistently equals the previous header's slot, not the current chain tip. This means header.slot > tip.slot by approximately one block.

Expected Behavior (my assumption)

I expected tip.slot >= header.slot to always hold, since:

• The tip represents the server's current chain tip
• The header is a block from that chain
• A block cannot be ahead of the chain tip

Questions

1. Is header.slot > tip.slot expected/valid behavior in MsgRollForward?
2. If so, is this documented somewhere in the protocol specification?

Environment

• cardano-node 10.3.1 (linux-x86_64, ghc-9.6, git rev b3f237b75e64f4d8142af95b053e2828221d707f)
• Preview network
• Node-to-node ChainSync protocol

[karknu]

This is expected behavior.
The cardano-node will announce a new header before it has downloaded and verified the corresponding block.
This "header pipelining" is done to speed up block propagation, but it is a feature that lives consensus.