| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Test.Consensus.HardFork.Combinator.B
Contents
Synopsis
- data BlockB = BlkB {}
- data ProtocolB
- blockForgingB ∷ Monad m ⇒ BlockForging m BlockB
- safeZoneB ∷ SecurityParam → SafeZone
- data family BlockConfig blk
- data family CodecConfig blk
- data family ConsensusConfig p
- data family GenTx blk
- data family Header blk
- data family LedgerState blk
- data family NestedCtxt_ blk ∷ (Type → Type) → Type → Type
- data family StorageConfig blk
- data family TxId tx
Documentation
Constructors
| BlkB | |
Fields | |
Instances
Instances
blockForgingB ∷ Monad m ⇒ BlockForging m BlockB Source #
safeZoneB ∷ SecurityParam → SafeZone Source #
A basic SafeZone
The mock B ledger has no transactions and so can't end and so needs no safezone. However, we give it a default one anyway, since that makes the test more realistic.
Type family instances
data family BlockConfig blk Source #
Static configuration required to work with this type of blocks
Instances
data family CodecConfig blk Source #
Static configuration required for serialisation and deserialisation of types pertaining to this type of block.
Data family instead of type family to get better type inference.
Instances
data family ConsensusConfig p Source #
Static configuration required to run the consensus protocol
Every method in the ConsensusProtocol class takes the consensus
configuration as a parameter, so having this as a data family rather than a
type family resolves most ambiguity.
Defined out of the class so that protocols can define this type without having to define the entire protocol at the same time (or indeed in the same module).
Instances
data family GenTx blk Source #
Generalized transaction
The mempool (and, accordingly, blocks) consist of "generalized transactions"; this could be "proper" transactions (transferring funds) but also other kinds of things such as update proposals, delegations, etc.
Instances
data family Header blk Source #
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 NestedCtxt_ blk ∷ (Type → Type) → Type → Type Source #
Context identifying what kind of block we have
In almost all places we will use NestedCtxt rather than NestedCtxt_.
Instances
data family StorageConfig blk Source #
Config needed for the
NodeInitStorage class. Defined here to
avoid circular dependencies.
Instances
A generalized transaction, GenTx, identifier.