Skip to content

[CTC 1] Generalize point schedule tests to parametric blk#1879

Merged
jasagredo merged 3 commits intoIntersectMBO:mainfrom
tweag:ctc/generalize-tests
Feb 26, 2026
Merged

[CTC 1] Generalize point schedule tests to parametric blk#1879
jasagredo merged 3 commits intoIntersectMBO:mainfrom
tweag:ctc/generalize-tests

Conversation

@ninioArtillero
Copy link
Contributor

@ninioArtillero ninioArtillero commented Feb 13, 2026 •
edited
Loading

Node-vs-Environment tests (a.k.a. point schedule tests, represented by GenesisTest) are currently hardcoded to use TestBlock. As part of the approved Conformance Testing of Consensus (CTC) proposal, we are tasked with exposing these tests to the wider ecosystem and therefore must support real Cardano blocks.

This PR generalizes the relevant types to make the tests block-agnostic. To accomplish this:

  1. The existing code is parameterized over an arbitrary block type, subject to the necessary constraints.
  2. New code implementing deforestBlockTree is introduced to generalize property test computations that previously depended on the TestHash implementation. This function constructs a map enabling prefix lookups by HeaderHash, where a prefix is the AnchoredFragment from genesis to the block corresponding to the given hash at its tip.
  3. A new type class, HasPointScheduleTestParams, is introduced to construct the ProtocolInfo and other pieces of state required for a test run.
  4. A new type class, IssueTestBlock, defining the interface for producing blocks in tests, is introduced.

Care has been taken to document the previously implicit TestHash-related logic (based on the use of ad hoc fork numbers) and to include comprehensive property tests for the deforestation code under ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/BlockTree/Tests.hs.

@ninioArtillero ninioArtillero changed the title Ctc/generalize tests [CTC 1] Generalize point schedule tests to parametric blk Feb 13, 2026
@ninioArtillero ninioArtillero force-pushed the ctc/generalize-tests branch 4 times, most recently from 3ea081f to 45f3760 Compare February 13, 2026 20:09
@ninioArtillero ninioArtillero marked this pull request as ready for review February 13, 2026 22:00
@ninioArtillero ninioArtillero force-pushed the ctc/generalize-tests branch 2 times, most recently from 6a7cf58 to d0a1689 Compare February 16, 2026 15:55
@ninioArtillero ninioArtillero mentioned this pull request Feb 16, 2026
Closed
@ninioArtillero ninioArtillero force-pushed the ctc/generalize-tests branch 3 times, most recently from 0254b6f to 0cebfdd Compare February 20, 2026 17:23
jasagredo
jasagredo reviewed Feb 24, 2026
View reviewed changes
@ninioArtillero ninioArtillero force-pushed the ctc/generalize-tests branch 3 times, most recently from 0608737 to 2b105db Compare February 24, 2026 23:57
@ninioArtillero ninioArtillero force-pushed the ctc/generalize-tests branch 2 times, most recently from 536769e to c5bb566 Compare February 25, 2026 15:49
@jasagredo jasagredo enabled auto-merge February 26, 2026 14:56
nbloomf and others added 3 commits February 26, 2026 09:22
@nbloomf @ninioArtillero
Add deforestBlockTree
6f5dbf7 
An important in-progress task is to make more test code
block-polymorphic; right now it is largely hardcoded to use test blocks
but this will not work for running conformance tests against live
implementations of the protocol.

We do not know the exact motivation behind making these tests monomorphic;
regardless it seems the only thing the tests require is the ability to
compute where a block is on the block tree.

Here we add a helper function to make generalize this by constructing a map
from each block hash in the tree to the `AnchoredFragment` from it to the
anchor. That fragment is a prefix of the trunk if and only if the block
is on the trunk.

The deforested block tree is used to check for block membership, and
to prevent its unnecessary regeneration many thousands of times per test,
it is implemented by adding a `DeforestedBlockTree` field to `BlockTree` to
cache it and a smart constructor that populates it correctly at definition time
and makes it possible to deconstruct a block tree into its trunk and branches
without giving access to the cached deforestation.

GHC's pattern match checker [assumes that any case expression involving
a pattern synonym is
incomplete](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas);
with either `-Wincomplete-patterns` or `-Wall`, GHC will report usage of
such patterns an incomplete pattern match like this:

```
    Pattern match(es) are non-exhaustive
    In an equation for ‘mkProperty’:
        Patterns of type ‘GenesisTestFull blk’,
                         ‘StateView blk’ not matched:
            (GenesisTest _ _ _ _ (Test.Consensus.BlockTree.RawBlockTree _ _ _)
             _ _ _ _ _ _ _)
            _
```

For this reason we add a `COMPLETE` pragma to let GHC know that `BlockTree` is
in fact a complete set of patterns for deconstructing a block tree.
@isovector @nbloomf @ninioArtillero
Generalize test machinery's reliance on TestBlock
d3cc18c 
Here we generalize all uses of unnecessarily-specified `TestBlock`s to
instead be parametric `blk`s. For this we introduce two new type classes.

The `IssueTestBlock` class abstracts the operations needed to produce
blocks during chain generation.

The `HasPointScheduleTestParams` class abstracts the parameters needed to run
the point schedule tests. We invoke `getProtocolInfoArgs` at the beginning of
a test, and use it to construct a `ProtocolInfo`, which in turn provides both a
`TopLevelConfig` and an `ExtLedgerState`. The requirement of `IO` comes
from needing to eventually parse cardano config files.
A key point of entry for this change is found on
`PeerSimulator.Run.nodeLifecycle`, where the `ProtocolInfo` is delivered,
enabling the generalization of the simulation to arbitrary blocks.

We provide instances for `TestBlock`.

Co-authored-by: Nathan Bloomfield <nathan.bloomfield@tweag.io>
Co-authored-by: Xavier Góngora <xavier.gongora@tweag.io>
@ninioArtillero
Use chain hash comparison for properties on parametric blk
afe45d7 
Some genesis tests still depend on 'TestBlock' specific logic.
Specifically, the `TestHash` (the `HeaderHash TestBlock` type family
instance) stores a number list representation of the path on the
`BlockTree` leading to the corresponding block (i.e. its prefix
`AnchoredFragment`); this is used to implement certain properties.

Here, such properties are refactored to parametric blocks by using direct
hash comparison (in some cases on the `BlockTree` trunk).

tweag/ouroboros-consensus-testing@3e83852
holds a test showcasing a property of a previous refactor: namely that
the order of _fork numbers_ in a `TestHash` are not relevant for the
properties that depended on it. This alternative refactor (on
tweag/ouroboros-consensus-testing@dab5349)
intended to preserve existing code structure, which was confusing, and
as such was changed in the end in search for clarity.
auto-merge was automatically disabled February 26, 2026 15:27

Head branch was pushed to by a user without write access

@jasagredo jasagredo enabled auto-merge February 26, 2026 15:30
@jasagredo jasagredo added this pull request to the merge queue Feb 26, 2026
Merged via the queue into IntersectMBO:main with commit 24a4ed1 Feb 26, 2026
16 checks passed
@ninioArtillero ninioArtillero deleted the ctc/generalize-tests branch February 26, 2026 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jasagredo jasagredo jasagredo approved these changes

@nfrisby nfrisby Awaiting requested review from nfrisby nfrisby is a code owner

@fraser-iohk fraser-iohk Awaiting requested review from fraser-iohk fraser-iohk is a code owner

@dnadales dnadales Awaiting requested review from dnadales dnadales is a code owner

@geo2a geo2a Awaiting requested review from geo2a geo2a is a code owner

@bladyjoker bladyjoker Awaiting requested review from bladyjoker bladyjoker is a code owner

+2 more reviewers

@isovector isovector isovector left review comments

@nbloomf nbloomf nbloomf left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

no changelog

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@ninioArtillero @isovector @nbloomf @jasagredo