Prepare Ledger State certification PoC

[jpraynaud]

Why

We need to prototype the certification of the ledger state snapshot of the Cardano node for which a deterministic snapshot is being implemented:

• [FEAT] - Snapshot at predictable points ouroboros-consensus#1424
• Predictable ledger state snapshots cardano-node#6526

What

Run the unreleased Cardano node in the devnet and assess requirements for the PoC.

How

• Prepare artifacts for the unreleased version of the Cardano node with this runbook
• Adapt the devnet with the configuration of the Cardano node to produce deterministic ledger state snapshots
• Assess the requirements to implement the PoC:
  • Cardano node
  • Mithril nodes

[turmelclem]

Checking deterministic ledger state snapshots

Using unreleased Cardano node producing deterministic snaphsot we where able to use it in our E2E test :
cargo run -p mithril-end-to-end -- -vvv --bin-directory target/release --devnet-scripts-directory=mithril-test-lab/mithril-devnet/ --run-only --work-directory=/tmp/e2e --cardano-binary-url=https://storage.googleapis.com/mithril-cardano-node-artifacts-test/cardano-node/11.0.1-integration/cardano-node-10.7.1-linux.tar.gz --cardano-node-version=11.0.1-integration --cardano-slot-length 0.1 --cardano-epoch-length 120

With those additional configuration.yml properties to produce ledger snapshots :

LedgerDB:
  # remains as-is
  Backend: V2InMemory
  Snapshots:

    # start taking the snaphots at slot 172800, after Byron
    SlotOffset: 120

    # take snapshots every 432000 slots, at the end of every Shelley epoch
    SnapshotInterval: 100

    # A minimum duration between snapshots, in seconds (used to avoid excessive snapshots while syncing).
    RateLimit: 0 # default is 10 minutes

    # randomised snapshot delay range, in seconds.
    # Both Min and Max need to be specified, otherwise the default delay of (5min, 10min) will be used
    MinDelay: 0
    MaxDelay: 0 

We were able to verify that each time the E2E test was run that the three nodes (node-full1, node-pool1, node-pool2) were producing the same snapshot at the same slot number (instead of standard Cardano were each node produce a snapshot at a different slot number).
And that each meta,state,tables files produces are the same between nodes by comparing there hash.

e2e/devnet/node-full1/db/ledger
├── 19079
│   ├── meta
│   ├── state
│   └── tables

sha256sum e2e/devnet/node-full1/db/ledger/19119/tables 0365d9ef66b2d2b5dcbd0d156ca5e028df09a0443bb9a83bc0dc3069a3539772
sha256sum e2e/devnet/node-pool1/db/ledger/19119/tables 0365d9ef66b2d2b5dcbd0d156ca5e028df09a0443bb9a83bc0dc3069a3539772
sha256sum e2e/devnet/node-pool2/db/ledger/19119/tables 0365d9ef66b2d2b5dcbd0d156ca5e028df09a0443bb9a83bc0dc3069a3539772

Signing the Ledger

If we want to sign the ledger snapshots we can create a new SignedEntityType for the Ledger and look for each meta, state, tables files inside node db/ledger directory and compute there hash (like we do to sign immutable files with CardanoDatabase signedEntityType).

• create a new SignedEntityType for the Ledger Snapshot
• create a MithrilSignableBuilderService (beacon ?)
• handle new signed entity type in compute_signed_entity_protocol_message
• implement a db ledger digester ? :
  • implement compute_merkle_tree (do we want to take hash of the three files (meta, state, tables) ?)
• Determine at which frequency we want to produce this snapshot
• ... (non exhaustive list)

[jpraynaud]

Computation of the snapshot parameters

Parameters:

• 21,600 slots per epoch in Byron
• 208 epochs for Byron
• 432,000 slots per epoch in Shelley

Parameters to use to create one ledger state snapshot in the middle of the epoch:

• Shelley beginning of epoch offset is 208 * 21,600 % 432,000 = 172,800 slots
• Half of Shelley epoch is 432,000 / 2 = 216,000
• Offset parameter is 172,800 + 216,000 = 388,800
• Interval parameter is 432,000

Legder state snapshot completion

The ledger state snapshot is complete once the meta file is written