Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

FR - Query block

Aperta
  • Qualcosa non va?
#1,335 8 commenti 4 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
haskell
Ambito
blockchain, cli, databases

Direzione di ricerca

Inizia esaminando la struttura dei comandi di cardano-cli e il livello di storage di ouroboros-consensus, concentrandoti su ChainDB, ImmutableDB e VolatileDB. Determina quali indici esistenti supportano le ricerche per slot, hash e numero di blocco prima di definire la forma del comando. Il lavoro è completato quando un comando offline recupera il blocco di uno dei due database come CBORHex non elaborato su stdout e segnala i blocchi mancanti e la loro posizione nello storage.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Haskell
Stelle
72
Fork
26
Merge medio
3g 4h
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di IntersectMBO/cardano-cli

Tutte le issue di IntersectMBO/cardano-cli

Issue simili

Altre issue su Haskell

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.