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

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

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

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.

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

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

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 current chain tip header from ChainDB, or Nothing at origin.

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

Read the current mempool contents as a point-in-time snapshot: transactions added or removed after the read are not reflected. Ticket numbers and mempool capacity accounting are dropped here, since readMempoolTxs only serves the one-shot ReadMempool method.

A point-in-time view of the mempool for WatchMempool: every current entry's ticket number (for change detection), the virtual block's slot number, and a pure projection of entries newer than a given ticket, already unwrapped out of Validated into TxInMode - a plain value that test code can construct directly with TxInMode fixtures, with no need to fabricate a genuine Validated value or run mempool validation.

Read the current mempool watch snapshot, without blocking.

Block until the mempool snapshot's ticket list or slot number differs from the given one, then return the new snapshot.

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.