Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

FR - Query block

Open
#1,335 8 comments 4 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
haskell

Research direction

Start by examining the cardano-cli command structure and the ouroboros-consensus storage layer, focusing on ChainDB, ImmutableDB, and VolatileDB. Determine which existing indexes support slot, hash, and block-number lookups before defining the command shape. Done means an offline command retrieves either database's block as raw CBORHex on stdout and reports missing blocks and their storage location.

Written by the indexing model from the issue text.

Description

Problem

As cardano-node operators, we currently have no straightforward way to access the raw content of a block stored in our local ChainDB. When debugging network incidents — particularly forks and network partitions — the ability to inspect individual blocks is critical.

Proposed Solution

Add a CLI command (either as part of cardano-cli or as a standalone tool) that can retrieve a block directly from the ChainDB on disk and output its CBORHex to stdout.

Retrieve by slot number

cardano-cli debug get-block --db /path/to/db --slot 83413505

Retrieve by block hash

cardano-cli debug get-block --db /path/to/db --hash e60aa1eb682ac5...

Retrieve by block number

cardano-cli debug get-block --db /path/to/db --block-number 4043212

Why

During a recent network partition, we needed to compare block contents across nodes to understand the fork. The process was painful because:

  1. Debugging is time-sensitive — During incidents, you need to inspect blocks quickly. Having to restart nodes or set up special queries adds delay at the worst possible time.

Implementation Considerations

The ChainDB is split into two components:

  • ImmutableDB — Stores finalized blocks (older than k slots from the tip). Blocks are stored in chunk files and indexed by slot number. This is where most historical lookups would go.
  • VolatileDB — Stores recent blocks that have not yet been finalized. These are the blocks most relevant during fork investigations, since competing chains live here until one wins.

A viable approach would be to read the ChainDB directly on disk, bypassing the node process entirely. Does ouroboros-consensus library provides the storage layer types and indexing logic? The key question is which block identifiers are supported by the existing index structures: Slot number, Block hash, Block number?

The command should:

  • Work offline (no running node required)
  • Output raw CBORHex to stdout (composable with other tools via pipes)
  • Support both ImmutableDB and VolatileDB lookups.
  • Report when a block is not found, or when it exists, id it's in the Immutable or in the Volatile Db.
Dominant language
Haskell
Stars
71
Forks
24
Avg merge
1d 5h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IntersectMBO/cardano-cli

All issues in IntersectMBO/cardano-cli

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.