ouroboros-consensus-0.1.0.1: Consensus layer for the Ouroboros blockchain protocol
Safe Haskell None
Language Haskell2010

Ouroboros.Consensus.NodeKernel

Contents

Synopsis

Node kernel

data NodeKernel m remotePeer localPeer blk Source #

Interface against running relay node

Constructors

NodeKernel

Fields

data TraceForgeEvent blk Source #

Trace the forging of a block as a slot leader.

The flow of trace events here can be visualized as follows:

TraceStartLeadershipCheck
         |
         +--- TraceSlotIsImmutable (leadership check failed)
         |
         +--- TraceBlockFromFuture (leadership check failed)
         |
 TraceBlockContext
         |
         +--- TraceNoLedgerState (leadership check failed)
         |
  TraceLedgerState
         |
         +--- TraceNoLedgerView (leadership check failed)
         |
  TraceLedgerView
         |
         +--- TraceForgeStateUpdateError (leadership check failed)
         |
         +--- TraceNodeCannotForge (leadership check failed)
         |
         +--- TraceNodeNotLeader
         |
  TraceNodeIsLeader
         |
   TraceForgedBlock
         |
         +--- TraceDidntAdoptBlock
         |
         +--- TraceForgedInvalidBlock
         |
 TraceAdoptedBlock

Constructors

TraceStartLeadershipCheck SlotNo

Start of the leadership check

We record the current slot number.

TraceSlotIsImmutable SlotNo ( Point blk) BlockNo

Leadership check failed: the tip of the ImmutableDB inhabits the current slot

This might happen in two cases.

  1. the clock moved backwards, on restart we ignored everything from the VolatileDB since it's all in the future, and now the tip of the ImmutableDB points to a block produced in the same slot we're trying to produce a block in
  2. k = 0 and we already adopted a block from another leader of the same slot.

We record both the current slot number as well as the tip of the ImmutableDB.

See also https://github.com/input-output-hk/ouroboros-network/issues/1462

TraceBlockFromFuture SlotNo SlotNo

Leadership check failed: the current chain contains a block from a slot after the current slot

This can only happen if the system is under heavy load.

We record both the current slot number as well as the slot number of the block at the tip of the chain.

See also https://github.com/input-output-hk/ouroboros-network/issues/1462

TraceBlockContext SlotNo BlockNo ( Point blk)

We found out to which block we are going to connect the block we are about to forge.

We record the current slot number, the block number of the block to connect to and its point.

Note that block number of the block we will try to forge is one more than the recorded block number.

TraceNoLedgerState SlotNo ( Point blk)

Leadership check failed: we were unable to get the ledger state for the point of the block we want to connect to

This can happen if after choosing which block to connect to the node switched to a different fork. We expect this to happen only rather rarely, so this certainly merits a warning; if it happens a lot, that merits an investigation.

We record both the current slot number as well as the point of the block we attempt to connect the new block to (that we requested the ledger state for).

TraceLedgerState SlotNo ( Point blk)

We obtained a ledger state for the point of the block we want to connect to

We record both the current slot number as well as the point of the block we attempt to connect the new block to (that we requested the ledger state for).

TraceNoLedgerView SlotNo OutsideForecastRange

Leadership check failed: we were unable to get the ledger view for the current slot number

This will only happen if there are many missing blocks between the tip of our chain and the current slot.

We record also the failure returned by forecastFor .

TraceLedgerView SlotNo

We obtained a ledger view for the current slot number

We record the current slot number.

TraceForgeStateUpdateError SlotNo ( ForgeStateUpdateError blk)

Updating the forge state failed.

For example, the KES key could not be evolved anymore.

We record the error returned by updateForgeState .

TraceNodeCannotForge SlotNo ( CannotForge blk)

We did the leadership check and concluded that we should lead and forge a block, but cannot.

This should only happen rarely and should be logged with warning severity.

Records why we cannot forge a block.

TraceNodeNotLeader SlotNo

We did the leadership check and concluded we are not the leader

We record the current slot number

TraceNodeIsLeader SlotNo

We did the leadership check and concluded we are the leader

The node will soon forge; it is about to read its transactions from the Mempool. This will be followed by TraceForgedBlock.

TraceForgeTickedLedgerState SlotNo ( Point blk)

We ticked the ledger state for the slot of the to-be-forged block.

We record the current slot number and the point of the block we attempt to connect the new block to.

TraceForgingMempoolSnapshot SlotNo ( Point blk) ( ChainHash blk) SlotNo

We acquired a mempool snapshot.

We record the the point of the state we are starting from (ie the point from TraceLedgerState ) and point the mempool had most last synced wrt.

TraceForgedBlock SlotNo ( Point blk) blk MempoolSize

We forged a block

We record the current slot number, the point of the predecessor, the block itself, and the total size of the mempool snapshot at the time we produced the block (which may be significantly larger than the block, due to maximum block size)

This will be followed by one of three messages:

  • TraceAdoptedBlock (normally)
  • TraceDidntAdoptBlock (rarely)
  • TraceForgedInvalidBlock (hopefully never -- this would indicate a bug)
TraceDidntAdoptBlock SlotNo blk

We did not adopt the block we produced, but the block was valid. We must have adopted a block that another leader of the same slot produced before we got the chance of adopting our own block. This is very rare, this warrants a warning.

TraceForgedInvalidBlock SlotNo blk ( InvalidBlockReason blk)

We forged a block that is invalid according to the ledger in the ChainDB. This means there is an inconsistency between the mempool validation and the ledger validation. This is a serious error!

TraceAdoptedBlock SlotNo blk [ Validated ( GenTx blk)]

We adopted the block we produced, we also trace the transactions that were adopted.

getPeersFromCurrentLedger :: ( IOLike m, LedgerSupportsPeerSelection blk) => NodeKernel m remotePeer localPeer blk -> ( LedgerState blk -> Bool ) -> STM m ( Maybe [( PoolStake , NonEmpty RelayAccessPoint )]) Source #

Retrieve the peers registered in the current chain/ledger state by descending stake.

For example, for Shelley, this will return the stake pool relays ordered by descending stake.

Only returns a Just when the given predicate returns True . This predicate can for example check whether the slot of the ledger state is older or newer than some slot number.

We don't use the ledger state at the tip of the chain, but the ledger state k blocks back, i.e., at the tip of the immutable chain, because any stake pools registered in that ledger state are guaranteed to be stable. This justifies merging the future and current stake pools.

getPeersFromCurrentLedgerAfterSlot :: forall m blk localPeer remotePeer. ( IOLike m, LedgerSupportsPeerSelection blk, UpdateLedger blk) => NodeKernel m remotePeer localPeer blk -> SlotNo -> STM m ( Maybe [( PoolStake , NonEmpty RelayAccessPoint )]) Source #

Like getPeersFromCurrentLedger but with a "after slot number X" condition.

initNodeKernel :: forall m remotePeer localPeer blk. ( IOLike m, RunNode blk, NoThunks remotePeer, Ord remotePeer, Hashable remotePeer) => NodeKernelArgs m remotePeer localPeer blk -> m ( NodeKernel m remotePeer localPeer blk) Source #