Integrated weighted BlockFetch decision logic
Home /
Input Output /
ouroboros-consensus
Jul 14, 9-10 AM (5)
Jul 14, 10-11 AM (3)
Jul 14, 11-12 PM (1)
Jul 14, 12-1 PM (0)
Jul 14, 1-2 PM (3)
Jul 14, 2-3 PM (0)
Jul 14, 3-4 PM (2)
Jul 14, 4-5 PM (0)
Jul 14, 5-6 PM (0)
Jul 14, 6-7 PM (0)
Jul 14, 7-8 PM (0)
Jul 14, 8-9 PM (0)
Jul 14, 9-10 PM (0)
Jul 14, 10-11 PM (0)
Jul 14, 11-12 AM (0)
Jul 15, 12-1 AM (0)
Jul 15, 1-2 AM (0)
Jul 15, 2-3 AM (0)
Jul 15, 3-4 AM (0)
Jul 15, 4-5 AM (0)
Jul 15, 5-6 AM (0)
Jul 15, 6-7 AM (0)
Jul 15, 7-8 AM (0)
Jul 15, 8-9 AM (0)
Jul 15, 9-10 AM (2)
Jul 15, 10-11 AM (0)
Jul 15, 11-12 PM (7)
Jul 15, 12-1 PM (0)
Jul 15, 1-2 PM (18)
Jul 15, 2-3 PM (2)
Jul 15, 3-4 PM (0)
Jul 15, 4-5 PM (1)
Jul 15, 5-6 PM (0)
Jul 15, 6-7 PM (0)
Jul 15, 7-8 PM (0)
Jul 15, 8-9 PM (0)
Jul 15, 9-10 PM (0)
Jul 15, 10-11 PM (0)
Jul 15, 11-12 AM (0)
Jul 16, 12-1 AM (0)
Jul 16, 1-2 AM (0)
Jul 16, 2-3 AM (0)
Jul 16, 3-4 AM (0)
Jul 16, 4-5 AM (0)
Jul 16, 5-6 AM (0)
Jul 16, 6-7 AM (3)
Jul 16, 7-8 AM (2)
Jul 16, 8-9 AM (0)
Jul 16, 9-10 AM (2)
Jul 16, 10-11 AM (4)
Jul 16, 11-12 PM (2)
Jul 16, 12-1 PM (0)
Jul 16, 1-2 PM (1)
Jul 16, 2-3 PM (1)
Jul 16, 3-4 PM (0)
Jul 16, 4-5 PM (1)
Jul 16, 5-6 PM (0)
Jul 16, 6-7 PM (0)
Jul 16, 7-8 PM (0)
Jul 16, 8-9 PM (0)
Jul 16, 9-10 PM (0)
Jul 16, 10-11 PM (0)
Jul 16, 11-12 AM (1)
Jul 17, 12-1 AM (0)
Jul 17, 1-2 AM (0)
Jul 17, 2-3 AM (0)
Jul 17, 3-4 AM (0)
Jul 17, 4-5 AM (0)
Jul 17, 5-6 AM (0)
Jul 17, 6-7 AM (0)
Jul 17, 7-8 AM (19)
Jul 17, 8-9 AM (25)
Jul 17, 9-10 AM (6)
Jul 17, 10-11 AM (23)
Jul 17, 11-12 PM (9)
Jul 17, 12-1 PM (2)
Jul 17, 1-2 PM (1)
Jul 17, 2-3 PM (1)
Jul 17, 3-4 PM (0)
Jul 17, 4-5 PM (0)
Jul 17, 5-6 PM (0)
Jul 17, 6-7 PM (0)
Jul 17, 7-8 PM (0)
Jul 17, 8-9 PM (0)
Jul 17, 9-10 PM (0)
Jul 17, 10-11 PM (0)
Jul 17, 11-12 AM (0)
Jul 18, 12-1 AM (0)
Jul 18, 1-2 AM (0)
Jul 18, 2-3 AM (0)
Jul 18, 3-4 AM (0)
Jul 18, 4-5 AM (0)
Jul 18, 5-6 AM (0)
Jul 18, 6-7 AM (1)
Jul 18, 7-8 AM (1)
Jul 18, 8-9 AM (8)
Jul 18, 9-10 AM (0)
Jul 18, 10-11 AM (1)
Jul 18, 11-12 PM (1)
Jul 18, 12-1 PM (0)
Jul 18, 1-2 PM (0)
Jul 18, 2-3 PM (0)
Jul 18, 3-4 PM (0)
Jul 18, 4-5 PM (0)
Jul 18, 5-6 PM (0)
Jul 18, 6-7 PM (0)
Jul 18, 7-8 PM (0)
Jul 18, 8-9 PM (0)
Jul 18, 9-10 PM (0)
Jul 18, 10-11 PM (0)
Jul 18, 11-12 AM (0)
Jul 19, 12-1 AM (0)
Jul 19, 1-2 AM (0)
Jul 19, 2-3 AM (0)
Jul 19, 3-4 AM (0)
Jul 19, 4-5 AM (0)
Jul 19, 5-6 AM (0)
Jul 19, 6-7 AM (0)
Jul 19, 7-8 AM (0)
Jul 19, 8-9 AM (0)
Jul 19, 9-10 AM (0)
Jul 19, 10-11 AM (0)
Jul 19, 11-12 PM (0)
Jul 19, 12-1 PM (0)
Jul 19, 1-2 PM (0)
Jul 19, 2-3 PM (0)
Jul 19, 3-4 PM (0)
Jul 19, 4-5 PM (0)
Jul 19, 5-6 PM (0)
Jul 19, 6-7 PM (0)
Jul 19, 7-8 PM (0)
Jul 19, 8-9 PM (0)
Jul 19, 9-10 PM (0)
Jul 19, 10-11 PM (0)
Jul 19, 11-12 AM (0)
Jul 20, 12-1 AM (0)
Jul 20, 1-2 AM (0)
Jul 20, 2-3 AM (0)
Jul 20, 3-4 AM (0)
Jul 20, 4-5 AM (0)
Jul 20, 5-6 AM (0)
Jul 20, 6-7 AM (0)
Jul 20, 7-8 AM (0)
Jul 20, 8-9 AM (0)
Jul 20, 9-10 AM (0)
Jul 20, 10-11 AM (0)
Jul 20, 11-12 PM (0)
Jul 20, 12-1 PM (0)
Jul 20, 1-2 PM (11)
Jul 20, 2-3 PM (0)
Jul 20, 3-4 PM (0)
Jul 20, 4-5 PM (0)
Jul 20, 5-6 PM (0)
Jul 20, 6-7 PM (0)
Jul 20, 7-8 PM (0)
Jul 20, 8-9 PM (0)
Jul 20, 9-10 PM (0)
Jul 20, 10-11 PM (0)
Jul 20, 11-12 AM (0)
Jul 21, 12-1 AM (0)
Jul 21, 1-2 AM (0)
Jul 21, 2-3 AM (0)
Jul 21, 3-4 AM (0)
Jul 21, 4-5 AM (0)
Jul 21, 5-6 AM (0)
Jul 21, 6-7 AM (0)
Jul 21, 7-8 AM (0)
Jul 21, 8-9 AM (23)
Jul 21, 9-10 AM (3)
191 commits this week
Jul 14, 2025
-
Jul 21, 2025
ChainDB: implement chain selection for certificates
Add bloomfilter-blocked to cabal.project
PerasCertDB.getWeightSnapshot: add `Fingerprint`
GSM: allow `candidateOverSelection` to be stateful
This is in preparation for weighted chain comparisons.
Introduce weighted chain comparisons
ChainSel.ReprocessLoEBlocks: ensure trigger block is not on chain
Previously, we triggered ChainSel for all successor blocks of the immutable tip, which in particular includes the oldest header on our selection (that is not yet immutable). This is fine semantics-wise, but a bit weird that the block we are performing chain selection for might not actually be part of the `ChainDiff` that we are adopting. In particular, it is not true that all suffixes in the candidate `ChainDiff`s intersect as one might expect. For example, suppose that `k=2` and that our selection is ``` A ] B :> C ``` and the VolatileDB furthermore contains blocks `D` and `E` with `B :> D` and `C :> E`. Then, when we trigger ChainSel, we trigger it for `B` (the only successor of the immutable tip), and the ChainSel logic builds the following `ChainDiffs`: - `ChainDiff { getRollback = 1, getSuffix = B ] D }` - `ChainDiff { getRollback = 0, getSuffix = C ] E }` Note that the suffixes do not intersect. Therefore, motivated by future work (weighted chain selection) which relies on these fragments to intersect, we refactor this code to trigger chain selection for all blocks that are a successor of a block on our selection (while ignoring blocks on our selection), which is semantically equivalent (but we potentially consider candidates in a different order than before, which is acceptable while syncing via Genesis). This ensures that all `ChainDiff` suffixes intersect. In the scenario above, this is achieved by the fact that we separately trigger chain selection for `D` and `E`.
Update index-state for hedgehog-quickcheck
Test the LSM backend in the LedgerDB StateMachine tests
Adapt snapshot-converter and db-analyser to the new types
Implement LSM instances for all blocks
Implement opening of an LSM LedgerDB backend
Define SnapshotManagement
Different LedgerDB backends will manage snapshots in different ways. In particular, before LSM trees each snapshot was fully contained in a directory in the ledger folder of the ChainDB. However LSM trees store part of the snapshot in the LSM database, which might be somewhere else. The SnapshotManagement record of functions provide a common interface for managing the snapshots.
Generalize some functions in the LedgerTablesHandle interface
LSM trees will need some additional information in some functions to emulate IndexedMemPack. Also taking a snapshot of a handle might not provide a CRC anymore.
Return maximal key when doing a range read
LSM trees use an ordering different than the Haskell `Ord`. This commit enriches the type returned by range reads so that the maximal key is returned, which is then given back to the next iteration of the range reading loop.
Reorganize LedgerDB args and define LSM trees arguments
LSM trees require a Session which we don't want cardano-node to create. We therefore define `LedgerDbBackendArgs` which will be given by the node to us.
Reorganize LedgerDB constraints
ouroboros-network already supports GHC-9.12
Updated golden files for GetBigledgerPeerSnapshot
ouroboros-consensus-diffusion integrated with cardano-diffusion