ouroboros-consensus-0.21.0.0: Consensus layer for the Ouroboros blockchain protocol
Safe HaskellSafe-Inferred
LanguageHaskell2010

Ouroboros.Consensus.Ledger.SupportsProtocol

Synopsis

Documentation

newtype GenesisWindow Source #

Size of the Genesis window, in number of slots.

This is the number of slots that the GDD Governor (Genesis Density Disconnection Governor -- see Governor) will consider when deciding whether to disconnect from a peer. It has to be smaller or equal to the stability window. For instance, for Shelley-based eras, this will be equal to a stability window, that is 3k/f.

Constructors

GenesisWindow 

Instances

Instances details
Num GenesisWindow Source # 
Instance details

Defined in Ouroboros.Consensus.Block.Abstract

Show GenesisWindow Source # 
Instance details

Defined in Ouroboros.Consensus.Block.Abstract

Eq GenesisWindow Source # 
Instance details

Defined in Ouroboros.Consensus.Block.Abstract

Ord GenesisWindow Source # 
Instance details

Defined in Ouroboros.Consensus.Block.Abstract

NoThunks GenesisWindow Source # 
Instance details

Defined in Ouroboros.Consensus.Block.Abstract

class (BlockSupportsProtocol blk, UpdateLedger blk, ValidateEnvelope blk) ⇒ LedgerSupportsProtocol blk where Source #

Link protocol to ledger

Methods

protocolLedgerViewLedgerConfig blk → Ticked (LedgerState blk) → LedgerView (BlockProtocol blk) Source #

Extract the ledger view from the given ticked ledger state

See ledgerViewForecastAt for a discussion and precise definition of the relation between this and forecasting.

ledgerViewForecastAtHasCallStackLedgerConfig blk → LedgerState blk → Forecast (LedgerView (BlockProtocol blk)) Source #

Get a forecast at the given ledger state.

This forecast can be used to validate headers of blocks within the range of the forecast. These blocks need to live on a chain that fits on the last applied block of the given ledger.

The range of the forecast should allow to validate a sufficient number of headers to validate an alternative chain longer than ours, so that chain selection can decide whether or not we prefer the alternative chain to our current chain. In addition, it would be helpful, though not essential, if we can look further ahead than that, as this would improve sync performance.

NOTE (difference between ledgerViewForecastAt and applyChainTick): Both ledgerViewForecastAt and applyChainTick can be used to obtain a protocol ledger view for a future slot. The difference between the two is that applyChainTick assumes no blocks are present between the current ledger tip and the specified SlotNo, whereas ledgerViewForecastAt cannot make such an assumption. Thus, applyChainTick cannot fail, whereas the forecast returned by ledgerViewForecastAt might report an OutsideForecastRange for the same SlotNo. We expect the two functions to produce the same view whenever the SlotNo is in range, however. More precisely:

If

   forecastFor (ledgerViewForecastAt cfg st) for
== Just view

then

   protocolLedgerView cfg (applyChainTick cfg for st)
== view

See lemma_ledgerViewForecastAt_applyChainTick.