Documentation

A single instruction produced by a chain follower.

ChainApply carries the per-block payload the follower was opened for (see withFollower and withBlockFollower). Consensus rollbacks are point-only: ChainRollBack never carries the blocks being rolled back, only the point to roll back to.

A handle to a running chain follower. The payload is selectable because consensus reads each requested block component separately.

Run an action with a ChainFollower tracking the selected chain, whose ChainApply payload is the raw CBOR block bytes together with the same block parsed into its era context - exactly the pair fetchBlock returns.

The follower and the resource registry backing it are closed on every exit path, including exceptions. The follower itself runs in IO, because the ChainDB handle is monomorphic, so the bracket runs there and the action is unlifted into it.

Creating a follower is cheap: a few in-memory STM operations, nothing proportional to chain length. The costs are steady-state instead. A caught-up follower receives an O(1) notification per adopted block. A follower catching up streams blocks from the ImmutableDB, paying a disk read and a deserialisation per block, with file handles owned by the registry. The node already runs one such follower per connected N2C ChainSync client, so one follower per stream scales the same way.

withFollower with the parsed block alone as the ChainApply payload, reading each block once instead of twice.

Position a freshly opened chain follower at the current tip (origin, at genesis), so it reports only blocks applied from now on, and return that point. A fork switch between the tip read and the intersection takes the old tip off the chain; then read the new tip and try again, rather than fall back to origin and replay the whole chain on the first drain.

Read the current chain tip point from ChainDB, or ChainPointAtGenesis at origin. An STM read, so a caller can wait for the tip to move.