Tokyo Hardfork（Japan Open Chain v2）
Japan Open Chain は、ネットワークのアップグレード「Tokyo Hardfork」を実施します。 本ハードフォークにより、コンセンサス方式が従来の Clique PoA から PoSA（Proof of Staked Authority / PoA v2）へ移行します。
スケジュール
| ネットワーク | 実施日 | ステータス |
|---|---|---|
| Testnet | 2026年9月7日 | 実施予定 |
| Mainnet | 未定（Testnet の結果を踏まえて決定） | 準備中 |
Testnet でノードを運用されている事業者様は、2026年9月7日より前にノード構成の変更を完了してください。 Geth のバージョンを上げるだけでは不十分です。詳細はこちらをご確認ください。
対象者別の対応
| 対象 | 必要な対応 |
|---|---|
| JOC 保有者・一般ユーザー | 対応不要です |
| JOC の RPC エンドポイント利用者 | 対応不要です |
| dApp 開発者 | Chain ID は変更されません。自前でノードを運用している場合のみ下記の対応が必要です |
| 自前でノードを運用している事業者 | 要対応。 下記の手順に従ってノード構成を変更してください |
| バリデータ | 要対応。 別途ご案内する手順に従ってください |
テストネットでノードを運用されている方の対応手順
対象： JOC テストネットのブートノードから直接同期して、自前でノードを運用している事業者 ※ JOC の RPC エンドポイント経由でご利用の場合、対応は不要です
Geth のバージョンを上げるだけでは足りません
PoA では Execution Client（Geth）が単独でブロックの検証と同期を行っていました。 PoSA 移行後は、ブロックの正当性を決めるのは Consensus Layer （ビーコンチェーン）になります。 Geth は「実行」だけを担い、どのブロックが正しいかは Consensus Client から指示を受けて動く構造に変わります。
したがって、必要な作業はバージョンアップではなく構成変更です。
【現在】 【Tokyo ハードフォーク後】
Geth（単体） Geth ── Engine API ── Lighthouse
│ │ │
P2P で 実行のみ 合意形成・fork choice
ブートノードへ │
CL 用ブートノードへ
1. ハードフォーク実施前に完了させること
Step 1 設定ファイル一式を入手する
| ファイル | 用途 | 備考 |
|---|---|---|
genesis.json（更新版） | Execution Client 用。TTD および各フォーク時刻を含む | 現行公開版とは別物 |
config.yaml | Consensus Client 用のチェーン仕様 | fork epoch、network ID を定義 |
deposit_contract_block.txt | Deposit Contract のブロック番号 | |
genesis.ssz | ビーコンチェーンの genesis state | 約 5.5 MB |
上記のファイルは、テストネット用リポジトリの metadata/ ディレクトリで配布しています。
Step 2 Geth を v1.16.8 に更新する
現在サイトに記載のある「Geth ver1.13.5 まで動作検証済み」では、ハードフォーク後のチェーンに追随できません。
Step 3 Consensus Client を新規に構築する
- 推奨：Lighthouse v7.0.1（Docker イメージ
sigp/lighthouse:v7.0.1） - Prysm は、当社の内部検証において Shapella フェーズ以降で接続エラーおよび同期の問題が確認されているため、推奨しません
- 既存の Geth と同一ホストで問題ありません
- Consensus Layer 用のブートノード（ENR）の設定が必要です（確定次第ご案内します）
- 初回同期には checkpoint sync のご利用を推奨します（エンドポイントは確定次第ご案内します）
Step 4 Geth と Consensus Client を Engine API で接続する
両者は認証付きの Engine API（既定ポート 8551）で通信します。共有する JWT secret を生成し、双方に指定してください。
# JWT secret の生成例
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Geth 側に追加が必要な起動オプション：
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 同期と接続を確認する
- Consensus Client がビーコンチェーンに追いついていること
- Geth のログに Engine API 経由の fork choice 更新が記録されていること
- ハードフォーク当日は、両クライアントを起動したまま維持してください。The Merge は設定された TTD への到達時に自動的に発火 します
2. ハードフォーク後、各フェーズごとに必要な作業
Shapella・Dencun・Pectra の各フェーズでは、当社からのアナウンス後に設定を更新し、再起動していただく必要があります。
| フェーズ | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 Shapella | shanghaiTime を設定 | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 Dencun | cancunTime を設定 | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 Pectra | pragueTime を設定 | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
当社のアナウンス前に、自己判断で設定の更新や再起動を行わないでください。
3. 対応いただけなかった場合
- ハードフォーク後、当該ノードは新しいブロックを受信できなくなり、チェーンの先端に追随できなくなります
- そのノードへ RPC 接続しているアプリケーションやウォレットは、最新のブロック情報やトランザクションを取得できなくなります
- 旧チェーン上に取り残されたノードは、廃止されたチェーンのデータを返し続ける可能性があります
- なお、一般のノードがスラッシュされることはありません（スラッシュの対象はバリデータのみです）
4. よくあるご質問
Q. バリデータになるための登録や、32 JOC のデポジットは必要ですか。
不要です。ブロックを生成しない通常のノードには、Launchpad での登録も deposit data の提出も必要ありません。必要なのは上記の構成変更のみです。
Q. 既存のチェーンデータを消して同期し直す必要はありますか。
いいえ。既存のチェーンデータおよびトランザクション履歴はすべて維持されます。
Q. Chain ID は変わりますか。
変わりません。
Q. サーバーの追加は必要ですか。
Consensus Client は既存ホスト 上で稼働させられます。ただしディスクとメモリに余裕が必要です。
お問い合わせ
本ハードフォークに関するお問い合わせはお問い合わせフォームよりご連絡ください。