Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain llevará a cabo una actualización de la red denominada Tokyo Hardfork. Con este hardfork, el mecanismo de consenso migra de Clique PoA a PoSA (Proof of Staked Authority / PoA v2).
Calendario
| Red | Fecha | Estado |
|---|---|---|
| Testnet | 7 de septiembre de 2026 | Completado |
| Mainnet (lanzamiento de la beacon chain) | 18 de septiembre de 2026 | Completado |
| Mainnet (Phase 1 / The Merge) | Por determinar (se decidirá en la reunión de validadores) | En preparación |
Si opera un nodo en la Testnet, le rogamos que complete el cambio de configuración antes del 7 de septiembre de 2026. No basta con actualizar Geth. Consulte los pasos que se indican a continuación para más detalles.
Acerca de la beacon chain de la Mainnet
La actualización de la Mainnet se realiza en dos etapas.
- Lanzamiento de la beacon chain (18 de septiembre de 2026 — completado)
La Consensus Layer comenzó a funcionar antes que la Execution Layer. Los bloques siguen siendo producidos por Clique PoA, por lo que, por el momento, no hay ningún impacto para los usuarios en general ni para los operadores de nodos. - Phase 1 — Hardfork (The Merge) (por determinar)
La Execution Layer pasará a operar según las instrucciones de la beacon chain. Las organizaciones que operan su propio nodo deberán cambiar su configuración en ese momento. La fecha se anunciará en esta página una vez que se decida en la reunión de validadores.
Los archivos de configuración de la Mainnet (config.yaml, genesis.ssz, la información del deposit contract y las listas de bootnodes / boot ENR) se publican en el directorio metadata/ del repositorio japan-open-chain/mainnet. Para conocer los pasos detallados de configuración del nodo, consulte la guía de conexión de nodos a la Mainnet.
Qué debe hacer en esta etapa
| Perfil | Acción requerida |
|---|---|
| Poseedores de JOC, usuarios en general y usuarios de los RPC Endpoints de JOC | No se requiere ninguna acción |
| Organizaciones que operan su propio nodo en la Mainnet | Puede mantener su configuración actual con solo el Execution Client (Geth), pero le recomendamos configurar ya un Consensus Client (recomendado: Lighthouse), antes del próximo hardfork (The Merge), siguiendo la guía de conexión de nodos a la Mainnet |
Antes del hardfork, Geth v1.14.0 o posterior no puede sincronizar la cadena. Le rogamos que siga utilizando la serie v1.13.
Qué debe hacer
| Perfil | Acción requerida |
|---|---|
| Poseedores de JOC y usuarios en general | No se requiere ninguna acción |
| Usuarios de los RPC Endpoints de JOC | No se requiere ninguna acción |
| Desarrolladores de dApps | El Chain ID no cambia. Solo se requiere una acción si opera su propio nodo |
| Organizaciones que operan su propio nodo | Acción requerida en el momento del hardfork. Siga los pasos que se indican a continuación para cambiar la configuración de su nodo |
| Validadores | Acción requerida. Se proporcionarán instrucciones por separado |
Pasos para operadores de nodos en la Testnet
A quién se aplica: organizaciones que se sincronizan directamente desde los boot nodes de la Testnet de JOC y operan su propio nodo. Si utiliza los RPC Endpoints de JOC, no se requiere ninguna acción.
No basta con actualizar Geth
Con PoA, el Execution Client (Geth) verificaba y sincronizaba los bloques por sí solo. Tras la migración a PoSA, la validez de los bloques la determina la Consensus Layer (la beacon chain). Geth se encarga únicamente de la ejecución y recibe las instrucciones de fork choice del Consensus Client.
Por lo tanto, el trabajo necesario es un cambio de configuración, no una actualización de versión.
[Actual] [Tras el Tokyo Hardfork]
Geth (independiente) Geth ── Engine API ── Lighthouse
│ │ │
P2P hacia solo ejecución consenso / fork choice
boot nodes │
hacia boot nodes de CL
1. Tareas que deben completarse antes del hardfork
Step 1 — Obtener los archivos de configuración
| Archivo | Finalidad | Observaciones |
|---|---|---|
genesis.json (actualizado) | Para el Execution Client. Contiene el TTD y la hora de cada fork | Distinto de la versión publicada actualmente |
config.yaml | Especificación de la cadena para el Consensus Client | Define los fork epochs y el network ID |
deposit_contract_block.txt | Número de bloque del Deposit Contract | |
genesis.ssz | Estado génesis de la beacon chain | Aprox. 5,5 MB |
Estos archivos se distribuyen en el directorio metadata/ del repositorio de la Testnet.
Step 2 — Mantener Geth en la serie v1.13
Siga utilizando Geth v1.13.5, la versión verificada en este sitio. Actualmente, Geth v1.14.0 y posteriores no pueden sincronizar la cadena.
Para las fases Shapella, Dencun y Pectra se requerirá una versión más reciente de Geth. Anunciaremos la versión compatible en esta página una vez que se confirme el calendario.
Step 3 — Configurar un Consensus Client
- Recomendado: Lighthouse v7.0.1 (imagen de Docker
sigp/lighthouse:v7.0.1) - Lighthouse ha sido probado y funciona de forma estable; otros clientes no han sido verificados
- Puede ejecutarse en el mismo host que su Geth existente
- Es necesario configurar los boot nodes (ENR) de la Consensus Layer (se anunciarán una vez confirmados)
- Recomendamos utilizar checkpoint sync para la sincronización inicial (el endpoint se anunciará una vez confirmado)
Step 4 — Conectar Geth y el Consensus Client mediante la Engine API
Ambos se comunican a través de la Engine API autenticada (puerto predeterminado 8551). Genere un secreto JWT compartido y configúrelo en ambos lados.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Opciones de arranque que deben añadirse en Geth:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Verificar la sincronización y la conectividad
- El Consensus Client se ha puesto al día con la beacon chain
- El registro de Geth muestra actualizaciones de fork choice a través de la Engine API
- Mantenga ambos clientes en funcionamiento el día del hardfork. The Merge se activa automáticamente al alcanzarse el TTD configurado
2. Tareas necesarias en cada fase posterior al hardfork
En las fases Shapella, Dencun y Pectra, deberá actualizar su configuración y reiniciar tras nuestro anuncio.
| Fase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | Configurar shanghaiTime | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | Configurar cancunTime | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | Configurar pragueTime | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
No actualice la configuración ni reinicie por iniciativa propia antes de nuestro anuncio.
3. Si no realiza las acciones indicadas
- Tras el hardfork, el nodo dejará de recibir nuevos bloques y no podrá seguir la cabeza de la cadena
- Las aplicaciones y wallets conectadas a ese nodo mediante RPC no podrán obtener los bloques ni las transacciones más recientes
- Un nodo que quede en la cadena antigua puede seguir devolviendo datos de la cadena discontinuada
- Tenga en cuenta que los nodos ordinarios nunca son objeto de Slashing (solo los validadores están sujetos a Slashing)
4. Preguntas frecuentes
P. ¿Es necesario registrarse como validador o depositar 32 JOC?
No. Los nodos ordinarios que no producen bloques no requieren registro en Launchpad ni deposit data. Solo es necesario el cambio de configuración descrito anteriormente.
P. ¿Es necesario eliminar los datos de cadena existentes y volver a sincronizar?
No. Se conservan todos los datos de cadena existentes y el historial de transacciones.
P. ¿Cambia el Chain ID?
No.
P. ¿Necesito un servidor adicional?
El Consensus Client puede ejecutarse en su host existente, siempre que disponga de suficiente margen de disco y memoria.
Contacto
Si tiene alguna pregunta sobre este hardfork, le rogamos que se ponga en contacto con nosotros a través del formulario de contacto.