| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.ByronSpec.Ledger
Synopsis
- data family Header blk
- data family StorageConfig blk
- data family CodecConfig blk
- data family BlockConfig blk
- data family Ticked st
- data family LedgerState blk
- data family Validated x
- data family GenTx blk
- data ByronSpecGenesis = ByronSpecGenesis {}
- data ByronSpecGenTx
- newtype ByronSpecGenTxErr = ByronSpecGenTxErr {}
- data ByronSpecBlock = ByronSpecBlock {}
- type ByronSpecHeader = Header ByronSpecBlock
- newtype ByronSpecLedgerError = ByronSpecLedgerError {}
- forgeByronSpecBlock ∷ BlockNo → SlotNo → Ticked (LedgerState ByronSpecBlock) → [Validated (GenTx ByronSpecBlock)] → VKey → ByronSpecBlock
- initByronSpecLedgerState ∷ ByronSpecGenesis → LedgerState ByronSpecBlock
Documentation
data family Header blk Source #
Instances
data family StorageConfig blk Source #
Config needed for the
NodeInitStorage class. Defined here to
avoid circular dependencies.
Instances
| Generic (StorageConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block Associated Types type Rep (StorageConfig ByronSpecBlock) ∷ Type → Type # Methods from ∷ StorageConfig ByronSpecBlock → Rep (StorageConfig ByronSpecBlock) x # to ∷ Rep (StorageConfig ByronSpecBlock) x → StorageConfig ByronSpecBlock # | |
| NoThunks (StorageConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block Methods noThunks ∷ Context → StorageConfig ByronSpecBlock → IO (Maybe ThunkInfo) Source # wNoThunks ∷ Context → StorageConfig ByronSpecBlock → IO (Maybe ThunkInfo) Source # showTypeOf ∷ Proxy (StorageConfig ByronSpecBlock) → String Source # | |
| data StorageConfig ByronSpecBlock Source # | |
| type Rep (StorageConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block | |
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
| Generic (CodecConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block Associated Types type Rep (CodecConfig ByronSpecBlock) ∷ Type → Type # Methods from ∷ CodecConfig ByronSpecBlock → Rep (CodecConfig ByronSpecBlock) x # to ∷ Rep (CodecConfig ByronSpecBlock) x → CodecConfig ByronSpecBlock # | |
| NoThunks (CodecConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block Methods noThunks ∷ Context → CodecConfig ByronSpecBlock → IO (Maybe ThunkInfo) Source # wNoThunks ∷ Context → CodecConfig ByronSpecBlock → IO (Maybe ThunkInfo) Source # showTypeOf ∷ Proxy (CodecConfig ByronSpecBlock) → String Source # | |
| data CodecConfig ByronSpecBlock Source # | |
| type Rep (CodecConfig ByronSpecBlock) Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Block | |
data family BlockConfig blk Source #
Static configuration required to work with this type of blocks
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
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 Validated x Source #
" Validated " transaction or block
The ledger defines how to validate transactions and blocks. It's possible the type before and after validation may be distinct (eg Alonzo transactions), which originally motivated this family.
We also gain the related benefit that certain interface functions, such as those that reapply blocks, can have a more precise type now. TODO
Similarly, the Node-to-Client mini protocols can explicitly indicate that the
client trusts the blocks from the local server, by having the server send
Validated blocks to the client. TODO
Note that validation has different implications for a transaction than for a block. In particular, a validated transaction can be " reapplied " to different ledger states, whereas a validated block must only be " reapplied " to the exact same ledger state (eg as part of rebuilding from an on-disk ledger snapshot).
Since the ledger defines validation, see the ledger details for concrete
examples of what determines the validity (wrt to a LedgerState) of a
transaction and/or block. Example properties include: a transaction's claimed
inputs exist and are still unspent, a block carries a sufficient
cryptographic signature, etc.
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 ByronSpecGenesis Source #
The equivalent of the genesis config for the abstract ledger
Constructors
| ByronSpecGenesis | |
Fields
| |
Instances
| Show ByronSpecGenesis Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Genesis Methods showsPrec ∷ Int → ByronSpecGenesis → ShowS # show ∷ ByronSpecGenesis → String # showList ∷ [ByronSpecGenesis] → ShowS # | |
| NoThunks ByronSpecGenesis Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Genesis | |
data ByronSpecGenTx Source #
Generalized transaction
The spec doesn't have a type for this, instead splitting the block body into separate lists
Constructors
| ByronSpecGenTxDCert DCert | |
| ByronSpecGenTxTx Tx | |
| ByronSpecGenTxUProp UProp | |
| ByronSpecGenTxVote Vote |
Instances
newtype ByronSpecGenTxErr Source #
Transaction errors
We don't distinguish these from any other kind of CHAIN failure.
Constructors
| ByronSpecGenTxErr | |
Fields | |
Instances
data ByronSpecBlock Source #
Block according to the Byron spec
Just like we do for ByronBlock, we cache the header hash. In addition, we
also add the BlockNo, as this is entirely absent from the spec but we need
it for the HasHeader abstraction, which is ubiquitous in
ouroboros-consensus and -network.
Constructors
| ByronSpecBlock | |
Fields | |
Instances
type ByronSpecHeader = Header ByronSpecBlock Source #
newtype ByronSpecLedgerError Source #
Constructors
| ByronSpecLedgerError | |
Fields | |
Instances
| Show ByronSpecLedgerError Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Ledger Methods showsPrec ∷ Int → ByronSpecLedgerError → ShowS # show ∷ ByronSpecLedgerError → String # showList ∷ [ByronSpecLedgerError] → ShowS # | |
| Eq ByronSpecLedgerError Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Ledger Methods | |
| NoThunks ByronSpecLedgerError Source # | |
Defined in Ouroboros.Consensus.ByronSpec.Ledger.Ledger | |
forgeByronSpecBlock ∷ BlockNo → SlotNo → Ticked (LedgerState ByronSpecBlock) → [Validated (GenTx ByronSpecBlock)] → VKey → ByronSpecBlock Source #