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（信标链启动） | 2026年9月18日 | 已完成 |
| Mainnet（Phase 1／The Merge） | 待定（将在 Validator 会议上决定） | 准备中 |
在 Testnet 上运营节点的机构，请务必在 2026年9月7日之前完成节点配置的变更。 仅升级 Geth 版本是不够的。详情请参阅下方的步骤。
关于 Mainnet 信标链
Mainnet 的升级将分以下两个阶段进行。
- 信标链启动（2026年9月18日，已完成）
Consensus Layer（共识层）已先于 Execution Layer（执行层）开始独立运行。由于区块仍由 Clique PoA 生成，目前对一般用户和节点运营者没有任何影响。 - Phase 1 — 硬分叉（The Merge）（待定）
Execution Layer 将开始依照信标链的指示运行。运营自有节点的机构需要在此时变更配置。实施日期在 Validator 会议上确定后，将在本页面公布。
Mainnet 的配置文件（config.yaml、genesis.ssz、Deposit Contract 信息以及 bootnode / boot ENR 列表）已在 japan-open-chain/mainnet 仓库的 metadata/ 目录中公开。节点搭建的具体步骤请参阅 Mainnet 节点连接指南。
当前阶段需要采取的措施
| 对象 | 所需措施 |
|---|---|
| JOC 持有者、一般用户及 JOC RPC Endpoint 用户 | 无需采取任何措施 |
| 在 Mainnet 上运营自有节点的机构 | 保持当前仅使用 Execution Client（Geth）的配置即可，但为了应对下一次硬分叉（The Merge），建议现在就按照 Mainnet 节点连接指南的步骤搭建 Consensus Client（推荐：Lighthouse） |
在硬分叉实施之前，Geth v1.14.0 及以上版本无法同步链数据。请继续使用 v1.13 系列版本。
各类对象需要采取的措施
| 对象 | 所需措施 |
|---|---|
| JOC 持有者及一般用户 | 无需采取任何措施 |
| JOC RPC Endpoint 用户 | 无需采取任何措施 |
| dApp 开发者 | Chain ID 不会变更。仅在自行运营节点的情况下需要采取措施 |
| 运营自有节点的机构 | 需要采取措施（硬分叉时）。 请按照以下步骤变更节点配置 |
| Validator | 需要采取措施。 请按照另行提供的说明操作 |
Testnet 节点运营者的操作步骤
适用对象： 直接从 JOC Testnet 引导节点同步并自行运营节点的机构。 如果您通过 JOC RPC Endpoint 使用服务，则无需采取任何措施。
仅升级 Geth 版本是不够的
在 PoA 下，Execution Client（Geth）独立完成区块的验证与同步。 迁移至 PoSA 后，区块的有效性将由 Consensus Layer（信标链）决定。 Geth 仅负责“执行”，并根据 Consensus Client 的 fork choice 指示运行。
因此，所需的工作并非版本升级，而是配置变更。
[当前] [Tokyo Hardfork 之后]
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 |
上述文件在 Testnet 仓库的 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 — 通过 Engine API 连接 Geth 与 Consensus Client
两者通过带认证的 Engine API（默认端口 8551）进行通信。请生成共享的 JWT secret，并在双方进行配置。
# Example: generating the 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 更新
- 硬分叉当天请保持两个客户端持续运行。达到所设定的 TTD 时，The Merge 将自动触发
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 连接到该节点的应用程序和钱包将无法获取最新的区块信息和交易
- 滞留在旧链上的节点可能会持续返回已废弃链的数据
- 请注意，普通节点不会被 Slashing（Slashing 的对象仅限于 Validator）
4. 常见问题
Q. 是否需要注册成为 Validator 或存入 32 JOC？
不需要。不生成区块的普通节点既无需在 Launchpad 上注册，也无需提交 deposit data。只需完成上述配置变更即可。
Q. 是否需要删除现有链数据并重新同步？
不需要。现有的链数据和交易历史将全部保留。
Q. Chain ID 会变更吗？
不会。
Q. 是否需要增加服务器？
Consensus Client 可以在现有主机上运行，但需要确保磁盘和内存有足够的余量。
联系我们
如对本次硬分叉有任何疑问，请通过联系表单与我们联系。