amesgen
amesgen
#925 added the LoE, together with peer simulator-based tests for it. The goal of this ticket is to also adapt the ChainDB q-s-m test for extra confidence.
Currently, `OneEraGenTxId` (used for the HFC's `GenTxId`) is an n-ary sum: https://github.com/IntersectMBO/ouroboros-consensus/blob/8c485b24161981d34bf3d0c1d58cafeac141d359/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/AcrossEras.hs#L127 Since #1017, motivated by #1009, we already compare these based on the underlying hash, ignoring the index of...
Currently, the `readFetchedBlocks` from `BlockFetchConsensusInterface` we provide to Network is implemented via `ChainDB.getIsFetched` (which in turn is implemented via `VolatileDB.getIsMember`). When a new block is added from a BlockFetch client,...
Currently, we have golden tests for some, but not all queries (both the encoded query and result messages): https://github.com/IntersectMBO/ouroboros-consensus/blob/15d2e93a44cf9697d99634695e67c685540410da/ouroboros-consensus-cardano/src/shelley-testlib/Test/Consensus/Shelley/Examples.hs#L199-L217 The goal of this ticket is to extend this: - Add...
The most intricate parts of the HFC related to how time/era transitions are performed have been largely unmodified since they were first introduced[^1]. Recently, investigating https://github.com/input-output-hk/cardano-ledger/issues/3491 lead us to scrutinize...
Right now, the HFC makes use of the fact that ticking can't let a transition become known: https://github.com/IntersectMBO/ouroboros-consensus/blob/106ce89c51e4b6d144b15d02bf78513e947817e6/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Ledger.hs#L130-L131 Right now, this is true due to "block counting" (see eg `ShelleyTransition`)....
Due to #395, we have good evidence that no use case is **fundamentally**/**crucially** relying on `TriggerHardForkAtEpoch`. Hence, we would like to remove them to simplify the possible trajectories of the...
For historical reasons, the logic for TPraos lives in Ledger instead of Consensus (which would be the natural place for the implementation of a `ConsensusProtocol`, as is already the case...
When crossing an era boundary while using `--trace-ledger`, db-analyser crashes due to https://github.com/IntersectMBO/ouroboros-consensus/blob/4b668deb5bcf22578cf2899f9091e2410d00e8d1/ouroboros-consensus-cardano/src/tools/Cardano/Tools/DBAnalyser/Block/Cardano.hs#L97 To see why, consider the signature of the offending function (that is used in `emitTraces`): https://github.com/IntersectMBO/ouroboros-consensus/blob/4b668deb5bcf22578cf2899f9091e2410d00e8d1/ouroboros-consensus-cardano/src/tools/Cardano/Tools/DBAnalyser/Block/Cardano.hs#L87-L93 with...
Right now, the semantics of cross-era ticking/forecasting is purely implementation-defined, driven by whatever does not cause any concrete issues, rather than principled considerations. - See [here](https://ouroboros-consensus.cardano.intersectmbo.org/docs/for-developers/HardWonWisdom/#how-does-cross-era-forecasting-work) for forecasting. - See...