Safe Haskell | None |
---|---|
Language | Haskell2010 |
Ouroboros.Consensus.ByronDual.Ledger
Synopsis
- type DualByronBlock = DualBlock ByronBlock ByronSpecBlock
- type DualByronBridge = BridgeLedger ByronBlock ByronSpecBlock
- data ByronSpecBridge = ByronSpecBridge {
- toSpecKeys :: Map (PBftVerKeyHash PBftByronCrypto) VKey
- toImplIds :: SpecToImplIds
- newtype SpecToImplIds = SpecToImplIds {
- getSpecToImplIds :: AbstractToConcreteIdMaps
- bridgeToSpecKey :: DualByronBridge -> PBftVerKeyHash PBftByronCrypto -> VKey
- bridgeTransactionIds :: DualByronBridge -> Map TxId TxId
- initByronSpecBridge :: ByronSpecGenesis -> Map TxId TxId -> ByronSpecBridge
- specToImplTx :: Tx -> ATxAux ByteString -> SpecToImplIds
- forgeDualByronBlock :: HasCallStack => TopLevelConfig DualByronBlock -> BlockNo -> SlotNo -> TickedLedgerState DualByronBlock -> [Validated (GenTx DualByronBlock)] -> PBftIsLeader PBftByronCrypto -> DualByronBlock
Shorthand
type DualByronBlock = DualBlock ByronBlock ByronSpecBlock Source #
type DualByronBridge = BridgeLedger ByronBlock ByronSpecBlock Source #
Bridge
data ByronSpecBridge Source #
Bridge the gap between the Byron implementation and specification
The relation between the Byron implementation and specification for the
linear case is tested in the Byron implementation itself, specifically
in ts_prop_generatedChainsAreValidated
. The main goal of the consensus
DualByron tests is to lift these tests to the general consensus setting,
where time is not linear but branching.
In the linear case, the tests maintain some state linking the spec and the implementation. In the consensus case, this state cannot be maintained like this, and so it has to become part of transactions, blocks, and the ledger state itself.
Constructors
ByronSpecBridge | |
Fields
|
Instances
newtype SpecToImplIds Source #
Constructors
SpecToImplIds | |
Fields
|
Instances
bridgeToSpecKey :: DualByronBridge -> PBftVerKeyHash PBftByronCrypto -> VKey Source #
Translate issuer key
We get a proof from PBFT that we are the leader, including a signing key (of
type SigningKey
). In order to produce the corresponding abstract block, we
need a VKey
.
bridgeTransactionIds :: DualByronBridge -> Map TxId TxId Source #
Arguments
:: ByronSpecGenesis | |
-> Map TxId TxId | Mapping for the transaction in the initial UTxO |
-> ByronSpecBridge |
specToImplTx :: Tx -> ATxAux ByteString -> SpecToImplIds Source #
Construct singleton SpecToImplIds
for a transaction
Block forging
Arguments
:: HasCallStack | |
=> TopLevelConfig DualByronBlock | |
-> BlockNo | Current block number |
-> SlotNo | Current slot number |
-> TickedLedgerState DualByronBlock | Ledger |
-> [Validated (GenTx DualByronBlock)] | Txs to add in the block |
-> PBftIsLeader PBftByronCrypto | Leader proof ( |
-> DualByronBlock |
Orphan instances
Bridge ByronBlock ByronSpecBlock Source # | |
Associated Types type BridgeLedger ByronBlock ByronSpecBlock type BridgeBlock ByronBlock ByronSpecBlock type BridgeTx ByronBlock ByronSpecBlock Methods updateBridgeWithBlock :: DualBlock ByronBlock ByronSpecBlock -> BridgeLedger ByronBlock ByronSpecBlock -> BridgeLedger ByronBlock ByronSpecBlock updateBridgeWithTx :: Validated (GenTx (DualBlock ByronBlock ByronSpecBlock)) -> BridgeLedger ByronBlock ByronSpecBlock -> BridgeLedger ByronBlock ByronSpecBlock |