Interacting with the Cardano Node · Assignment

Assignment 101: Node Inspector CLI

Artifact

A small multi-command Go CLI, built on gOuroboros, that connects to a Cardano node and reports on it: current chain tip and sync state, the contents of a specific block, and the node's pending mempool.

Required Task

Using the gOuroboros Starter Kit as your starting point, build a command-line tool that talks directly to a Cardano node over the Ouroboros protocols. Give it commands that each exercise a different mini-protocol:

  • tip / sync — connect via ChainSync and report the chain tip and how far the node has synced.
  • block — fetch a specific block via BlockFetch and print its identifying fields (slot, hash, transaction count).
  • mempool — query the node's pending transactions via LocalTxMonitor.

This is the node-interaction plumbing the DNS CLI sits on: before it can register or resolve a name, it needs to reach a node, know the chain is current, read blocks, and see what's pending. A Cobra structure here also carries straight over from 099.3.

The first three commands run over Node-to-Node (N2N) against a public preprod relay (magic 1) — e.g. preprod-node.world.dev.cardano.org:3001 (more relays in the Cardano environments list). The mempool command uses Node-to-Client (N2C) over a local Unix socket and therefore requires a local node — Dingo (Preview, magic 2) or cardano-node in Docker. If you don't run a local node, complete the first three commands against a relay and note the mempool command as infra-blocked.

Additional Exploration

Close the loop with submission: send a transaction (reuse your Module 102 wallet/builder, or the starter kit's TxSubmission path) and have your mempool command show it sitting in the local node's mempool before it's included in a block. As a lighter stretch, point tip at two different relays and observe whether they report the same tip slot.

Deliverables

  • Code — public repo or gist with the runnable CLI (gOuroboros, multi-command). The README lists each command and how to run it.

  • Runtime evidence — captured terminal output for each capability:tip/sync — connection established plus the reported chain tip and sync state.block — a specific block's slot, hash, and transaction count.mempool — the query result (pending transaction hashes, or an explicit "mempool empty"). Include the tip slot/block hash so it can be cross-checked on Cardanoscan Preprod.

    • tip/sync — connection established plus the reported chain tip and sync state.
    • block — a specific block's slot, hash, and transaction count.
    • mempool — the query result (pending transaction hashes, or an explicit "mempool empty"). Include the tip slot/block hash so it can be cross-checked on Cardanoscan Preprod.
  • Connection note — for each command, which access mode and endpoint you used (public relay over N2N vs. local node over N2C) and the network magic.

  • Course feedback (required): Written feedback on Module 101's lessons covering:Quality — what was clear, what was confusing, what was missing.Correctness — any code that didn't run, commands that failed, or steps that were wrong/out of date (cite the lesson number, e.g. 101.2).

    • Quality — what was clear, what was confusing, what was missing.
    • Correctness — any code that didn't run, commands that failed, or steps that were wrong/out of date (cite the lesson number, e.g. 101.2).

Assessment Criteria

  • SLT 101.1 — pass when the code connects to a node via gOuroboros (ChainSync, N2N) and the output shows a live connection.
  • SLT 101.2 — pass when the code fetches a specific block via BlockFetch and the output shows that block's identifying fields (slot, hash).
  • SLT 101.3 — pass when the program reports the node's sync state — the chain tip and how far the node has synced toward it.
  • SLT 101.4 — pass when the program queries the mempool via LocalTxMonitor against a local node and the output shows the result (pending tx hashes or an explicit empty mempool). Requires a local node; if infra-blocked, the learner must show the working code and a clear account of the blocker.
  • Course feedback — pass when feedback is specific and lesson-referenced (not "it was good"); flags at least one correctness issue OR one concrete improvement.

Notes

  • Network magic: preprod = 1, preview = 2, mainnet = 764824073 (do not target mainnet).
  • 101.4 is the only part that needs a local node. Dingo is the all-Go option (Preview, ~50 GB, Mithril snapshot bootstrap); cardano-node in Docker is the stable fallback. Both expose the N2C socket LocalTxMonitor needs.
  • Preprod mempool is often empty between transactions — the Additional Exploration (submit your own tx) is the reliable way to see a non-empty result.
  • *Lesson content for Module 101 is not yet written; this assignment is drafted from the SLTs and infrastructure-options.md. Reconcile command names and APIs against the lessons once they exist.*

What you'll demonstrate

  • 1 I can set up and run the gOuroboros Starter Kit to connect to a Cardano Node.
  • 2 I can fetch specific blocks from a remote Cardano Node.
  • 3 I can check how far a Cardano Node has synced with the blockchain.
  • 4 I can fetch information about pending transactions waiting in a Node's mempool.