Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain effettuerà un aggiornamento della rete denominato Tokyo Hardfork. Con questo hardfork, il meccanismo di consenso passa da Clique PoA a PoSA (Proof of Staked Authority / PoA v2).
Calendario
| Rete | Data | Stato |
|---|---|---|
| Testnet | 7 settembre 2026 | Completato |
| Mainnet (avvio della beacon chain) | 18 settembre 2026 | Completato |
| Mainnet (Phase 1 / The Merge) | Da definire (sarà deciso nella riunione dei validatori) | In preparazione |
Se gestisce un nodo sulla Testnet, La preghiamo di completare la modifica della configurazione prima del 7 settembre 2026. Il solo aggiornamento di Geth non è sufficiente. Per i dettagli, consulti i passaggi riportati di seguito.
Informazioni sulla beacon chain della Mainnet
L'aggiornamento della Mainnet si svolge in due fasi.
- Avvio della beacon chain (18 settembre 2026 — completato)
La Consensus Layer ha iniziato a funzionare prima della Execution Layer. I blocchi continuano a essere prodotti da Clique PoA, pertanto al momento non vi è alcun impatto per gli utenti in generale né per gli operatori di nodi. - Phase 1 — Hardfork (The Merge) (da definire)
La Execution Layer inizierà a operare secondo le istruzioni della beacon chain. Le organizzazioni che gestiscono un proprio nodo dovranno modificare la configurazione in quel momento. La data sarà comunicata su questa pagina non appena verrà decisa nella riunione dei validatori.
I file di configurazione della Mainnet (config.yaml, genesis.ssz, le informazioni sul deposit contract e gli elenchi di bootnode / boot ENR) sono pubblicati nella directory metadata/ del repository japan-open-chain/mainnet. Per i passaggi dettagliati di configurazione del nodo, consulti la guida alla connessione dei nodi alla Mainnet.
Cosa fare in questa fase
| Destinatari | Azione richiesta |
|---|---|
| Detentori di JOC, utenti in generale e utenti dei RPC Endpoint di JOC | Nessuna azione richiesta |
| Organizzazioni che gestiscono un proprio nodo sulla Mainnet | È possibile mantenere l'attuale configurazione con il solo Execution Client (Geth), ma raccomandiamo di configurare fin da ora un Consensus Client (consigliato: Lighthouse), in vista del prossimo hardfork (The Merge), seguendo la guida alla connessione dei nodi alla Mainnet |
Prima dell'hardfork, Geth v1.14.0 o versioni successive non sono in grado di sincronizzare la catena. La preghiamo di continuare a utilizzare la serie v1.13.
Cosa fare
| Destinatari | Azione richiesta |
|---|---|
| Detentori di JOC e utenti in generale | Nessuna azione richiesta |
| Utenti dei RPC Endpoint di JOC | Nessuna azione richiesta |
| Sviluppatori di dApp | Il Chain ID non cambia. È richiesta un'azione solo se si gestisce un proprio nodo |
| Organizzazioni che gestiscono un proprio nodo | Azione richiesta al momento dell'hardfork. Seguire i passaggi riportati di seguito per modificare la configurazione del nodo |
| Validatori | Azione richiesta. Verranno fornite istruzioni separate |
Passaggi per gli operatori di nodi sulla Testnet
A chi si applica: organizzazioni che si sincronizzano direttamente dai boot node della Testnet di JOC e gestiscono un proprio nodo. Se utilizza i RPC Endpoint di JOC, non è richiesta alcuna azione.
Il solo aggiornamento di Geth non è sufficiente
Con PoA, l'Execution Client (Geth) verificava e sincronizzava i blocchi in modo autonomo. Dopo la migrazione a PoSA, la validità dei blocchi è determinata dalla Consensus Layer (la beacon chain). Geth si occupa esclusivamente dell'esecuzione e riceve le istruzioni di fork choice dal Consensus Client.
Il lavoro necessario è quindi una modifica della configurazione, non un aggiornamento di versione.
[Attuale] [Dopo il Tokyo Hardfork]
Geth (autonomo) Geth ── Engine API ── Lighthouse
│ │ │
P2P verso i solo esecuzione consenso / fork choice
boot node │
verso i boot node CL
1. Operazioni da completare prima dell'hardfork
Step 1 — Ottenere i file di configurazione
| File | Scopo | Note |
|---|---|---|
genesis.json (aggiornato) | Per l'Execution Client. Contiene il TTD e l'orario di ciascun fork | Diverso dalla versione attualmente pubblicata |
config.yaml | Specifica della catena per il Consensus Client | Definisce i fork epoch e il network ID |
deposit_contract_block.txt | Numero di blocco del Deposit Contract | |
genesis.ssz | Stato genesis della beacon chain | Circa 5,5 MB |
Questi file sono distribuiti nella directory metadata/ del repository della Testnet.
Step 2 — Mantenere Geth sulla serie v1.13
Continui a utilizzare Geth v1.13.5, la versione verificata su questo sito. Attualmente Geth v1.14.0 e le versioni successive non sono in grado di sincronizzare la catena.
Per le fasi Shapella, Dencun e Pectra sarà necessaria una versione più recente di Geth. Comunicheremo la versione supportata su questa pagina non appena il calendario sarà confermato.
Step 3 — Configurare un Consensus Client
- Consigliato: Lighthouse v7.0.1 (immagine Docker
sigp/lighthouse:v7.0.1) - Lighthouse è stato testato e funziona in modo stabile; gli altri client non sono stati verificati
- Può essere eseguito sullo stesso host del Geth esistente
- È necessario configurare i boot node (ENR) della Consensus Layer (saranno comunicati non appena confermati)
- Raccomandiamo di utilizzare il checkpoint sync per la sincronizzazione iniziale (l'endpoint sarà comunicato non appena confermato)
Step 4 — Collegare Geth e il Consensus Client tramite la Engine API
I due comunicano tramite la Engine API autenticata (porta predefinita 8551). Generi un segreto JWT condiviso e lo configuri su entrambi i lati.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Opzioni di avvio da aggiungere lato Geth:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Verificare la sincronizzazione e la connettività
- Il Consensus Client si è allineato con la beacon chain
- Il log di Geth registra gli aggiornamenti di fork choice tramite la Engine API
- Mantenga entrambi i client in esecuzione il giorno dell'hardfork. The Merge si attiva automaticamente al raggiungimento del TTD configurato
2. Operazioni richieste in ciascuna fase dopo l'hardfork
Per le fasi Shapella, Dencun e Pectra, sarà necessario aggiornare la configurazione e riavviare dopo la nostra comunicazione.
| Fase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | Impostare shanghaiTime | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | Impostare cancunTime | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | Impostare pragueTime | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Non aggiorni la configurazione né riavvii di Sua iniziativa prima della nostra comunicazione.
3. Se non si interviene
- Dopo l'hardfork, il nodo non riceverà più nuovi blocchi e non sarà in grado di seguire la testa della catena
- Le applicazioni e i wallet collegati a quel nodo tramite RPC non potranno ottenere i blocchi e le transazioni più recenti
- Un nodo rimasto sulla vecchia catena potrebbe continuare a restituire dati della catena dismessa
- Si noti che i nodi ordinari non sono mai soggetti a Slashing (solo i validatori sono soggetti a Slashing)
4. Domande frequenti
D. È necessario registrarsi come validatore o depositare 32 JOC?
No. I nodi ordinari che non producono blocchi non richiedono né la registrazione sul Launchpad né i deposit data. È necessaria soltanto la modifica della configurazione descritta sopra.
D. È necessario eliminare i dati della catena esistenti e risincronizzare?
No. Tutti i dati della catena esistenti e la cronologia delle transazioni vengono conservati.
D. Il Chain ID cambia?
No.
D. È necessario un server aggiuntivo?
Il Consensus Client può essere eseguito sull'host esistente, a condizione che disponga di spazio su disco e memoria sufficienti.
Contatti
Per qualsiasi domanda su questo hardfork, La preghiamo di contattarci tramite il modulo di contatto.