Skip to main content

Tokyo Hardfork（Japan Open Chain v2）

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

スケジュール​

ネットワーク実施日ステータス
Testnet2026年9月7日完了
Mainnet（ビーコンチェーン稼働開始）2026年9月18日完了
Mainnet（Phase 1／The Merge）2026年11月27日 正午前後（予定）
TTD 47,370,500 到達時に自動実行		準備中
ノードを運用されている方へ

Testnet でノードを運用されている事業者様は、2026年9月7日より前にノード構成の変更を完了してください。 Geth のバージョンを上げるだけでは不十分です。詳細はこちらをご確認ください。

Mainnet ビーコンチェーンについて​

Mainnet のアップグレードは、次の2段階で進みます。

  1. ビーコンチェーンの稼働開始（2026年9月18日・完了）
    コンセンサスレイヤーが Execution Layer とは別に先行して稼働を開始しました。ブロックの生成は引き続き Clique PoA が担っているため、現時点で一般ユーザーやノード運用者への影響はありません。
  2. Phase 1　ハードフォーク（The Merge）（2026年11月27日 正午前後・予定）
    Execution Layer がビーコンチェーンからの指示で動作するようになります。ノードを運用されている事業者様はこのタイミングで構成変更が必要です。The Merge は時刻ではなく、総難易度（Total Difficulty）が 47,370,500（TTD）に到達した時点で自動的に実行されるため、正確な時刻は事前に確定しません。最新の予測時刻はカウントダウンページでリアルタイムにご確認いただけます。

Mainnet 用の設定ファイル（config.yaml / genesis.ssz / deposit contract 情報 / bootnode・boot ENR 一覧）は、japan-open-chain/mainnet リポジトリの metadata/ ディレクトリで公開されています。ノード構築の具体的な手順は Mainnet ノード接続ガイドをご参照ください。

この段階で必要な対応​

対象必要な対応
JOC 保有者・一般ユーザー、RPC エンドポイント利用者対応不要です
Mainnet で自前ノードを運用している事業者現状の Execution Client（Geth）のみの構成のままで問題ありませんが、次のハードフォーク（The Merge）に備えて、Mainnet ノード接続ガイドの手順に従って今のうちに Consensus Client（推奨：Lighthouse）を構築しておくことを推奨します
Mainnet でノードを運用されている方へ

ハードフォーク実施前は、Geth v1.14.0 以降ではチェーンに同期できません。引き続き v1.13 系をご利用ください。

対象者別の対応​

対象必要な対応
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

上記のファイルは、テストネット用リポジトリの metadata/ ディレクトリで配布しています。

Step 2　Geth は v1.13 系を使用する​

当サイトで動作確認済みの Geth v1.13.5 を引き続きご利用ください。Geth v1.14.0 以降は、現時点ではチェーンを同期できません。

注記

Shapella / Dencun / Pectra の各フェーズでは、より新しいバージョンの Geth が必要になります。対応バージョンは、実施時期が確定し次第本ページでご案内します。

Step 3　Consensus Client を新規に構築する​

  • 推奨：Lighthouse v7.0.1（Docker イメージ sigp/lighthouse:v7.0.1）
  • Lighthouse は当社で安定して動作することを確認しています。その他のクライアントは動作未確認です
  • 既存の 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
警告

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

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

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

4. よくあるご質問​

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

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

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

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

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

変わりません。

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

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

お問い合わせ​

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