Conversation
The Mithril snapshot policy (which is also the default policy) used an interval of one Shelley epoch with an offset of half an epoch. Take a snapshot every 40*k slots instead, with no offset: on mainnet that is one snapshot a day, and one of every five lands on an epoch boundary, as 40*k = 86,400 divides both the 432,000-slot epoch and the 4,492,800-slot start of Shelley. As the interval now depends on k, 'sfaInterval' becomes a 'SnapshotInterval': either 'DefaultSnapshotInterval', resolved to 40*k once the 'SecurityParam' is known, or an explicit 'RequestedSnapshotInterval'. 'SnapshotPolicyArgs' therefore stays plain data, and the security parameter is only needed by 'defaultSnapshotPolicy', which takes it from the LedgerDB configuration, and by 'sanityCheckSnapshotPolicyArgs', which checks the resolved interval.
The Eq/Ord instances for OneEraGenTxId (and hence for TxId (GenTx (HardForkBlock xs))) compared through oneEraGenTxIdRawHash, which serialised each operand's hash to a fresh 32-byte ShortByteString. That allocated on every comparison, on a path the mempool and local queries exercise heavily. The comparison now goes through two new CanHardFork methods, hardForkEqGenTxId and hardForkCompareGenTxId. The Eq/Ord (OneEraGenTxId xs) instances unwrap the newtype and delegate to them, so each hard fork decides how to compare its transaction ids. The methods have no default, so every CanHardFork instance must supply them. This is a breaking change to the class. The Cardano instance implements them without allocating, on every comparison: it reads each id's 32-byte hash as four 64-bit words (Word64#) and compares them in registers, instead of serialising to a ShortByteString. Shelley-based eras return the four words they already store, and Byron reads them out of its hash bytes in place. This covers same-era and cross-era pairs alike, for every era including Byron. The other CanHardFork instances (the single-era instance and the two test hard forks) implement the methods with rawHashNS, the shared raw-hash reference. Those still allocate, but they are not the mempool traffic that #2003 targets. The observable semantics are unchanged: order by the hash bytes, ignoring the era. oneEraGenTxIdRawHash is removed; its walk survives as rawHashNS, now exported from the abstract CanHardFork module. The hard fork tx id's getRawTxId composes rawHashNS with the OneEraGenTxId accessor.
Test.Consensus.Cardano.TxId (in cardano-test) checks that the Eq/Ord instances agree with rawHashNS, the raw-hash reference, over every era pair. An HUnit test probes hashes that differ at the first and last byte of each 64-bit word; a QuickCheck property checks agreement on random hashes. Because the Cardano comparison is no longer the reference itself, these cross-era cells genuinely check the packed comparison against the raw-hash order. The era-txid builders live in Test.Consensus.Cardano.GenTxIdBuilders in unstable-cardano-testlib, so the benchmark can share them.
Measures bytes allocated and ns per compare/== on Cardano OneEraGenTxId across the era grid: one distinct-hash pair for every ordered era pair (64 cells), plus one same-hash pair per era (8 cells). It shares the era-txid builders in Test.Consensus.Cardano.GenTxIdBuilders with the test. Run with +RTS -T to read the allocation counter.
erikd
requested review from
bladyjoker,
dnadales,
geo2a,
jasagredo and
nfrisby
as code owners
August 12, 2026 22:18
erikd
marked this pull request as draft
August 12, 2026 22:18
erikd
changed the title
erikd
force-pushed
the
erikd/ram
branch
4 times, most recently
from
August 20, 2026 05:41
2fbbf01 to
206dffe
Compare
As the thread delay for snapshotting was blocking the snapshotting thread, we would accumulate states in the LedgerDB until the snapshot was taken. We could have done this earlier but we didn't notice. This change just runs that code in a separate thread, allowing garbage collection to proceed.
As the thread delay for snapshotting was blocking the snapshotting thread, we would accumulate states in the LedgerDB until the snapshot was taken. We could have done this earlier but we didn't notice. This change just runs that code in a separate thread, allowing garbage collection to proceed.
cardano-ledger-shelley 1.19.0.0 added sgExtraConfig and grew the CBOR record from 15 fields to 16, with no version guard. The encoder writes the 15 fields that cardano-ledger-shelley 1.18 wrote. The decoder accepts 15 or 16 fields. Nothing uses these functions yet. (cherry picked from commit 274ea3f)
cardano-ledger-shelley 1.19.0.0 changed the ShelleyGenesis encoding under a fixed node-to-client version. A client that links 1.18 and a client that links 1.19 cannot both read the reply. Encode 15 fields again, and accept 15 or 16 on decode. Regenerate the golden files for ShelleyNodeToClientVersion13 and later. Each one loses the trailing 0x80, the SNothing for sgExtraConfig. (cherry picked from commit ec9caa3)
The tests write four .cddl files to the working directory on every run, and a failing_cddl_tests directory when a test fails. (cherry picked from commit 094928a)
(cherry picked from commit 52c997b)
Address Alexey's review on #2251: - Use the ledger codec for node-to-client versions above ShelleyNodeToClientVersion15. - Decode exactly 15 fields with decodeRecordNamed, restoring support for indefinite length encoding. - Set sgExtraConfig to SNothing instead of reading an optional 16th field. Accepting 16 fields changed an existing query with no version bump. Also rename decodeShelleyGenesisWithOptionalExtraConfig to decodeShelleyGenesisNoExtraConfig, and update the pending changelog fragment. (cherry picked from commit d01d5ab)
…2.1.0 (#2257) Backport of #2251 to `ouroboros-consensus-4.x-backports`, plus the release commit. `cardano-ledger-shelley` 1.19.0.0 added `sgExtraConfig` to `ShelleyGenesis`, growing the CBOR record from 15 to 16 fields under a fixed node-to-client version. This restores the 15-field encoding for `GetGenesisConfig` and accepts 15 or 16 on decode. `compactGenesis` erases `sgExtraConfig`, so the reply loses no data. The four commits are cherry-picked unmodified from #2251 (`-x` provenance in each message). The release commit follows #2247: version bump, README badge, `scriv collect`. `ouroboros-consensus`: 4.2.0.1 -> 4.2.1.0 (highest pending fragment severity is non-breaking). Local runs on this branch: `shelley-test` (229 tests) and `cardano-test` pass, including the golden `GenesisConfig` groups covering the 24 changed golden files. CHaP PR: IntersectMBO/cardano-haskell-packages#1449, to be re-pointed at the merge commit.
erikd
force-pushed
the
erikd/ram
branch
2 times, most recently
from
September 1, 2026 23:08
9f8d3bd to
6a0f887
Compare
erikd
force-pushed
the
erikd/ram
branch
2 times, most recently
from
September 9, 2026 07:21
20e2642 to
aed5521
Compare
The package `crypton < 1.1` depends on `memory` and `>= 1.1` depends on `ram`. This does not affect `consensus` directly, but has a huge impact on the whole stack, `ledger`, `consensus` and `node` all need to be changed/fixed at once.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Note: This PR is no longer against
mainbut against therelease-ouroboros-consensus-3.0.1.0tag.cardano-nodeis currently using that version ofconsensusand need to use the commits here in an SRP incardano-node.The package
crypton < 1.1depends onmemoryand>= 1.1depends onram. This does not affectconsensusdirectly, but has a huge impact on the whole stack,ledger,consensusandnodeall need to be changed/fixed at once.The commits in this PR will be used on an experiment branch of
cardano-nodeto make sure everything works.Also note that:
WARNING
To update your feature branch if it's stale, please rebase it manually on top of
main. Don't update your feature branch by mergingmaininto it. Your pull request will not pass CI if you do.