@blinklabs/dingo 0.31.1 → 0.32.0

package/ARCHITECTURE.md

@@ -22,7 +22,7 @@ Dingo is a high-performance Cardano blockchain node implementation in Go. This d
 - [Transaction Mempool](#transaction-mempool)
 - [Block Production](#block-production)
 - [Mithril Bootstrap](#mithril-bootstrap)
-- [API Servers](#api-servers)
+- [External Interfaces](#external-interfaces)
 - [Design Patterns](#design-patterns)
 - [Threading and Concurrency](#threading-and-concurrency)
 - [Configuration](#configuration)
@@ -79,7 +79,7 @@ graph TB
         Meta["MetadataStore<br/>sqlite / postgres / mysql"]
     end
 
-    subgraph "API Servers"
+    subgraph "External Interfaces"
         URPC["UTxO RPC<br/><i>utxorpc/</i>"]
         BFA["Blockfrost API<br/><i>blockfrost/</i>"]
         Mesh["Mesh API<br/><i>mesh/</i>"]
@@ -490,10 +490,10 @@ dingo/
 │   ├── submit.go        # Submit service
 │   ├── sync.go          # Sync service
 │   └── watch.go         # Watch service
-├── bark/                # Bark archive block storage
-│   ├── bark.go          # HTTP server for block archive access
-│   ├── archive.go       # Archive blob store interface
-│   └── blob.go          # Blob store adapter with security window
+├── bark/                # Bark Dingo-to-Dingo C2 and archive protocol
+│   ├── bark.go          # Bark server lifecycle and transport setup
+│   ├── archive.go       # Archive service interface
+│   └── blob.go          # Remote archive blob adapter with security window
 ├── mithril/             # Mithril snapshot bootstrap
 │   ├── bootstrap.go     # Bootstrap orchestration
 │   ├── client.go        # Mithril aggregator client
@@ -538,7 +538,7 @@ type Node struct {
     ledgerState    *ledger.LedgerState            // UTXO/state tracking
     snapshotMgr    *snapshot.Manager              // Stake snapshot capture
     utxorpc        *utxorpc.Utxorpc               // UTxO RPC server
-    bark           *bark.Bark                     // Block archive server
+    bark           *bark.Bark                     // Bark C2/archive server
     blockfrostAPI  *blockfrost.Blockfrost         // Blockfrost REST API
     meshAPI        *mesh.Server                   // Mesh (Rosetta) API
     ouroboros      *ouroboros.Ouroboros            // Protocol handlers
@@ -557,7 +557,7 @@ When `Node.Run()` is called, components are initialized in this order:
  3. ChainManager initialization
  4. Ouroboros protocol handler creation
  5. LedgerState creation (UTXO tracking, validation)
- 6. Bark blob store adapter (if configured)
+ 6. Bark remote archive adapter (if configured)
  7. LedgerState start
  8. Snapshot manager start (captures genesis snapshot)
  9. Mempool setup
@@ -567,7 +567,7 @@ When `Node.Run()` is called, components are initialized in this order:
 13. Stalled client recycler (background goroutine)
 14. PeerGovernor (topology + churn + ledger peers)
 15. UTxO RPC server (if port configured)
-16. Bark archive server (if port configured)
+16. Bark C2/archive server (if port configured)
 17. Blockfrost API (if port configured)
 18. Mesh API (if port configured)
 19. Block forger + leader election (if block producer mode)
@@ -582,7 +582,7 @@ Graceful shutdown proceeds in phases:
 Phase 1: Stop accepting new work
   Block forger, leader election, chain selector,
   peer governor, snapshot manager, UTxO RPC,
-  Bark, Blockfrost API, Mesh API
+  Bark C2/archive server, Blockfrost API, Mesh API
 
 Phase 2: Drain and close connections
   Mempool, ConnectionManager
@@ -679,7 +679,7 @@ Dingo uses a dual-layer storage architecture with pluggable backends:
 Dingo supports two storage modes, configured via `storageMode`:
 
 - `core` (default): Minimal storage for chain following and block production.
-- `api`: Extended storage with transaction indexes, address lookups, and asset tracking. Required when any API server (Blockfrost, Mesh, UTxO RPC) is enabled.
+- `api`: Extended storage with transaction indexes, address lookups, and asset tracking. Required when any client-facing API server (Blockfrost, Mesh, UTxO RPC) is enabled. Bark is a separate Dingo-to-Dingo protocol and is not part of that API surface.
 
 ### Tiered CBOR Cache
 
@@ -977,13 +977,13 @@ The `mithril/` package enables fast initial sync by downloading and importing a
 
 This is exposed via the `dingo mithril` CLI subcommand and the `dingo load` command.
 
-## API Servers
+## External Interfaces
 
-Dingo provides multiple API interfaces, all optional and gated by port configuration. All require `storageMode: api`.
+Dingo provides three client-facing APIs plus Bark. All are optional and gated by port configuration. UTxO RPC, Blockfrost, and Mesh are general-purpose external APIs and require `storageMode: api`. Bark is different: it is Dingo's own protocol for Dingo-to-Dingo C2/archive services, not a general-purpose application API.
 
 ### Blockfrost API (`blockfrost/`)
 
-A Blockfrost-compatible REST API that provides read access to chain data. Uses an adapter pattern to translate between Dingo's internal state and Blockfrost response types. Supports cursor-based pagination.
+A Blockfrost-compatible REST API that provides read access to chain data. The current implementation exposes the latest, epoch, network, and pool subset. It uses an adapter pattern to translate between Dingo's internal state and Blockfrost response types and supports cursor-based pagination.
 
 ### Mesh API (`mesh/`)
 
@@ -995,7 +995,7 @@ A gRPC server implementing the UTxO RPC specification with query, submit, sync,
 
 ### Bark (`bark/`)
 
-An HTTP server for block archive access. Also acts as a blob store adapter with a configurable security window, allowing Dingo to fetch historical blocks from a remote Bark instance instead of storing them locally.
+Bark is Dingo's own protocol for Dingo-to-Dingo control-plane and archive services. It exposes archive access over Connect/gRPC and also supplies a remote archive adapter with a configurable security window, allowing Dingo to fetch historical blocks from a remote Bark instance instead of storing them locally.
 
 ## Design Patterns
 
@@ -1066,7 +1066,7 @@ Key configuration areas:
 - CBOR cache sizing (hot entries, block LRU)
 - Chainsync client limits and stall timeout
 - Block producer credentials (VRF key, KES key, operational certificate)
-- API server ports (Blockfrost, Mesh, UTxO RPC, Bark)
+- External interface ports (Blockfrost, Mesh, UTxO RPC, Bark)
 
 ## Stake Snapshots
 

package/README.md

@@ -22,7 +22,7 @@ A high-performance Cardano blockchain node implementation in Go by Blink Labs. D
 - Peer governance with dynamic peer selection, ledger peers, and topology support
 - Chain rollback support for handling forks with automatic state restoration
 - Fast bootstrapping via built-in Mithril client
-- Multiple API servers: UTxO RPC, WIP Blockfrost-compatible REST, Mesh (Coinbase Rosetta)
+- Multiple external interfaces: general-purpose APIs (UTxO RPC, Blockfrost-compatible REST, Mesh/Rosetta) plus Bark for Dingo-to-Dingo C2 and archive services
 
 Note: On Windows systems, named pipes are used instead of Unix sockets for node-to-client communication.
 
@@ -132,11 +132,15 @@ docker run -p 3001:3001 \
 
 The image is based on Debian bookworm-slim and includes `cardano-cli`, `nview`, and `txtop`. Mithril snapshot support is built into dingo natively (`dingo mithril sync`). The Dockerfile sets `CARDANO_DATABASE_PATH=/data/db` and `CARDANO_SOCKET_PATH=/ipc/dingo.socket`, overriding the local defaults of `.dingo` and `dingo.socket` — the volume mounts above map to these container paths.
 
-| Port | Service |
-|------|---------|
-| 3001 | Ouroboros NtN (node-to-node) |
-| 3002 | Ouroboros NtC over TCP |
-| 12798 | Prometheus metrics |
+| Port | Service | Default |
+|------|---------|---------|
+| 3001 | Ouroboros NtN (node-to-node) | Enabled |
+| 3002 | Ouroboros NtC over TCP | Enabled |
+| 12798 | Prometheus metrics | Enabled |
+| 3000 | Blockfrost REST API | Disabled |
+| 8080 | Mesh (Rosetta) REST API | Disabled |
+| 9090 | UTxO RPC (gRPC) | Disabled |
+| — | Bark archive (gRPC) | Disabled (example when enabled: 9091) |
 
 ## Storage Modes
 
@@ -161,15 +165,16 @@ Or in `dingo.yaml`:
 storageMode: "api"
 ```
 
-## API Servers
+## API Servers and Bark
 
-Dingo includes three API servers. All APIs require `storageMode: "api"` and start automatically on their default ports in that mode. Set an individual port to 0 to disable a specific API. The Blockfrost server provides a WIP Blockfrost-compatible REST API with a growing subset of the compatibility surface.
+Dingo includes three general-purpose external APIs plus Bark. UTxO RPC, Blockfrost, and Mesh are client-facing APIs and require `storageMode: "api"`. Bark is different: it is Dingo's own protocol for Dingo-to-Dingo C2/archive services, not a general-purpose application API. Set an individual port to 0 to disable a specific interface. The Blockfrost server currently exposes the latest, epoch, network, and pool subset.
 
-| API | Port Env Var | Default | Protocol |
-|-----|-------------|---------|----------|
-| UTxO RPC | `DINGO_UTXORPC_PORT` | disabled | gRPC |
-| Blockfrost | `DINGO_BLOCKFROST_PORT` | disabled | REST |
-| Mesh (Rosetta) | `DINGO_MESH_PORT` | disabled | REST |
+| Interface | Port Env Var | Default | Protocol | Role |
+|-----------|--------------|---------|----------|------|
+| UTxO RPC | `DINGO_UTXORPC_PORT` | disabled | gRPC | General-purpose client API |
+| Blockfrost | `DINGO_BLOCKFROST_PORT` | disabled | REST | General-purpose client API |
+| Mesh (Rosetta) | `DINGO_MESH_PORT` | disabled | REST | General-purpose client API |
+| Bark | `DINGO_BARK_PORT` | disabled | Connect/gRPC | Dingo-to-Dingo C2/archive protocol |
 
 ```bash
 # Enable Blockfrost API on port 3100 and UTxO RPC on port 9090

package/RELEASE_NOTES.md

@@ -1,6 +1,39 @@
 # Release Notes
 
 
+## v0.31.1 (April 4, 2026)
+
+**Title:** Clearer rollback recovery outcomes
+
+**Date:** April 4, 2026
+
+**Version:** v0.31.1
+
+Hi folks! Here’s what we shipped in v0.31.1.
+
+### ✨ What's New
+
+- **Clearer rollback recovery status:** Recovery is simpler to understand because chain recovery now reports clearer outcomes after a local rollback.
+
+### 💪 Improvements
+
+- **More consistent recovery staleness checks:** Recovery decisions are more rock-solid because staleness checks are now based on the primary chain tip.
+
+### 🔧 Fixes
+
+- **Rollback-aware recovery test coverage:** Reliability is more rock-solid because recovery and chainsync tests now validate rollback-aware behavior.
+
+### 📋 What You Need to Know
+
+- **No action required:** You're all set—just upgrade to v0.31.1.
+
+### 🙏 Thank You
+
+Thank you for trying!
+
+---
+
+
 ## v0.31.0 (April 3, 2026)
 
 **Title:** Storage safeguards and smarter peer sync

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blinklabs/dingo",
-  "version": "0.31.1",
+  "version": "0.32.0",
   "description": "Dingo is a Cardano blockchain data node",
   "main": "index.js",
   "bin": {