| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.Byron.Ledger.Ledger
Description
Instances requires for consensus/ledger integration
Synopsis
- data ByronTransition = ByronTransitionInfo !(Map ProtocolVersion BlockNo)
- byronEraParams ∷ Config → EraParams
- byronEraParamsNeverHardForks ∷ Config → EraParams
- initByronLedgerState ∷ Config → Maybe UTxO → LedgerState ByronBlock
- decodeByronAnnTip ∷ Decoder s (AnnTip ByronBlock)
- decodeByronLedgerState ∷ Decoder s (LedgerState ByronBlock)
- decodeByronQuery ∷ Decoder s (SomeSecond BlockQuery ByronBlock)
- decodeByronResult ∷ BlockQuery ByronBlock result → ∀ s. Decoder s result
- encodeByronAnnTip ∷ AnnTip ByronBlock → Encoding
- encodeByronExtLedgerState ∷ ExtLedgerState ByronBlock → Encoding
- encodeByronHeaderState ∷ HeaderState ByronBlock → Encoding
- encodeByronLedgerState ∷ LedgerState ByronBlock → Encoding
- encodeByronQuery ∷ BlockQuery ByronBlock result → Encoding
- encodeByronResult ∷ BlockQuery ByronBlock result → result → Encoding
- data family BlockQuery blk ∷ Type → Type
- data family LedgerState blk
- data family Ticked st
- validationErrorImpossible ∷ ∀ err a. Except err a → a
Documentation
data ByronTransition Source #
Information required to determine the transition from Byron to Shelley
Constructors
| ByronTransitionInfo !(Map ProtocolVersion BlockNo) | Per candidate proposal, the The HFC needs to know when a candidate proposal becomes stable. We cannot
reliably do this using Invariant: the domain of this map should equal the set of candidate proposals. |
Instances
Ledger integration
byronEraParams ∷ Config → EraParams Source #
To be used for a Byron-to-X (where X is typically Shelley) chain.
byronEraParamsNeverHardForks ∷ Config → EraParams Source #
Separate variant of byronEraParams to be used for a Byron-only chain.
Arguments
| ∷ Config | |
| → Maybe UTxO | Optionally override UTxO |
| → LedgerState ByronBlock |
Serialisation
decodeByronResult ∷ BlockQuery ByronBlock result → ∀ s. Decoder s result Source #
encodeByronQuery ∷ BlockQuery ByronBlock result → Encoding Source #
encodeByronResult ∷ BlockQuery ByronBlock result → result → Encoding Source #
Type family instances
data family BlockQuery blk ∷ Type → Type Source #
Different queries supported by the ledger, indexed by the result type.
Instances
data family LedgerState blk Source #
Ledger state associated with a block
This is the Consensus notion of a ledger state. Each block type is
associated with one of the Ledger types for the ledger state. Virtually
every concept in this codebase revolves around this type, or the referenced
blk. Whenever we use the type variable l, we intend to denote that the
expected instantiation is either a LedgerState or some wrapper over it
(like the ExtLedgerState).
The main operations we can do with a LedgerState are ticking (defined in
IsLedger), and applying a block (defined in
ApplyBlock).
Instances
data family Ticked st Source #
" Ticked " piece of state, either LedgerState or ChainDepState
Ticking refers to the passage of time (the ticking of the clock). When a
piece of state is marked as ticked, it means that time-related changes have
been applied to the state. There are exactly two methods in the interface
that do that: tickChainDepState and
applyChainTickLedgerResult.
Also note that a successful forecast
forecastFor
(ledgerViewForecastAt cfg st)
slotprotocolLedgerView cfg
(applyChainTick cfg slot st)LedgerView can only be projected
from a Ticked state, but cannot itself be ticked.
Some examples of time related changes:
- Scheduled delegations might have been applied in Byron
- New leader schedule computed for Shelley
- Transition from Byron to Shelley activated in the hard fork combinator.
- Nonces switched out at the start of a new epoch.
Instances
Auxiliary
validationErrorImpossible ∷ ∀ err a. Except err a → a Source #
Mark computation as validation error free
Given a BlockValidationMode of NoBlockValidation, a call to
applyByronBlock shouldn't fail since the ledger layer won't be performing
any block validation checks. However, because applyByronBlock can fail in
the event it is given a BlockValidationMode of BlockValidation, it still
looks like it can fail (since its type doesn't change based on the
ValidationMode) and we must still treat it as such.