[BUG] - db-analyser --store-ledger does not store the ledger at the requested slot

[notunrandom]

External

Summary

When a snapshot is produced using db-analyser [...] --store-ledger SLOT_NUMBER, where SLOT_NUMBER contains a block, the resulting snapshot is for an earlier slot.

Steps to reproduce

Steps to reproduce the behavior:

• install cardano-node 10.5.4 and cardano-cli
• install db-analyser from corresponding ouroboros-consensus (release-ouroboros-consensus-cardano-0.25.1.1)
• Download preprod config files from https://book.play.dev.cardano.org/environments/preprod
• Download mithril snapshot
• start the node on preprod config files and wait till it is synchronised
• Use cardano-cli query tip:

{
    "block": 4412526,
    "epoch": 270,
    "era": "Conway",
    "hash": "16f6569272011c12147a7227a6a6a1b1d94df6b6391d3a211b38dd6fbbd882f6",
    "slot": 115135151,
    "slotInEpoch": 136751,
    "slotsToEpochEnd": 295249,
    "syncProgress": "100.00"
}

• Use that to calculate the last slot of the previous epoch (114998400)
• Stop the node.
• Check if there is a block in that last slot with:

db-analyser --db db --analyse-from 108950442 --num-blocks-to-process 1 --count-blocks --v2-in-mem cardano --config conf/config.json`

• Since there is not, keep trying the previous slot until you found one with a block in it (114998370)
• Ask db-analyser to produce a snapshot at that slot you found (with a block in it):

db-analyser --db db --v2-in-mem --store-ledger $slot cardano --config conf/config.json`

• Although the standard output from db-analyser claims to have produced requested snapshot, in fact db/ledger contains 114998312_db-analyser

log.txt

Expected behavior

That the snapshot produced is for the same slot that was requested, if that slot contains at least one block. The db_SLOT_NUMBER/ directory in which the snapshot is placed should correspond.

**System info **

• OS Name: Ubuntu
• OS Version: 24.04 aarch64
• Consensus version: release-ouroboros-consensus-cardano-0.25.1.1

Screenshots and attachments

Cf. attached log

Additional context

In order to produce snapshots from which to bootstrap Amaru we need to be able to snapshot the ledger exactly at the last, non-empty slot of an epoch.

[dnadales]

The behaviour can be reproduced, for instance, with the preview database, with earlier blocks as well, and not necessarily the last one of an epoch. Eg. when requested a snapshot at slot 500, it takes a snapshot at slot 460. The tool seems to consistently be off by 40 slot.

For reference, on preview:

• k = 432
• 1 second slots
• epoch duration = 86400

[jasagredo]

I think this is fixed on main:

$ db-analyser --db db --config config.json --store-ledger 4500000 --in-mem
1.071540s] Started StoreLedgerStateAt (SlotNo 4500000) LedgerReapply
[1.116075s] BlockNo 0	SlotNo 0	89d9b5a5b8ddc8d7e5a6795e9774d97faf1efea59b2caf7eaf9f8c5b32059df4
[1.291785s] BlockNo 1000	SlotNo 999	f84748ae7f413a7f73ddb599fd77e4ed488484c1353c6075a05f30e9c78c9de9
...
[854.043254s] BlockNo 4490000	SlotNo 4492289	428b01626de393dff5c41916ec07be1b307213bc750dbf2ec0cadb5f9e8c2247
[859.576308s] Snapshot stored at SlotNo 4500000
[859.576535s] Done
ImmutableDB tip: Point (At (Block {blockPointSlot = SlotNo 178999186, blockPointHash = b44327edfb5b3e66acb5a4aca69e4a71e35e867aa4281989f2a4e9843082f1cb}))
$ cabal repl lib:ourobros-consensus-cardano -b transformers -b fs-api
ghci> import Cardano.Chain.Slotting
ghci> import Codec.Serialise
ghci> import Control.Monad.Trans.Except
ghci> import Data.SOP.Strict
ghci> import Ouroboros.Consensus.Cardano.Block
ghci> import Ouroboros.Consensus.Cardano.Ledger 
ghci> import Ouroboros.Consensus.Cardano.Node 
ghci> import Ouroboros.Consensus.Ledger.Extended 
ghci> import Ouroboros.Consensus.Shelley.HFEras 
ghci> import Ouroboros.Consensus.Shelley.Ledger.Config
ghci> import Ouroboros.Consensus.Shelley.Ledger.Ledger 
ghci> import Ouroboros.Consensus.Shelley.Ledger.SupportsProtocol 
ghci> import Ouroboros.Consensus.Storage.LedgerDB.Snapshots 
ghci> import System.FS.API
ghci> import System.FS.IO
ghci> s = ShelleyCodecConfig
ghci> ccfg = HardForkCodecConfig (PerEraCodecConfig (ByronCodecConfig (EpochSlots 0) :* s :* s :* s :* s :* s :* s :* s :* Nil)) :: CodecConfig (CardanoBlock StandardCrypto )
ghci> fs = ioHasFS @IO $ MountPoint "db/ledger/4500000_db-analyser/"
ghci> Right st <- runExceptT $ readExtLedgerState @IO @(CardanoBlock StandardCrypto) (SomeHasFS fs) (decodeDiskExtLedgerState ccfg) decode $ mkFsPath ["state"]
ghci> getTip (fst st)
Point (At (Block {blockPointSlot = SlotNo 4500000, blockPointHash = f3c705ca66acf6f808f1aa775536a4c75ba917873bad5866f66dec31a771f119}))

[notunrandom]

I would like to try this out but I can't even get main to build. Do you know if the changes that might make this work are included in cardano-node 10.6.2? Or when they might be officially released?

[jasagredo]

but I can't even get main to build

main builds on every PR merge. What error are you getting?

Or when they might be officially released?

They will be included in 10.7. 10.6.2 is already out.

[notunrandom]

That's great, I look forward to the 10.7 release then.

(This is the error I get when trying to build main - I'm not using Nix, just cabal update; cabal build all, and this has worked for me on various release tags...)

Error: [Cabal-7107]
Could not resolve dependencies:
[__0] next goal: ouroboros-consensus (user goal)
[__0] rejecting: ouroboros-consensus; 0.30.0.1, 0.30.0.0, 0.29.0.0, 0.28.0.2, 0.28.0.1 (constraint from user target requires ==0.28.0.0)
[__0] trying: ouroboros-consensus-0.28.0.0
[__1] trying: blockio-0.1.1.1 (dependency of ouroboros-consensus)
[__2] trying: blockio:-serialblockio
[__3] next goal: blockio-uring (dependency of blockio -serialblockio)
[__3] rejecting: blockio-uring-0.1.0.2 (conflict: pkg-config package liburing>=2.0 && <3, not found in the pkg-config database)
[__3] rejecting: blockio-uring-0.1.0.1 (conflict: pkg-config package liburing>=2.0 && <2.12, not found in the pkg-config database)
[__3] rejecting: blockio-uring-0.1.0.0 (conflict: pkg-config package liburing>=2.0 && <2.10, not found in the pkg-config database)
[__3] fail (backjumping, conflict set: blockio, blockio-uring, blockio:serialblockio)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ouroboros-consensus, blockio-uring, blockio:serialblockio, blockio
Try running with --minimize-conflict-set to improve the error message.

[jasagredo]

I assume you are in Ubuntu, if so you have to install liburing (the error tells you about it pkg-config package liburing>=2.0 && <3, not found in the pkg-config database). It should be enough to do:

$ sudo apt install liburing-dev

[jasagredo]

Important detail, the snapshots you create with this db-analyser version will not work for 10.6 nodes. The serialization of TxIns is flipped so if you try to load it on a node everything will crash catastrophically.

[notunrandom]

Important detail, the snapshots you create with this db-analyser version will not work for 10.6 nodes. The serialization of TxIns is flipped so if you try to load it on a node everything will crash catastrophically.

But can I produce a snapshot from the db of a 10.6 node? In any case after producing a snapshot I have been using snapshot-converter to convert it to Legacy which is what Amaru currently can read.

[jasagredo]

The immutable and volatile data format does not change with the node version, so any immutable/volatile folder created by any node can be used by any other node or db-analyser.

About the snapshot-converter, I am the bringer of bad news: https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/utxo-hd/migrating#upgrading-a-ledger-snapshots-from-104x-to-105x. In short, the 10.6 or >10.6 snapshot-converter doesn't have a Legacy mode, it only converts among the different utxo-HD formats (InMem - LSM - LMDB).

It should not be very difficult to upgrade Amaru to be able to read these snapshots, at least the inmem one. When reading the state, once it is going to read the utxo map, go read the tables file which in the version on main and the what the 10.7 node will output is literally a CBOR encoding with shape [ {_ (TxId,BigEndian TxIx) => TxOut } ]. You can run cbor2pretty.rb on the tables file to verify the format.

That or implement a conversion to legacy again, but Im unsure it will work in snapshot-converter as now it streams the utxos, and to convert them back into the legacy format we need the whole thing in memory...

[notunrandom]

I confirm that db-analyser --store-ledger on main now works perfectly for me. Well done and thanks.