| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.HardFork.Combinator.Mempool
Contents
Synopsis
- data family GenTx blk ∷ Type
- data HardForkApplyTxErr xs
- data family TxId tx ∷ Type
- data family Validated x ∷ Type
- hardForkApplyTxErrFromEither ∷ Either (MismatchEraInfo xs) (OneEraApplyTxErr xs) → HardForkApplyTxErr xs
- hardForkApplyTxErrToEither ∷ HardForkApplyTxErr xs → Either (MismatchEraInfo xs) (OneEraApplyTxErr xs)
Documentation
data family GenTx blk ∷ Type 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 HardForkApplyTxErr xs Source #
Constructors
| HardForkApplyTxErrFromEra !(OneEraApplyTxErr xs) | Validation error from one of the eras |
| HardForkApplyTxErrWrongEra !(MismatchEraInfo xs) | We tried to apply a block from the wrong era |
Instances
data family TxId tx ∷ Type Source #
A generalized transaction, GenTx, identifier.
Instances
data family Validated x ∷ Type 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
hardForkApplyTxErrFromEither ∷ Either (MismatchEraInfo xs) (OneEraApplyTxErr xs) → HardForkApplyTxErr xs Source #
hardForkApplyTxErrToEither ∷ HardForkApplyTxErr xs → Either (MismatchEraInfo xs) (OneEraApplyTxErr xs) Source #