| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.Shelley.Ledger.Mempool
Contents
Description
Shelley mempool integration
Synopsis
- data family GenTx blk
- newtype ApplyTxError era = ApplyTxError [ PredicateFailure ( EraRule "LEDGER" era)]
- data family TxId tx
- data family Validated x
- data WithTop a
- fixedBlockBodyOverhead :: Num a => a
- mkShelleyTx :: forall era proto. ShelleyBasedEra era => Tx era -> GenTx ( ShelleyBlock proto era)
- mkShelleyValidatedTx :: forall era proto. ShelleyBasedEra era => Validated ( Tx era) -> Validated ( GenTx ( ShelleyBlock proto era))
- perTxOverhead :: Num a => a
- data AlonzoMeasure = AlonzoMeasure { }
- fromExUnits :: ExUnits -> ExUnits' ( WithTop Natural )
Documentation
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
newtype ApplyTxError era Source #
Constructors
| ApplyTxError [ PredicateFailure ( EraRule "LEDGER" era)] |
Instances
A generalized transaction,
GenTx
, identifier.
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
Add a unique top element to a lattice.
TODO This should be relocated to `cardano-base:Data.Measure'.
Instances
fixedBlockBodyOverhead :: Num a => a Source #
txInBlockSize
is used to estimate how many transactions we can grab from
the Mempool to put into the block we are going to forge without exceeding
the maximum block body size according to the ledger. If we exceed that
limit, we will have forged a block that is invalid according to the ledger.
We ourselves won't even adopt it, causing us to lose our slot, something we
must try to avoid.
For this reason it is better to overestimate the size of a transaction than to underestimate. The only downside is that we maybe could have put one (or more?) transactions extra in that block.
As the sum of the serialised transaction sizes is not equal to the size of
the serialised block body (
TxSeq
) consisting of those transactions
(see cardano-node#1545 for an example), we account for some extra overhead
per transaction as a safety margin.
Also see
perTxOverhead
.
mkShelleyTx :: forall era proto. ShelleyBasedEra era => Tx era -> GenTx ( ShelleyBlock proto era) Source #
mkShelleyValidatedTx :: forall era proto. ShelleyBasedEra era => Validated ( Tx era) -> Validated ( GenTx ( ShelleyBlock proto era)) Source #
perTxOverhead :: Num a => a Source #
See
fixedBlockBodyOverhead
.
Exported for tests
data AlonzoMeasure Source #
Constructors
| AlonzoMeasure | |