Skip to main content
Injectiveのバリデーターおよびノードオペレーター向けのトラブルシューティングリファレンスと運用ガイドです。よくある障害パターン、復旧手順、アップグレードチェックリスト、および重要な安全対策を説明します。

​
はじめに：重要な安全ルール

絶対にしてはいけないこと
  1. 同じ priv_validator_key.json を持つ2つのノードを同時に実行しないでください。 二重署名が発生し、スラッシュは0%ですが、恒久的なトゥームストーン（tombstone）につながります。そのバリデーターは二度とアクティブセットに復帰できません。
  2. 結果を完全に理解していない限り、バリデーターノードで unsafe-reset-all を使用しないでください。 コンセンサスstateが消去され、トゥームストーンにつながる矛盾した投票を生成する可能性があります。
  3. ノードが稼働中の状態で priv_validator_state.json をバックアップしないでください。 このファイルはコンセンサス中に絶えず変化します。まずノードを完全に停止してからコピーしてください。
  4. バックアップした priv_validator_state.json を復元せずに、スナップショット復旧後のノードを起動しないでください。 スナップショットにはこのファイルが含まれません。復元せずに起動すると署名stateがブロック高0にリセットされ、二重署名を引き起こします。
  5. アーカイブノードや大きな履歴を持つノードは、事前にテストせずにロールバックしないでください。 大規模なデータベースでのロールバックは数時間かかるか、ノードを完全に使用不能にする可能性があります。特にPebbleDBでは注意が必要です。
必ずすべきこと
  1. ロールバック、スナップショット復元、バイナリアップグレードなどの復旧作業の前には、必ずノードを完全に停止してから priv_validator_state.json をバックアップしてください。
  2. ロールバックやスナップショット復旧の後、ノードを起動する前に、必ず priv_validator_state.json を元の場所に復元してください。
  3. ノードを起動する前に、必ず priv_validator_state.json が破損していないことを確認してください。 height、round、stepの値が妥当かどうかをチェックしてください。
  4. 協調アップグレードでは必ず --halt-height を設定してください。 halt-heightフラグを設定しなかったノードは、より困難な復旧手順が必要になります。
  5. アップグレード後の起動前に、必ず injectived version でバイナリのバージョンを確認してください。
  6. チェーンが安定したら、一時的なコンセンサスの上書き設定（--unsafe-consensus-timeout-precommit-delta=1ms など）を必ず元に戻してください。
復旧用のスナップショットが必要ですか？ プルーニングされたスナップショットとコミュニティプロバイダーについては、このページの下部にあるスナップショットリソースを参照してください。アーカイブセグメントのスナップショットについては、アーカイブセットアップページを参照してください。

​
よくある問題と解決策

​
アップグレード高でノードが停止したまま進まない

症状：
  • ノードログに、想定されたアップグレード高でチェーンが停止したことが表示される
  • latest_block_height が停止高を超えて進まない
原因： ノードが古いバイナリを実行しています。チェーンはアップグレード高を超えて進むために、アップグレード済みのバイナリを必要とします。 解決策：
  1. ノードを停止する
  2. ~/.injectived/data/priv_validator_state.json をバックアップする
  3. 新しいバイナリをインストールする
  4. 確認する：injectived version
  5. ノードを起動する

​
アップグレード後のブロックヘッダーハッシュの不一致

症状：
ノードが継続的にnilにprevoteし、次のブロックをファイナライズできません。 原因： アップグレード高におけるノードのローカルstateが、新しいバイナリが期待するstateと一致していません。これは、アップグレード前に古いバイナリのロジックでhalt-heightのブロックを処理してしまった場合に発生します。 解決策：
  1. ノードを停止する
  2. priv_validator_state.json をバックアップする
  3. 1ブロックロールバックする：
  4. priv_validator_state.json を復元する
  5. 新しいバイナリでノードを起動する
大規模なデータベース（数百GB）を持つアーカイブノードでのロールバックは、非常に長い時間がかかるか失敗する可能性があります。これらのノードでは、代わりにスナップショットから復旧してください。

​
矛盾した投票（conflicting vote）の警告

症状：
このメッセージが継続的に繰り返されます。 原因： ノードの priv_validator_state.json がリセットまたは破損したため、すでに署名済みのラウンドに再度署名し、矛盾した投票を生成しています。 よくある引き金：
  • バリデーターで unsafe-reset-all を実行した
  • 古い、または誤った priv_validator_state.json を復元した
  • ノードが稼働中の状態で priv_validator_state.json をバックアップした（古いコピー）
  • rollbackコマンドがバリデーターstateをリセットした
解決策：
  • （ノードを完全に停止した後に取得した）正しい priv_validator_state.json のバックアップがある場合：それを復元して再起動してください。
  • 正しいバックアップがない場合：直ちにノードを停止し、ブロック生成が再開されるのを待ってから再起動してください。 誤ったstateで起動すると二重署名のリスクがあります。
  • 署名情報を確認する：
矛盾した投票がオンチェーンで検出されると、バリデーターはトゥームストーン（恒久的なジェイル）になります。二重署名に対するオンチェーンでのunjailは存在しません。

​
バリデーターがトゥームストーンされた（二重署名）

症状：
原因： バリデーターが同じブロック高で2つの異なるブロックまたはprevoteに署名しました。よくある引き金：
  • 同じ署名キーでノードの2つのインスタンスを実行した
  • 古い priv_validator_state.json を復元したことで、すでに署名済みのブロック高で再署名が発生した
  • ロールバックによって署名stateがリセットされ、その後ノードが矛盾したブロックに署名した
対応方法： トゥームストーンされたバリデーターに対する標準的なオンチェーンのunjailは存在しません。対応の選択肢：
  • 影響を受けたバリデーターのトゥームストーンを明示的に解除するガバナンスプロポーザルまたはアップグレードハンドラー
  • 新しいオペレーターキーで新しいバリデーターを作成する（既存のデリゲーションは失われます）
協調セキュリティアップグレード中にトゥームストーンされた場合は、直ちに認証済みバリデーターチャンネルでInjectiveチームに連絡してください。協調アップグレードの際、チームは影響を受けたバリデーターを復旧するためのトゥームストーン解除ハンドラーをアップグレードバイナリに含めることがあります。時間に敏感な対応であるため、アップグレードハンドラーが確定する前に含めてもらえるよう、できるだけ早く報告してください。
予防策：
  • ハードウェアで強制されるシングルサイナーのセマンティクスのために、TMKMSまたはHorcruxを使用する
  • ノードを停止した後に必ず priv_validator_state.json をバックアップする
  • 同じ署名キーで2つのノードを同時に実行しない

​
スナップショットからの復旧

使用すべきタイミング： ロールバックが失敗する、時間がかかりすぎる、またはノードのstateが修復不可能なほど破損している場合（AppHashの不一致）。 手順：
  1. ノードを完全に停止する
  2. ~/.injectived/data/priv_validator_state.json をバックアップする
  3. 他の場所にバックアップしていない場合は ~/.injectived/config/priv_validator_key.json もバックアップする
  4. 信頼できるプロバイダーからスナップショットをダウンロードする：
    • Injectiveチームがセキュリティアップグレードの前や最中に緊急スナップショットを共有する場合もあります
    • Polkachu Injective Snapshots（通常goleveldb）
    • コミュニティのバリデーターがインシデント時に緊急スナップショットを共有することがあります
  5. 古いデータを削除する：
  6. スナップショットを ~/.injectived/data/ に展開する
  7. バックアップしておいた priv_validator_state.json を ~/.injectived/data/ に復元する
  8. priv_validator_state.json が存在し、内容が正しいことを確認する
  9. ノードを起動する

​
自分の priv_validator_state.json を必ず保持しなければならない理由

スナップショットにはブロックチェーンデータ（ブロック、アプリケーションstate）が含まれますが、バリデーターの署名stateは決して含まれません。署名stateは、バリデーターが最後に署名したheight、round、stepを記録しています。これを失ったり空のファイルで置き換えたりすると、ノードは自分がすでに何に署名したかを認識できず、矛盾したブロックに署名する可能性があります。その結果、二重署名と恒久的なトゥームストーンが発生します。 署名stateが常にスナップショットのブロック高以上でなければならない理由を示す、実践的な例を挙げます。 前提： ブロック125をhalt-heightとする協調チェーンアップグレード。
停止時点で、あなたの priv_validator_state.json は次のようになっています：
停止高が125なのに、なぜheightが126になっているのでしょうか？ --halt-height フラグはブロック126がコミット（ファイナライズ）されるのを防ぎますが、CometBFTコンセンサスエンジンはそれでもブロック高126に入り、アプリケーション層がブロックの処理を拒否してノードがシャットダウンするまで、そのラウンド（プロポーズ、prevote、precommit）を開始します。高いラウンド番号（42）は、バリデーターが徐々に停止していく中でコンセンサスに到達できず、ネットワークがラウンドを重ねたことを反映しています。これは正常な動作です：ブロック126は一度もファイナライズされなかったにもかかわらず、あなたのバリデーターはブロック高126で実際に投票を行ったのです。 つまり、あなたのバリデーターはすでにブロック高126、ラウンド42で投票を行っています。利用可能なスナップショットはブロック高115のものです。 署名stateなしでスナップショットを復元するとどうなるか： スナップショットには priv_validator_state.json が含まれないか、空のもの（height 0）が付属します。この状態でノードを起動すると：
  1. ノードはブロック高115からブロックチェーンデータをロードする
  2. ブロック116〜125をリプレイしてブロック高126まで追いつく
  3. ブロック高126でコンセンサスに入り、ラウンド0から署名を開始する
  4. しかし、ネットワークにはこのブロック高でのラウンド42のあなたの投票がすでに存在する
  5. あなたのノードはブロック高126で別のブロック提案に署名する（新しいバイナリでリプレイしたため、異なる結果を生成する可能性がある）
  6. ネットワークが、あなたのバリデーターキーからの2つの矛盾した署名を検出する
  7. あなたのバリデーターは二重署名となり、トゥームストーンされます。恒久的に。
正しい手順：
  1. ノードを停止する
  2. priv_validator_state.json をバックアップする（height 126、round 42と記録されている）
  3. データディレクトリを削除する
  4. スナップショット（ブロック高115からのブロックチェーンデータ）を展開する
  5. バックアップした priv_validator_state.json をデータディレクトリに書き戻す
  6. ノードを起動する
このときノードが起動すると：
  1. ブロック高115からブロックチェーンデータをロードする
  2. ブロック116〜125をリプレイしてブロック高126まで追いつく
  3. ブロック高126で署名stateを読み取る：「ラウンド42まではすでに署名済み」
  4. ラウンド0〜42をスキップし、新たに署名する前にラウンド43を待つ
  5. 矛盾した投票は発生しません。あなたのバリデーターは安全です。
重要なルール： 署名stateは、バリデーターがこれまでに署名した最も高い地点を常に反映していなければなりません。署名stateがスナップショットより先にあるのは安全です（ノードが追いつきます）。署名stateが、バリデーターがネットワーク上で実際に署名した地点より後ろにあることは決して安全ではありません。
データベースバックエンドの互換性： スナップショットはバックエンド固有です。goleveldbのスナップショットはpebbledb向けに設定されたノードでは動作せず、その逆も同様です。設定を確認してください：

​
ロールバックがハングまたは失敗する

症状： injectived rollback は実行されるが完了しない、またはエラーを出力する。 原因：
  • PebbleDBバックエンド： pebbleでのロールバックには既知の問題があり、無期限にハングする可能性があります
  • 非常に大きなデータベース： ロールバック時間はデータベースのサイズに比例します
  • 破損したWAL（Write-Ahead Log）
解決策：
  • PebbleDBノードの場合：代わりにスナップショットから復旧してください
  • 大規模ノードの場合：ロールバックが30分以上経っても完了しない場合は中断し、スナップショットを使用してください
  • goleveldbへの切り替えを検討してください。PebbleDBはスペース効率に優れていますが、ロールバックに関するテストは十分ではありません

​
キャッチアップ中のラウンド後退エラー

症状：
原因： ノードが現在のコンセンサスラウンドに追いついている途中です。多くのラウンドを経て進行中のアクティブなコンセンサスラウンドの最中にノードを再起動した場合、これは正常かつ想定された動作です。 解決策： 対応は不要です。ノードは追いつきます。ラウンドのキャッチアップを高速化するには：
チェーンが安定し、ノードが追いついたら、この上書き設定を削除してください。 デフォルト（100ms）に戻して再起動してください。通常運用中にこの設定を残しておくと、1msのデルタによって、投票がネットワークを伝播できる速度よりはるかに速くラウンドが進んでしまいます。他のバリデーターのprecommitが届く前にあなたのバリデーターは次のラウンドへ移ってしまい、その投票は実際のコミットラウンドを外してしまいます。その結果、ブロックミスのカウンターが着実に増え続け、十分な数のブロックをミスすると（通常、直近10,000ブロック中500ブロック）、バリデーターはダウンタイムによりジェイルされます。

​
AppHashの不一致

症状：
原因： アプリケーションstateがコンセンサスstateから乖離しました。不完全なアップグレード、ブロック実行中のクラッシュ、またはデータベースの破損によって発生する可能性があります。 解決策：
  1. ロールバックを試す：injectived rollback
  2. ロールバックが失敗するかエラーが続く場合：スナップショットから復旧する
  3. 復旧後は必ず priv_validator_state.json を復元する

​
アップグレード後にセントリーノードが停止したまま

症状： バリデーターノードはアップグレード済みで署名しているが、セントリーノードは古いブロック高で停止したままになっている。 原因： セントリーノードも、アップグレード高を超えてブロックを処理するために新しいバイナリを必要とします。 解決策： セントリーノードをバリデーターと同じバージョンのバイナリにアップグレードしてください。セントリーは priv_validator_state.json を持ちません（署名を行わないため）が、正しいバイナリは必要です。

​
アップグレード後にチェーンが停滞する（投票パワー不足）

症状：
  • アップグレード高の後、チェーンが新しいブロックを生成しない
  • コンセンサスのラウンド番号が継続的に増加する（ラウンド50、100、200以上）
  • ノードはprevoteとprecommitをログに記録しているが、ブロックはコミットされない
  • latest_block_height が停止高で止まったまま
原因： CometBFTがブロックをファイナライズするには、合計投票パワーの2/3超が正しいバイナリでオンラインになり、参加している必要があります。協調アップグレードの間、バリデーターがそれぞれ異なる速度でアップグレードを行う時間帯が発生します。十分な投票パワーが新しいバイナリを実行するまで、ネットワークはコンセンサスに到達できません。 この時間帯に起きること：
  1. チェーンがアップグレード高で停止する（例：ブロック125）
  2. アップグレード済みのバリデーターがブロック高126でコンセンサスへの参加を開始する
  3. 各ラウンドでネットワークはブロック126のファイナライズを試みるが、投票パワーの2/3未満しか投票していないため失敗する
  4. ラウンド番号が増加し、サイクルが繰り返される。ラウンド1、2、3、…50、…100以上
  5. 十分な数のバリデーターがアップグレードを完了してオンラインになるまで、これが続く
これはアップグレード中の正常な動作です。 チェーンが壊れているのではなく、クォーラム（定足数）を待っている状態です。 取るべき対応：
  • すでにアップグレード済みの場合： 対応は不要です。あなたのノードは参加しており、クォーラムに達すると自動的に次のブロックをファイナライズします。ノードがラウンドを追いかける間、ログにラウンド後退エラーが表示されますが、これは想定内です（キャッチアップ中のラウンド後退エラーを参照）。
  • まだアップグレードしていない場合： あなたは不足している投票パワーの一部です。チェーンの再開を助けるため、できるだけ早くアップグレードを完了してください。
  • 進捗を監視する： オンラインで参加しているバリデーターの数を確認する：
  • バリデーターチャンネルで連携する： 大規模なアップグレードの際、バリデーターは通常、認証済みバリデーターチャンネルで連携し、アップグレードの進捗と投票パワーの割合を追跡します。
この時間帯が長引くほど、ラウンド番号は高くなります。後からオンラインになるバリデーターは、それらすべてのラウンドを追いかける必要があります。--unsafe-consensus-timeout-precommit-delta=1ms フラグが存在するのはこのためですが、チェーンが安定したら削除することを忘れないでください。

​
ダウンタイムによるジェイル（トゥームストーンではない）

症状：
  • バリデーターが非アクティブまたはジェイル状態と表示される
  • 署名情報で tombstoned: false になっている
  • ブロックミスのカウンターが高い
原因： バリデーターが連続して多くのブロックをミスしました（通常、直近10,000ブロック中500ブロック）。 解決策：
  1. ノードが稼働しており、最新のブロックまで完全に追いついていることを確認する
  2. unjailを実行する：
  3. バリデーターが再びアクティブになったことを確認する：

​
協調アップグレードチェックリスト

​
アップグレード高の前

  • ガバナンスプロポーザルまたはチェーンチームから、目標のhalt-heightを確認する
  • 新しいバイナリをダウンロードして検証する（sha256チェックサムを確認）
  • ノード設定またはCLIフラグで --halt-height=<target_height> を設定する
  • Cosmovisorを使用している場合：正しいアップグレードディレクトリに新しいバイナリを配置する
  • priv_validator_state.json をバックアップする
  • ロールバックが必要になった場合に備えて、スナップショットプロバイダーを把握しておく
  • チェーンが停止高に向かって進行するのを監視する

​
アップグレード高の時点

  • ノードが想定した高さで停止したことを確認する
  • ノードを完全に停止する（プロセスが終了していることを確認する）
  • priv_validator_state.json をバックアップする
  • 新しいバイナリをインストールする
  • バージョンを確認する：

​
アップグレード後

  • 新しいバイナリでノードを起動する
  • コンセンサスへの参加状況をログで監視する
  • prevoteが正しいことを確認する（すべてのラウンドでnilに投票していないこと）
  • エクスプローラー（Mintscan）で投票パワーを監視する
  • wrong Block.Header.LastResultsHash が表示された場合：停止し、1ブロックロールバックし、priv_validator_state.json を復元して再起動する
  • ラウンドキャッチアップの上書き設定（--unsafe-consensus-timeout-precommit-delta）を使用している場合：安定したら削除する
  • バリデーターが署名していることを確認する：

​
モニタリングリファレンス

​
コンセンサスと同期のステータス

​
バリデーターの健全性

​
ノード設定

​
プルーニングされたノードとアーカイブノードの比較

​
その他のリソース

​
スナップショットリソース

​
Injective提供のスナップショット

Injectiveは、2つのリージョンでプルーニングされたメインネットスナップショットを維持しています。最新の利用可能なブロック高とダウンロードURLについては、ステータスエンドポイントを確認してください： 最新のスナップショットをダウンロードするには、ステータスエンドポイントで現在のファイル名を確認してください：
協調セキュリティアップグレードの際、Injectiveチームが認証済みバリデーターチャンネルで緊急スナップショットを共有することもあります。アーカイブセグメントのスナップショットについては、アーカイブセットアップページを参照してください。

​
コミュニティのスナップショットプロバイダー

データベースバックエンドの互換性： スナップショットはバックエンド固有です。goleveldbのスナップショットはpebbledb向けに設定されたノードでは動作せず、その逆も同様です。ダウンロードする前に設定を確認してください：
スナップショット復旧の後、ノードを起動する前に、バックアップしておいた priv_validator_state.json をデータディレクトリに必ず復元してください。 完全な手順については、上記のスナップショットからの復旧を参照してください。
最終更新日 2026年9月1日