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 — Geth와 Consensus Client를 Engine API로 연결
두 클라이언트는 인증이 적용된 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 업데이트가 기록되어 있는지 확인
- 하드포크 당일에는 두 클라이언트를 실행 상태로 유지해 주십시오. 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. 조치하지 않은 경우
- 하드포크 이후 해당 노드는 새로운 블록을 수신할 수 없게 되어 체인의 최신 블록(head)을 따라갈 수 없게 됩니다
- 해당 노드에 RPC로 연결된 애플리케이션이나 지갑은 최신 블록 정보나 트랜잭션을 가져올 수 없게 됩니다
- 구 체인에 남겨진 노드는 폐지된 체인의 데이터를 계속 반환할 수 있습니다
- 참고로 일반 노드가 slash되는 일은 없습니다(Slashing 대상은 Validator뿐입니다)
4. 자주 묻는 질문
Q. Validator가 되기 위한 등록이나 32 JOC의 디포짓이 필요합니까?
필요하지 않습니다. 블록을 생성하지 않는 일반 노드는 Launchpad에서의 등록도 deposit data 제출도 필요하지 않습니다. 필요한 것은 위에서 설명한 구성 변경뿐입니다.
Q. 기존 체인 데이터를 삭제하고 다시 동기화해야 합니까?
아니요. 기존 체인 데이터 및 트랜잭션 이력은 모두 유지됩니다.
Q. Chain ID가 변경됩니까?
변경되지 않습니다.
Q. 서버를 추가해야 합니까?
Consensus Client는 기존 호스트에서 실행할 수 있습니다. 다만 디스크와 메모리에 여유가 있어야 합니다.
문의
본 하드포크에 관한 문의는 문의 양식을 통해 연락해 주십시오.