| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.Ledger.SupportsMempool
Synopsis
- data family GenTx blk :: Type
- type family ApplyTxErr blk :: Type
- class (UpdateLedger blk, NoThunks (GenTx blk), NoThunks (Ticked (LedgerState blk)), Show (GenTx blk), Show (ApplyTxErr blk)) => LedgerSupportsMempool blk where
- txInvariant :: GenTx blk -> Bool
- applyTx :: LedgerConfig blk -> SlotNo -> GenTx blk -> TickedLedgerState blk -> Except (ApplyTxErr blk) (TickedLedgerState blk)
- reapplyTx :: HasCallStack => LedgerConfig blk -> SlotNo -> GenTx blk -> TickedLedgerState blk -> Except (ApplyTxErr blk) (TickedLedgerState blk)
- maxTxCapacity :: TickedLedgerState blk -> Word32
- txInBlockSize :: GenTx blk -> Word32
- data family TxId tx :: Type
- class (Show (TxId tx), Ord (TxId tx), NoThunks (TxId tx)) => HasTxId tx where
- type GenTxId blk = TxId (GenTx blk)
- class HasTxs blk where
- extractTxs :: blk -> [GenTx blk]
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
type family ApplyTxErr blk :: Type Source #
Updating the ledger with a single transaction may result in a different error type as when updating it with a block
Instances
| type ApplyTxErr (HardForkBlock xs) Source # | |
| type ApplyTxErr (DualBlock m a) Source # | |
Defined in Ouroboros.Consensus.Ledger.Dual | |
class (UpdateLedger blk, NoThunks (GenTx blk), NoThunks (Ticked (LedgerState blk)), Show (GenTx blk), Show (ApplyTxErr blk)) => LedgerSupportsMempool blk where Source #
Minimal complete definition
Methods
txInvariant :: GenTx blk -> Bool Source #
Check whether the internal invariants of the transaction hold.
Arguments
| :: LedgerConfig blk | |
| -> SlotNo | Slot number of the block containing the tx |
| -> GenTx blk | |
| -> TickedLedgerState blk | |
| -> Except (ApplyTxErr blk) (TickedLedgerState blk) |
Apply transaction we have not previously seen before
Arguments
| :: HasCallStack | |
| => LedgerConfig blk | |
| -> SlotNo | Slot number of the block containing the tx |
| -> GenTx blk | |
| -> TickedLedgerState blk | |
| -> Except (ApplyTxErr blk) (TickedLedgerState blk) |
Re-apply a transaction
When we re-apply a transaction to a potentially different ledger state expensive checks such as cryptographic hashes can be skipped, but other checks (such as checking for double spending) must still be done.
maxTxCapacity :: TickedLedgerState blk -> Word32 Source #
The maximum number of bytes worth of transactions that can be put into a block according to the currently adopted protocol parameters of the ledger state.
This is (conservatively) computed by subtracting the header size and any other fixed overheads from the maximum block size.
txInBlockSize :: GenTx blk -> Word32 Source #
Return the post-serialisation size in bytes of a GenTx /when it is
embedded in a block/. This size might differ from the size of the
serialisation used to send and receive the transaction across the
network.
This size is used to compute how many transaction we can put in a block when forging one.
For example, CBOR-in-CBOR could be used when sending the transaction across the network, requiring a few extra bytes compared to the actual in-block serialisation. Another example is the transaction of the hard-fork combinator which will include an envelope indicating its era when sent across the network. However, when embedded in the respective era's block, there is no need for such envelope.
Can be implemented by serialising the GenTx, but, ideally, this is
implement more efficiently. E.g., by returning the length of the
annotation.
Instances
data family TxId tx :: Type Source #
A generalized transaction, GenTx, identifier.
Instances
class (Show (TxId tx), Ord (TxId tx), NoThunks (TxId tx)) => HasTxId tx where Source #
Transactions with an identifier
The mempool will use these to locate transactions, so two different transactions should have different identifiers.
Methods
txId :: tx -> TxId tx Source #
NOTE: a TxId must be unique up to ledger rules, i.e., two GenTxs with
the same TxId must be the same transaction according to the ledger.
However, we do not assume that a TxId uniquely determines a GenTx:
two GenTxs with the same TxId can differ in, e.g., witnesses.
Should be cheap as this will be called often.
Instances
| Bridge m a => HasTxId (GenTx (DualBlock m a)) Source # | |
| CanHardFork xs => HasTxId (GenTx (HardForkBlock xs)) Source # | |
Defined in Ouroboros.Consensus.HardFork.Combinator.Mempool Methods txId :: GenTx (HardForkBlock xs) -> TxId (GenTx (HardForkBlock xs)) Source # | |
class HasTxs blk where Source #
Collect all transactions from a block
This is used for tooling only. We don't require it as part of RunNode (and cannot, because we cannot give an instance for the dual ledger).
Methods
extractTxs :: blk -> [GenTx blk] Source #
Return the transactions part of the given block in no particular order.
Instances
| All HasTxs xs => HasTxs (HardForkBlock xs) Source # | |
Defined in Ouroboros.Consensus.HardFork.Combinator.Mempool Methods extractTxs :: HardForkBlock xs -> [GenTx (HardForkBlock xs)] Source # | |