> ## Documentation Index
> Fetch the complete documentation index at: https://injectivelabs-mintlify-6abb8c3a.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# v1.20.4-bl.2 への緊急アップグレード

> Injectiveメインネットのバリデーター、取引所、ノードオペレーター向けのアップグレードおよびAppHash復旧手順です。

> [!WARNING]
>
> **この緊急アップグレードが実施された理由**
>
> Injectiveとは無関係の取引所であるBitGetが侵害を報告し、資金回収への協力を要請しました。その資金の一部は、他の主要チェーンとともにInjective上でもやり取りされた可能性があります。このパッチは、攻撃者が **BitGetの影響を受けた資金** を移動できないようにするため、オンチェーンのブロックリストを導入しました。これは **BitGetの資金回収を支援し、より広いエコシステムをサポートするための一度限りの緊急措置** です。封じ込めが完了する前に攻撃者に察知されることを避けるため、初期の配布と調整はバリデーターを中心に行われ、公開のコミュニケーションは限定されました。
>
> 取引所やその他のノードオペレーターに対して、アップグレードが必要であることについての十分な事前通知や明確な手順が届かなかったことを認識しています。これにより生じた混乱について、お詫び申し上げます。この例外的な対応は、通常の協調アップグレードプロセスに代わるものではありません。
>
> 10月7日、ブロック対象アドレスに関わるトランザクションにより、パッチ適用済みノードと未適用ノードの差異が表面化しました。ネットワークがブロック生成を続ける一方で、パッチ未適用のノードではAppHashの不一致が発生しました。**セントリー、RPCノード、取引所インフラを含む、すべてのメインネットノードでパッチを実行する必要があります。**

## 概要

`v1.20.4-bl.2` は、**Injectiveメインネット（`injective-1`）** 向けの `v1.20.4` リリースライン上の緊急パッチです。コンセンサスのブロックリストはブロック **184,950,000** で有効化されており、このブロックはすでに通過しています。今すぐアップグレードしてください。このパッチには、予定されたチェーン停止、ガバナンスのアップグレードハンドラー、state移行はありません。停止を待ったり、新たに `--halt-height` を設定したりしないでください。

| ノードの状態 | 必要な対応 |
| - | - |
| パッチ未適用のバイナリを実行しており、10月7日のAppHash不一致で停止した | ノードを停止し、stateをバックアップし、**既存のバイナリを使用して** 1ブロックロールバックしてから、パッチをインストールして再起動します。 |
| パッチ未適用のバイナリを実行しているが、不一致は発生していない | ノードを停止し、stateをバックアップし、パッチをインストールして再起動します。ロールバックは不要です。 |
| すでに `v1.20.4-bl.2` を実行しており、正常に同期している | ロールバックや再インストールは不要です。運用しているすべてのセントリー、RPC、その他のノードにもパッチが適用されていることを確認してください。 |

これは、バリデーター、セントリー、フルノード、パブリックおよびプライベートのRPC/ブロードキャストノード、取引所・エクスプローラー・その他のインテグレーションにサービスを提供するノードに適用されます。

## 1. リリースの選択と検証

バイナリアーカイブまたはDockerイメージのいずれかを選択してください。**Dockerオペレーターはアーカイブのダウンロードを省略し、イメージを直接使用できます。**

### オプションA：バイナリアーカイブ

[公式リリースマニフェスト](https://storage.googleapis.com/injective-chain-releases/status.json)に、ホストされているバイナリが記載されています。お使いのプラットフォーム用のアーカイブをダウンロードしてください：

| プラットフォーム | ダウンロード |
| - | - |
| Linux AMD64 | [injective-v1.20.4-bl.2-linux-amd64.zip](https://storage.googleapis.com/injective-chain-releases/v1.20.4-bl.2/injective-v1.20.4-bl.2-linux-amd64.zip) |
| macOS Apple Silicon | [injective-v1.20.4-bl.2-darwin-arm64.zip](https://storage.googleapis.com/injective-chain-releases/v1.20.4-bl.2/injective-v1.20.4-bl.2-darwin-arm64.zip) |
| SHA-256チェックサム | [SHA256SUMS.zip.txt](https://storage.googleapis.com/injective-chain-releases/v1.20.4-bl.2/SHA256SUMS.zip.txt) |

Linux AMD64の場合は、実行中のバイナリを置き換えずに、ステージング用ディレクトリにダウンロードします：

```bash theme={null}
mkdir -p ~/injective-v1.20.4-bl.2
cd ~/injective-v1.20.4-bl.2
curl -fLO https://storage.googleapis.com/injective-chain-releases/v1.20.4-bl.2/injective-v1.20.4-bl.2-linux-amd64.zip
echo '81f49009d1652fe8688bf6662c6d4d42ad65d7039207fd77ec2a161050973df2  injective-v1.20.4-bl.2-linux-amd64.zip' | sha256sum -c -
```

チェックサムが `OK` と表示された場合のみ続行してください。その後、アーカイブを展開します：

```bash theme={null}
unzip injective-v1.20.4-bl.2-linux-amd64.zip
```

macOSの場合は `shasum -a 256` を使用し、アーカイブをチェックサムファイル内の対応するエントリと照合してください。

### オプションB：Dockerイメージ

初回リリースでは、パッチは以下のDockerイメージとして配布されました：

```text theme={null}
injectivelabs/injective-core:v1.20.4-bl.2
```

ノードのデータをマウントせずに、イメージをプルしてバイナリを検証します：

```bash theme={null}
docker pull injectivelabs/injective-core:v1.20.4-bl.2
docker run --rm injectivelabs/injective-core:v1.20.4-bl.2 injectived version
```

初回リリースでは、AMD64について以下の出力が記録されています：

```text theme={null}
Version v1.20.4-bl.2 (1ffa252)
Compiled at 20260928-0409 using Go go1.26.8 (amd64)
```

既存のコンテナデプロイメントを使用して、以下の停止、バックアップ、復旧、再起動の手順を進めてください。古いイメージは残しておいてください。影響を受けたノードは、パッチに切り替える前にそのイメージでロールバックを完了する必要があります。Dockerイメージにはランタイムライブラリが含まれているため、コンテナオペレーターはアーカイブの `libwasmvm` をホストにインストールする必要はありません。

## 2. ノードの停止とstateのバックアップ

既存のサービスマネージャーまたはコンテナデプロイメントを通じてノードを停止します。復旧中に自動的に再起動しないよう、スーパーバイザーも停止してください。ノードのデータディレクトリにアクセスしている `injectived` プロセスがないことを確認してください。

続行する前に、ノードの設定、鍵、データをバックアップしてください。必要なロールバックが完了するまで、既存のバイナリは残しておいてください。以下のコマンドはデフォルトのホームディレクトリ `~/.injectived` を前提としています。異なる場合は、設定済みの `--home` パスを使用してください。

**Docker Composeの例：** 通常のデプロイメントと同じComposeファイルと環境を使用し、既存のComposeプロジェクトからコマンドを実行します。`node_service` を実際のサービス名に、`container_node_home` を **コンテナ内の** 既存のホームパスに設定してください。以下の値は例です。このホームが既存のバインドマウントまたは名前付きボリュームに保存されていることを確認してから、サービスを停止します：

```bash theme={null}
node_service=injectived
container_node_home=/root/.injectived
docker compose stop "$node_service"
```

シャットダウン後、マウントされたノードホームをバックアップします。以降のComposeコマンドのために、これらの変数は設定したままにしておいてください。プレーンなDockerや他のオーケストレーターを使用している場合は、そのデプロイメントを通じて既存のノードコンテナを停止し、マウントと設定を保持してください。

> [!WARNING]
>
> **バリデーター：** ノードが完全に停止した後、`~/.injectived/data/priv_validator_state.json` をデータディレクトリの外に別途バックアップしてください。ロールバックやスナップショット復旧の間もこの署名stateをそのまま保持し、再起動前に復元してください。リモート署名者（remote signer）を使用している場合は、既存の署名者の手順に従って署名stateを保持してください。署名stateをリセットしたり、同じバリデーター鍵で2つのインスタンスを実行したりしないでください。

## 3. 影響を受けたノードの復旧（必要な場合）

この手順は、ノードで10月7日のAppHash不一致が発生した場合にのみ実行してください。報告されたエラーの例：

```text theme={null}
panic: Precommit step; +2/3 prevoted for an invalid block: wrong Block.Header.AppHash.
```

アーカイブノードや大規模なデータベースを持つノードの場合は、ロールバックを試みる前にサポートに連絡して復旧方法を確認してください。適切なスナップショットを復元するほうが望ましい場合があります。

ノードを停止した状態で、パッチをインストールする前に、**不一致が発生したときに実行していたものと同じバージョンのバイナリを使用して** 次のコマンドを実行します：

```bash theme={null}
injectived rollback --hard -n 1 --home ~/.injectived
```

この1ブロックのロールバックとその後のバイナリアップグレードは、インシデント中にテスト済みです。シェルの `PATH` 上にある別の `injectived` ではなく、サービス設定で使用されている実際の実行ファイルを使用してください。

* **Cosmovisor：** 既存の `$DAEMON_HOME/cosmovisor/current/bin/injectived` を使用し、`--home` をそのノードのホームディレクトリに指定してロールバックを実行します。
* **コンテナ：** **古いイメージ** と、同じデータボリューム、ノードホーム、ユーザー権限を使用して、ロールバックを単発のコマンドとして実行します。通常のノードコンテナは停止したままにしてください。

Docker Composeの場合は、ロールバックが成功するまで、サービスの `image` を影響を受けたノードで使用していた古いイメージそのままにしておいてください。バックアップの完了後、上記のホスト用ロールバックコマンドの **代わりに** 以下を実行します：

```bash theme={null}
docker compose run --rm --no-deps --pull never --entrypoint injectived \
  "$node_service" rollback --hard -n 1 --home "$container_node_home"
```

これにより、サービスに設定されたマウント、環境、ユーザーが再利用されます。この例では、`injectived` がイメージ内で直接利用可能であることを前提としています。デプロイメントでカスタムラッパーを使用している場合は、必要な初期化処理を維持してください。

バイナリを置き換える前に、ロールバックが正常に完了するまで待ってください。インシデント時の復旧手順では、所要時間はおよそ10秒〜1分と見積もられていますが、大規模なデータベースやアーカイブデータベースでは大幅に長くかかる場合があります。コマンドが失敗した場合や不一致が解消されない場合に、追加のブロックを繰り返しロールバックしないでください。ノードを停止したままにし、バージョン、ブロック高、ログを添えてサポートに連絡してください。

ロールバックが利用できない場合や失敗した場合は、[Chain Portal](https://chain.injective.network/snapshots)またはInjectiveのサポート窓口から適切なスナップショットを入手してください。ブロック **186,223,485** より前のスナップショットであれば、パッチ適用済みのバイナリでリプレイできます。バリデーターの署名stateを保持し、[スナップショット復旧の手順](/jp/infra/coordinated-upgrades#スナップショットからの復旧)に従ってください。

## 4. パッチのインストール

必要なロールバックが完了したら：

* **バイナリデプロイメント：** サービスが使用している `injectived` 実行ファイルを、検証済みアーカイブに含まれるものに置き換えます。同梱の `libwasmvm` ライブラリをデプロイメントで使用しているライブラリの場所にインストールし、サービスの所有者と権限を維持してください。
* **Cosmovisor：** `$DAEMON_HOME/cosmovisor/current/bin` 内の `injectived` を置き換え、同梱のライブラリをサービスが読み込む場所に配置します。このパッチにはアップグレードハンドラーがないため、新しい `upgrades` ディレクトリに配置しても自動的には有効になりません。
* **コンテナ：** データボリューム、設定、ユーザー、起動フラグを維持したまま、既存のデプロイメントを `injectivelabs/injective-core:v1.20.4-bl.2` に更新します。

Docker Composeの場合は、ノードサービスの `image` の値（またはそれを指定する環境変数）のみを `injectivelabs/injective-core:v1.20.4-bl.2` に変更します。ノードを停止したまま、設定したイメージをプルして検証します：

```bash theme={null}
docker compose pull "$node_service"
docker compose run --rm --no-deps --entrypoint injectived "$node_service" version
```

起動する前に、サービスが使用する実行ファイルまたはイメージそのものに対して `version` を実行し、以下を確認してください：

```text theme={null}
Version v1.20.4-bl.2 (1ffa252)
```

### オプション：ローカルmempoolブロックリスト

コンセンサスのブロックリストはパッチ適用済みのバイナリに組み込まれており、設定は不要です。以下の `app.toml` のエントリは、ローカルでのトランザクション受け入れフィルタリングを追加するもので、**任意** です。バイナリのアップグレードの代わりにはなりません。

有効にする場合は、`~/.injectived/config/app.toml` の **トップレベル**、つまり `[api]` などのTOMLセクションヘッダーより前に、このエントリを追加してください：

```toml theme={null}
mempool-blocked-signers = ["inj134wrp6mctpq4czhw6rghekt3js3ac7c4s8ya3d"]
```

キーがすでに存在する場合は、キーを重複させたり、設定済みの他のアドレスを削除したりせずに更新してください。無効なアドレスがあると、ノードは起動しません。

## 5. 再起動と検証

バリデーターは、再起動する前に、ノード停止後に取得した署名stateのバックアップを復元して検証する必要があります。既存のサービスマネージャーまたはコンテナデプロイメントを通じてノードを起動します。

Docker Composeの場合は、新しいイメージでサービスを再作成し、実行中のコンテナ内でバイナリを検証してログを確認します：

```bash theme={null}
docker compose up -d --no-deps "$node_service"
docker compose exec "$node_service" injectived version
docker compose logs --tail 100 "$node_service"
```

イメージの変更を適用するには `up` を使用してください。古いコンテナを再起動するだけでは、イメージは置き換わりません。プレーンなDockerや他のオーケストレーターの場合は、既存のマウント、ポート、環境、ユーザー、起動引数を使用して、停止したノードコンテナをパッチ適用済みのイメージから再作成してください。ノードのデータとバリデーター鍵を使用するインスタンスは1つだけにしてください。

ログで正常に起動したことを確認し、AppHashの不一致が表示されなくなったことを確認してください。ノードのローカルRPCエンドポイントに問い合わせます（必要に応じてアドレスを調整してください）：

```bash theme={null}
curl -fsS http://localhost:26657/status \
  | jq '.result | {network: .node_info.network, latest_block_height: .sync_info.latest_block_height, catching_up: .sync_info.catching_up}'
```

以下を確認してください：

* ネットワークが `injective-1` であること。
* 確認を繰り返すたびにブロック高が進み、ネットワークに追いつくこと。
* 同期が完了すると `catching_up` が `false` になること。
* バリデーターが署名を再開し、取引所/RPCオペレーターは下流のサービスが最新のブロックを受信していることを確認すること。

バリデーションに参加しないセントリーやRPCノードを含め、運用しているすべてのノードでアップグレードを繰り返してください。

## サポート

復旧に失敗した場合は、ノードを停止したままにし、バイナリのバージョン、最後に処理したブロック高、データベースバックエンド、関連するエラーログを、既存のInjective調整窓口または[Discord](https://discord.gg/injective)のチームに共有してください。秘密鍵や署名者の認証情報は共有しないでください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.