クイックスタートガイド

Dingo

Dingoは、Go言語で書かれたCardanoブロックチェーンデータノードであり、Ouroboros Network Node-to-Nodeミニプロトコルファミリーを使用して、Cardanoブロックチェーン上のネットワーク通信に積極的に参加します。

⚠️ これは開発中のプロジェクトであり、現在活発に開発が進められています

このガイドでは、Dingoバイナリのダウンロードと、Cardano PreviewネットワークでDingoノードを実行するために必要なすべての手順を説明します。以下の手順に従って始めましょう。

✅ このガイドは一般的なLinux環境を前提としています。必要に応じてコマンドとパスを調整してください。

ステップ1 - Dingoバイナリのダウンロード

Dingoリリースページから最新リリースをダウンロードします。

⚠️ お使いのシステムに合わせて、バージョン（以下の例ではv0.86.0）とアーキテクチャを調整してください。

mkdir -p ~/dingo
cd ~/dingo
wget https://github.com/blinklabs-io/dingo/releases/download/v0.86.0/dingo-v0.86.0-linux-amd64.tar.gz -O - | tar -xz

以下を実行してバイナリが動作することを確認できます：

./dingo version

npmを使用する場合（代替方法）

Node.js 22以降とtarが必要です。npmパッケージはLinux、FreeBSD、macOSのx64（amd64）またはarm64をサポートします。

次のコマンドでグローバルインストールし、動作を確認します：

npm install --global @blinklabs/dingo
dingo --help

パッケージは対応するバージョンのリリースアーカイブを取得し、組み込まれたSHA-256チェックサムを検証してからネイティブバイナリをインストールします。グローバルインストールを使用する場合、以降のコマンドでは./dingoをdingoに置き換えてください。グローバルにインストールしない場合は、次のコマンドで確認できます：

インストーラーは、承認済みのHTTPSリリースアセットだけを使用します。資格情報を含むURL、443以外のポート、許可されていないURLを拒否します。リダイレクト先やDNSの解決先がプライベートまたは特殊用途アドレスの場合も拒否します。

npx @blinklabs/dingo --help

ローカル単一ノードDevnetの実行

設定ファイルなしでローカル単一ノードDevnetを起動します：

./dingo devnet

npmパッケージをグローバルにインストールした場合はdingo devnetを、そうでない場合は次のコマンドを実行します：

npx @blinklabs/dingo devnet

--data-dirを指定しない場合、Dingoは設定、テストキー、チェーンデータを専用の一時ディレクトリに保存し、プロセス終了時にそのディレクトリを削除します。実行するたびに新しいチェーンが開始されます。

Devnetは、ローカルテスト用のfaucet認証情報をcardano/keys/に配置します。Dingoが配置するファイルは次の3つです：

faucet.skey
faucet.vkey
faucet.addr

一時実行では、Dingoはこれらのファイルを専用の一時ディレクトリ内のcardano/keys/に配置し、プロセス終了時に一時ディレクトリごと削除します。--data-dir ./.dingo-devnetを指定する永続実行では、Dingoは<data-dir>/cardano/keys/に配置します。Dingoはファイルとディレクトリに所有者だけがアクセスできる権限を設定します。

genesis時点で、Dingoはfaucet.addrのアドレスに900,000 test ADA（900_000_000_000 lovelace）を割り当てます。

チェーンを保持して再利用するには、永続データディレクトリを指定します：

./dingo devnet --data-dir ./.dingo-devnet

同じコマンドを再度実行すると、そのチェーンを再開します。--resetを指定せずに永続Devnetを再開すると、Dingoはfaucet認証情報だけを復元または更新し、producer認証情報、genesisの割り当て、チェーンデータを保持します。Dingoが管理する状態を意図的に再作成し、ディレクトリ内の無関係なファイルを保持するには、次のコマンドを実行します：

./dingo devnet --data-dir ./.dingo-devnet --reset

永続データディレクトリを初めて使用するときは、空のディレクトリを指定してください。Dingoは、ノードの実行中に同じディレクトリを使用する別の起動を拒否します。

組み込みのキーとネットワークはローカルテスト専用です。実際の資金には使用しないでください。

ステップ2 - dingo.yaml設定ファイルの作成

Dingo v0.86.0の全設定、既定値、環境変数、コマンドラインでの上書きについては、設定リファレンス（英語）を参照してください。同じリリースのdingo.yaml.exampleをダウンロードして、設定の出発点として利用できます。

Dingoには、preview、preprod、mainnet向けのCardanoネットワーク設定（genesisファイル、config.json）と、prime-testnet向けの設定（genesisファイル、configuration.yaml）が組み込まれています。これらを別途ダウンロードする必要はありません。

dingoディレクトリにdingo.yamlファイルを作成します。$HOME変数は自動的にホームディレクトリのパスに展開されます：

cat <<EOF > ~/dingo/dingo.yaml
# Storage
databasePath: "$HOME/dingo/.dingo"

plugins:
  storage:
    blob:
      provider: "badger"
      config:
        # dataDir は任意で、指定しなければ databasePath を使います。
        # dataDir: "$HOME/dingo/.dingo"
        blockCacheSize: 0
        compression: false
        gc: true
        indexCacheSize: 0
    metadata:
      provider: "sqlite"
      config:
        # dataDir は任意で、指定しなければ databasePath を使います。
        # dataDir: "$HOME/dingo/.dingo"
  mempool:
    provider: "default"
    config:
      # capacity は任意で、コメントアウトするとモードの既定値を使います。
      # 既定値: 通常のモードでは 1048576 (1 MiB)、leios モードでは 26214400 (25 MiB) です。
      # capacity: 1048576
  api:
    blockfrost:
      provider: "builtin"
      config:
        port: 3000
    mesh:
      provider: "builtin"
      config:
        port: 8080
    utxorpc:
      provider: "builtin"
      config:
        port: 9090

# Mithril
mithril:
  aggregatorUrl: ""
  # pinnedDigest: ""
  cleanupAfterLoad: true
  enabled: true
  verifyCertificates: true

# Network
bindAddr: "0.0.0.0"
# PrometheusはbindAddrとは独立したアドレスを使用し、既定値はループバックです。
# --metrics-bind-addr CLIフラグまたはDINGO_METRICS_BIND_ADDR環境変数で上書きできます。metricsPort: 0にするとメトリクスリスナーを無効にします。
metricsBindAddr: "127.0.0.1"
metricsPort: 12798
# healthPort は --health-port CLI フラグまたは DINGO_HEALTH_PORT 環境変数で設定できます。healthPort: 0 にするとリスナーを無効にします。
healthPort: 12799
# healthReadyGapSlots は --health-ready-gap-slots CLI フラグまたは DINGO_HEALTH_READY_GAP_SLOTS 環境変数で設定できます。
healthReadyGapSlots: 1000
debugPort: 0
network: "preview"
privateBindAddr: "127.0.0.1"
privatePort: 3002
maxNtCConns: 100
maxNtCConnectionsPerIP: 5
relayPort: 3001
socketPath: "$HOME/dingo/dingo.socket"

# API and Bark
barkBaseUrl: ""
barkPort: 0
storageMode: "core"
midnight:
  serverEnabled: false
  reflectionEnabled: false
  allowInsecureRemote: false
  port: 50051
  host: "127.0.0.1"
  authTokenPolicyId: ""
  authTokenAssetName: ""

EOF

📝 debugPort はプロファイリングが必要な場合を除き 0 のままにします。debugPort は任意の pprof リスナーを制御し、metricsPort とは別で、0 のときは無効のままです。

📝 maxNtCConns は --max-ntc-conns または DINGO_MAX_NTC_CONNS で設定でき、maxNtCConnectionsPerIP は --max-ntc-connections-per-ip または DINGO_MAX_NTC_CONNECTIONS_PER_IP で設定できます。既定値はそれぞれ 100 と 5 です。0以下の値は無視されます。

📝 skipRewardLiveStakeBackfillCheck は高度な診断用オプションです。既定値は false なので、通常の起動ではこの値を使用してください。true にすると高コストな reward_live_stake 起動時整合性スキャンだけを省略します。DingoはStaleConsensusStakeSnapshotsExist によるコンセンサスステークスナップショットの来歴チェックを常に実行し、必要な場合は起動を拒否します。

💡 API サーバーは storageMode: "api" のときだけ有効です。各 API の port を 0 にすると、その API は無効になります。

💡 Midnight gRPC サーバーには storageMode: "api"、midnight.serverEnabled: true、および midnight.port の 0 以外の値が必要です。インデックス作成とサーバー公開は別々に制御されます。midnight.reflectionEnabled は midnight.serverEnabled が true の場合にのみ有効で、midnight.serverEnabled が false の場合はリスナーも無効です。

📝 midnight.host の既定値は "127.0.0.1" です。midnight.host: "" もループバックを使用します。非ループバックの平文リスナーには midnight.allowInsecureRemote: true が必要です。TLS 証明書とキーのペアを設定すると、リモート TLS 公開を使用できます。

📝 API ストレージモードで Midnight インデックスを使用する場合、midnight.authTokenPolicyId と midnight.authTokenAssetName は両方を設定するか、両方とも空のままにします。一方だけを設定すると、起動時の設定検証に失敗します。authTokenPolicyId には56桁の16進数（デコード後28バイト）を指定します。両方を設定した場合、Dingoは指定したポリシーIDとアセット名に完全一致する認証トークンだけを照合します。

💡 block-cache-sizeとindex-cache-sizeを0に設定し、compression: falseにすると、BadgerDBの内部キャッシュの代わりにOSのページキャッシュ（mmap）が使用されます。これによりメモリ使用量が大幅に削減されます。

ステップ3 - ポートの開放

Dingoに必要なポートに対するUFWファイアウォールルールの追加方法について説明します。

💡 ヒント: UFWはUncomplicated Firewallの略で、iptables（netfilter）ファイアウォールルールの管理に使用されます。

現在開いているポートを確認するには：

sudo ufw status numbered

Ouroboros Node to Node（NtN）通信用のポート3001を追加

sudo ufw allow 3001/tcp

ステップ4 - Mithrilスナップショットからのブートストラップ

Dingoには、スナップショットを自動的にダウンロードしてロードする組み込みのMithrilクライアントがあります。これにより、genesisからチェーンをリプレイする場合と比較して、数時間の同期時間を節約できます。

dingoディレクトリから以下のコマンドを実行します：

cd ~/dingo
./dingo mithril sync --config ~/dingo/dingo.yaml

📝 mithril.downloadMaxTransientRetries は、TLS タイムアウト、HTTP 429 応答、HTTP 5xx 応答などの一時的なブートストラップダウンロード障害に対する再試行回数を制御します。例では既定値の 10 を使用しています。

Dingoは次の処理を行います：

設定したネットワークの最新Mithrilスナップショットをダウンロード
証明書チェーンを検証
スナップショットをデータベースにロード

これにはシステムとネットワーク速度によって、約10〜15分かかります。

📝 このステップをスキップした場合、Dingoは起動時にgenesisから同期するため、はるかに長い時間がかかります。

📝 Dingoはポート 12799 でヘルスプローブを提供します。/health と /healthz はイベントループの応答性を含む稼働確認に、/readyz はレディネス確認に使用します。/readyz は、先端とのギャップを取得でき、そのギャップが healthReadyGapSlots の設定値を超えていないことに加えて、データベースを読み取れることを必要とします。ブロックプロデューサーの場合は、実行中のフォージャーと使用可能な認証情報も必要です。リモートKESを使用する場合は、リモートKESが準備完了であることも必要です。ヘルスプローブは Mithril のブートストラップ中も利用できます。コンテナのヘルスチェックは /metrics ではなく /health を使用します。

ステップ5 - Dingoの起動

Mithrilスナップショットがロードされたら、ノードを起動します：

cd ~/dingo
./dingo serve --config ~/dingo/dingo.yaml

ノードがピアに接続し、チェーン先端に到達するために残りのブロックを同期するログ出力が表示されるはずです。

コンピューターが再起動したときにDingoノードを自動的に再起動して稼働時間を最大化するためのsystemdサービスの使用に興味がありますか？

Dingoのスタートアップサービスを作成する方法についてのガイドを参照してください。

おめでとうございます。Dingoノードを使用する準備が整いました！

Cardano CLIを使用してDingoと対話する方法を学ぶ。

Docs authored by Doc Holiday

ページを編集

最終更新日: 2026/10/22

前へ
Dingo 次へ
スタートアップサービスの作成