| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Ouroboros.Consensus.Byron.Ledger.Mempool
Description
Byron mempool integration
Synopsis
- data family GenTx blk
- data family TxId tx
- data family Validated x
- byronIdDlg :: ACertificate ByteString -> CertificateId
- byronIdProp :: AProposal ByteString -> UpId
- byronIdTx :: ATxAux ByteString -> TxId
- byronIdVote :: AVote ByteString -> VoteId
- decodeByronApplyTxError :: Decoder s ( ApplyTxErr ByronBlock )
- decodeByronGenTx :: Decoder s ( GenTx ByronBlock )
- decodeByronGenTxId :: Decoder s ( GenTxId ByronBlock )
- encodeByronApplyTxError :: ApplyTxErr ByronBlock -> Encoding
- encodeByronGenTx :: GenTx ByronBlock -> Encoding
- encodeByronGenTxId :: GenTxId ByronBlock -> Encoding
- fromMempoolPayload :: AMempoolPayload ByteString -> GenTx ByronBlock
- toMempoolPayload :: GenTx ByronBlock -> AMempoolPayload ByteString
- countByronGenTxs :: ByronBlock -> Word64
Mempool integration
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
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
Transaction IDs
byronIdProp :: AProposal ByteString -> UpId Source #
byronIdVote :: AVote ByteString -> VoteId Source #
Serialisation
decodeByronGenTx :: Decoder s ( GenTx ByronBlock ) Source #
The
ByteString
annotation will be the canonical encoding.
While the new implementation does not care about canonical encodings, the
old one does. When a generalised transaction arrives that is not in its
canonical encoding (only the
ATxAux
of the
ByronTx
can be
produced by nodes that are not under our control), the old implementation
will reject it. Therefore, we need to reject them too. See #905.
We use the ledger to check for canonical encodings: the ledger will check
whether the signed hash of the transaction (in the case of a
ATxAux
, the transaction witness) matches the annotated
bytestring. Is therefore
important
that the annotated bytestring be the
canonical
encoding, not the
original, possibly non-canonical
encoding.
decodeByronGenTxId :: Decoder s ( GenTxId ByronBlock ) Source #
Low-level API (primarily for testing)
Auxiliary functions
countByronGenTxs :: ByronBlock -> Word64 Source #
Count all (generalized) transactions in the block