Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain va procéder à une mise à niveau du réseau appelée Tokyo Hardfork. Avec ce hardfork, le mécanisme de consensus passe de Clique PoA à PoSA (Proof of Staked Authority / PoA v2).
Calendrier
| Réseau | Date | Statut |
|---|---|---|
| Testnet | 7 septembre 2026 | Terminé |
| Mainnet (lancement de la beacon chain) | 18 septembre 2026 | Terminé |
| Mainnet (Phase 1 / The Merge) | À déterminer (décidé lors de la réunion des validateurs) | En préparation |
Si vous exploitez un nœud sur le Testnet, veuillez effectuer la modification de configuration avant le 7 septembre 2026. La simple mise à jour de Geth ne suffit pas. Veuillez consulter les étapes ci-dessous pour plus de détails.
À propos de la beacon chain du Mainnet
La mise à niveau du Mainnet se déroule en deux étapes.
- Lancement de la beacon chain (18 septembre 2026 — terminé)
La Consensus Layer a commencé à fonctionner en amont de l'Execution Layer. Les blocs sont toujours produits par Clique PoA ; il n'y a donc, à ce stade, aucun impact pour les utilisateurs en général ni pour les opérateurs de nœuds. - Phase 1 — Hardfork (The Merge) (à déterminer)
L'Execution Layer fonctionnera selon les instructions de la beacon chain. Les organisations qui exploitent leur propre nœud devront modifier leur configuration à ce moment-là. La date sera annoncée sur cette page dès qu'elle aura été décidée lors de la réunion des validateurs.
Les fichiers de configuration du Mainnet (config.yaml, genesis.ssz, les informations sur le deposit contract et les listes de bootnodes / boot ENR) sont publiés dans le répertoire metadata/ du dépôt japan-open-chain/mainnet. Pour les étapes détaillées de configuration du nœud, veuillez consulter le guide de connexion des nœuds au Mainnet.
Ce que vous devez faire à ce stade
| Profil | Action requise |
|---|---|
| Détenteurs de JOC, utilisateurs en général et utilisateurs des RPC Endpoints de JOC | Aucune action requise |
| Organisations exploitant leur propre nœud sur le Mainnet | Vous pouvez conserver votre configuration actuelle composée uniquement de l'Execution Client (Geth), mais nous vous recommandons de mettre en place dès maintenant un Consensus Client (recommandé : Lighthouse), en prévision du prochain hardfork (The Merge), en suivant le guide de connexion des nœuds au Mainnet |
Avant le hardfork, Geth v1.14.0 ou ultérieur ne peut pas synchroniser la chaîne. Veuillez continuer à utiliser la série v1.13.
Ce que vous devez faire
| Profil | Action requise |
|---|---|
| Détenteurs de JOC et utilisateurs en général | Aucune action requise |
| Utilisateurs des RPC Endpoints de JOC | Aucune action requise |
| Développeurs de dApps | Le Chain ID ne change pas. Une action n'est requise que si vous exploitez votre propre nœud |
| Organisations exploitant leur propre nœud | Action requise lors du hardfork. Veuillez suivre les étapes ci-dessous pour modifier la configuration de votre nœud |
| Validateurs | Action requise. Des instructions distinctes vous seront communiquées |
Étapes pour les opérateurs de nœuds sur le Testnet
Public concerné : les organisations qui se synchronisent directement à partir des boot nodes du Testnet de JOC et exploitent leur propre nœud. Si vous utilisez les RPC Endpoints de JOC, aucune action n'est requise.
La simple mise à jour de Geth ne suffit pas
Sous PoA, l'Execution Client (Geth) vérifiait et synchronisait les blocs de manière autonome. Après la migration vers PoSA, la validité des blocs est déterminée par la Consensus Layer (la beacon chain). Geth se charge uniquement de l'exécution et reçoit les instructions de fork choice du Consensus Client.
Le travail nécessaire est donc une modification de configuration, et non une mise à jour de version.
[Actuel] [Après le Tokyo Hardfork]
Geth (autonome) Geth ── Engine API ── Lighthouse
│ │ │
P2P vers les exécution seule consensus / fork choice
boot nodes │
vers les boot nodes CL
1. À effectuer avant le hardfork
Step 1 — Obtenir les fichiers de configuration
| Fichier | Utilisation | Remarques |
|---|---|---|
genesis.json (mis à jour) | Pour l'Execution Client. Contient le TTD et l'heure de chaque fork | Différent de la version actuellement publiée |
config.yaml | Spécification de la chaîne pour le Consensus Client | Définit les fork epochs et le network ID |
deposit_contract_block.txt | Numéro de bloc du Deposit Contract | |
genesis.ssz | État genesis de la beacon chain | Env. 5,5 Mo |
Ces fichiers sont distribués dans le répertoire metadata/ du dépôt du Testnet.
Step 2 — Conserver Geth sur la série v1.13
Veuillez continuer à utiliser Geth v1.13.5, la version vérifiée sur ce site. Geth v1.14.0 et les versions ultérieures ne peuvent actuellement pas synchroniser la chaîne.
Une version plus récente de Geth sera nécessaire pour les phases Shapella, Dencun et Pectra. Nous annoncerons la version prise en charge sur cette page dès que le calendrier sera confirmé.
Step 3 — Mettre en place un Consensus Client
- Recommandé : Lighthouse v7.0.1 (image Docker
sigp/lighthouse:v7.0.1) - Lighthouse a été testé et fonctionne de manière stable ; les autres clients n'ont pas été vérifiés
- Il peut fonctionner sur le même hôte que votre Geth existant
- Les boot nodes (ENR) de la Consensus Layer doivent être configurés (ils seront annoncés dès leur confirmation)
- Nous recommandons d'utiliser le checkpoint sync pour la synchronisation initiale (l'endpoint sera annoncé dès sa confirmation)
Step 4 — Connecter Geth et le Consensus Client via l'Engine API
Les deux communiquent via l'Engine API authentifiée (port par défaut 8551). Générez un secret JWT partagé et configurez-le des deux côtés.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Options de démarrage à ajouter côté Geth :
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Step 5 — Vérifier la synchronisation et la connectivité
- Le Consensus Client a rattrapé la beacon chain
- Le journal de Geth enregistre les mises à jour de fork choice via l'Engine API
- Laissez les deux clients en fonctionnement le jour du hardfork. The Merge se déclenche automatiquement lorsque le TTD configuré est atteint
2. Travaux requis à chaque phase après le hardfork
Pour les phases Shapella, Dencun et Pectra, vous devrez mettre à jour votre configuration et redémarrer après notre annonce.
| Phase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | Définir shanghaiTime | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | Définir cancunTime | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | Définir pragueTime | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Veuillez ne pas mettre à jour votre configuration ni redémarrer de votre propre initiative avant notre annonce.
3. Si vous n'effectuez pas ces actions
- Après le hardfork, le nœud ne recevra plus de nouveaux blocs et ne pourra plus suivre la tête de la chaîne
- Les applications et wallets connectés à ce nœud via RPC ne pourront plus récupérer les derniers blocs ni les dernières transactions
- Un nœud resté sur l'ancienne chaîne peut continuer à renvoyer des données de la chaîne abandonnée
- Veuillez noter que les nœuds ordinaires ne font jamais l'objet de Slashing (seuls les validateurs y sont soumis)
4. Questions fréquentes
Q. Dois-je m'enregistrer en tant que validateur ou déposer 32 JOC ?
Non. Les nœuds ordinaires qui ne produisent pas de blocs ne nécessitent ni enregistrement sur le Launchpad ni deposit data. Seule la modification de configuration décrite ci-dessus est nécessaire.
Q. Dois-je supprimer mes données de chaîne existantes et resynchroniser ?
Non. Toutes les données de chaîne existantes et l'historique des transactions sont conservés.
Q. Le Chain ID change-t-il ?
Non.
Q. Ai-je besoin d'un serveur supplémentaire ?
Le Consensus Client peut fonctionner sur votre hôte existant, à condition que celui-ci dispose d'une marge suffisante en disque et en mémoire.
Contact
Pour toute question concernant ce hardfork, veuillez nous contacter via le formulaire de contact.