ข้ามไปที่เนื้อหาหลัก

Tokyo Hardfork（Japan Open Chain v2）

Japan Open Chain は、ネットワークのアップグレード「Tokyo Hardfork」を実施します。 本ハードフォークにより、コンセンサス方式が従来の Clique PoA から PoSA（Proof of Staked Authority / PoA v2）へ移行します。

スケジュール​

ネットワーク実施日ステータス
Testnet2026年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.yamlConsensus Client 用のチェーン仕様fork epoch、network ID を定義
deposit_contract_block.txtDeposit Contract のブロック番号
genesis.sszビーコンチェーンの genesis state約 5.5 MB
หมายเหตุ

設定ファイルの配布先 URL は確定次第、本ページでご案内します。

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 ClientConsensus Client
Phase 2　ShapellashanghaiTime を設定CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH
Phase 3　DencuncancunTime を設定DENEB_FORK_VERSION / DENEB_FORK_EPOCH
Phase 4　PectrapragueTime を設定ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH
warning

当社のアナウンス前に、自己判断で設定の更新や再起動を行わないでください。

3. 対応いただけなかった場合​

  • ハードフォーク後、当該ノードは新しいブロックを受信できなくなり、チェーンの先端に追随できなくなります
  • そのノードへ RPC 接続しているアプリケーションやウォレットは、最新のブロック情報やトランザクションを取得できなくなります
  • 旧チェーン上に取り残されたノードは、廃止されたチェーンのデータを返し続ける可能性があります
  • なお、一般のノードがスラッシュされることはありません（スラッシュの対象はバリデータのみです）

4. よくあるご質問​

Q. バリデータになるための登録や、32 JOC のデポジットは必要ですか。

不要です。ブロックを生成しない通常のノードには、Launchpad での登録も deposit data の提出も必要ありません。必要なのは上記の構成変更のみです。

Q. 既存のチェーンデータを消して同期し直す必要はありますか。

いいえ。既存のチェーンデータおよびトランザクション履歴はすべて維持されます。

Q. Chain ID は変わりますか。

変わりません。

Q. サーバーの追加は必要ですか。

Consensus Client は既存ホスト上で稼働させられます。ただしディスクとメモリに余裕が必要です。

お問い合わせ​

本ハードフォークに関するお問い合わせはお問い合わせフォームよりご連絡ください。