Documentation

In-process access to the node kernel. Constructed by cardano-node once consensus initialisation completes.

The network's system start time, extracted from genesis config. Used together with readEraHistory to convert slots to wall-clock time.

The protocol security parameter k: consensus never rolls back more than k blocks.

The network's genesis configuration.

Read current era history from the ledger state: the hard-fork era summary wrapped into the opaque interpreter used for slot/time conversion queries.

Read the raw hard-fork era summary from the current ledger state, with the era boundaries directly accessible.

Read the current chain tip header from ChainDB, or Nothing at origin.

The per-era genesis configuration of the network the node is running on.

Gathered once, when the node kernel hook fires, by walking the per-era ledger configs of the node kernel's TopLevelConfig. The Byron, Alonzo and Conway genesis values are the ones the running node holds, shared with it rather than copied. Nothing is kept from cardano-node's boot-time ProtocolInfoArgs, whose Shelley genesis reaches gigabytes on networks with large initial fund sets.

The Shelley genesis is not kept here at all. All the node has is a compacted copy with the initial funds erased, which is no use to a caller, so shelleyGenesis holds the file and a cache instead and the genesis is read from disk when someone asks for it.

The Shelley genesis hash and file path come from cardano-node's own boot-time genesis parsing, because the ledger config carries neither (see mkNodeKernelAccess).

Construct NodeKernelAccess from a consensus NodeKernel. Returns Nothing and traces the block type for non-Cardano block types.

Fetch a raw block and its parsed era-contextualised form from ChainDB by slot and header hash.

Grab the current NodeKernelAccess from the environment, or throw gRPC UNAVAILABLE if the node kernel has not yet initialised.

A single instruction produced by a chain follower.

ChainApply carries the raw CBOR block bytes together with the same block parsed into its era context - exactly the pair fetchBlock returns. 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.

Run an action with a ChainFollower tracking the selected chain.

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.