Tokyo Hardfork (Japan Open Chain v2)
Japan Open Chain führt ein Netzwerk-Upgrade mit dem Namen Tokyo Hardfork durch. Mit diesem Hardfork wird der Konsensmechanismus von Clique PoA auf PoSA (Proof of Staked Authority / PoA v2) umgestellt.
Zeitplan
| Netzwerk | Datum | Status |
|---|---|---|
| Testnet | 7. September 2026 | Abgeschlossen |
| Mainnet (Start der Beacon Chain) | 18. September 2026 | Abgeschlossen |
| Mainnet (Phase 1 / The Merge) | Noch nicht festgelegt (Entscheidung im Validator-Meeting) | In Vorbereitung |
Wenn Sie einen Knoten im Testnet betreiben, schließen Sie die Konfigurationsänderung bitte vor dem 7. September 2026 ab. Ein Upgrade von Geth allein reicht nicht aus. Einzelheiten finden Sie in den folgenden Schritten.
Zur Mainnet Beacon Chain
Das Mainnet-Upgrade erfolgt in zwei Stufen.
- Start der Beacon Chain (18. September 2026 — abgeschlossen)
Der Consensus Layer hat seinen Betrieb vor dem Execution Layer aufgenommen. Blöcke werden weiterhin durch Clique PoA erzeugt, sodass derzeit keine Auswirkungen auf allgemeine Nutzer oder Knotenbetreiber bestehen. - Phase 1 — Hardfork (The Merge) (noch nicht festgelegt)
Der Execution Layer wird künftig auf Anweisung der Beacon Chain arbeiten. Organisationen, die einen eigenen Knoten betreiben, müssen zu diesem Zeitpunkt ihre Konfiguration ändern. Das Datum wird auf dieser Seite bekannt gegeben, sobald es im Validator-Meeting festgelegt wurde.
Die Konfigurationsdateien für das Mainnet (config.yaml, genesis.ssz, Informationen zum Deposit Contract sowie die Listen der Bootnodes / Boot-ENRs) werden im Verzeichnis metadata/ des Repositorys japan-open-chain/mainnet veröffentlicht. Die detaillierten Schritte zur Einrichtung eines Knotens finden Sie in der Anleitung zur Verbindung mit einem Mainnet-Knoten.
Erforderliche Maßnahmen in dieser Phase
| Betroffene | Erforderliche Maßnahme |
|---|---|
| JOC-Inhaber, allgemeine Nutzer und Nutzer der JOC RPC Endpoints | Keine Maßnahme erforderlich |
| Organisationen, die einen eigenen Knoten im Mainnet betreiben | Sie können Ihre aktuelle Konfiguration, die nur aus dem Execution Client (Geth) besteht, beibehalten. Wir empfehlen jedoch, bereits jetzt im Hinblick auf den nächsten Hardfork (The Merge) einen Consensus Client (empfohlen: Lighthouse) gemäß der Anleitung zur Verbindung mit einem Mainnet-Knoten einzurichten |
Vor dem Hardfork kann Geth ab Version v1.14.0 nicht mit der Chain synchronisieren. Bitte verwenden Sie weiterhin die Versionsreihe v1.13.
Erforderliche Maßnahmen
| Betroffene | Erforderliche Maßnahme |
|---|---|
| JOC-Inhaber und allgemeine Nutzer | Keine Maßnahme erforderlich |
| Nutzer der JOC RPC Endpoints | Keine Maßnahme erforderlich |
| dApp-Entwickler | Die Chain ID ändert sich nicht. Eine Maßnahme ist nur erforderlich, wenn Sie einen eigenen Knoten betreiben |
| Organisationen, die einen eigenen Knoten betreiben | Maßnahme zum Hardfork erforderlich. Ändern Sie Ihre Knotenkonfiguration gemäß den folgenden Schritten |
| Validatoren | Maßnahme erforderlich. Gesonderte Anweisungen werden bereitgestellt |
Schritte für Betreiber von Testnet-Knoten
Betroffen: Organisationen, die direkt über die Bootnodes des JOC Testnet synchronisieren und einen eigenen Knoten betreiben. Wenn Sie die JOC RPC Endpoints nutzen, ist keine Maßnahme erforderlich.
Ein Upgrade von Geth allein reicht nicht aus
Unter PoA hat der Execution Client (Geth) Blöcke eigenständig verifiziert und synchronisiert. Nach der Umstellung auf PoSA wird die Gültigkeit von Blöcken durch den Consensus Layer (die Beacon Chain) bestimmt. Geth übernimmt nur noch die Ausführung und erhält Fork-Choice-Anweisungen vom Consensus Client.
Die erforderliche Arbeit ist daher keine Versionsaktualisierung, sondern eine Konfigurationsänderung.
[Aktuell] [Nach dem Tokyo Hardfork]
Geth (eigenständig) Geth ── Engine API ── Lighthouse
│ │ │
P2P zu nur Ausführung Konsens / Fork Choice
Bootnodes │
zu CL-Bootnodes
1. Vor dem Hardfork abzuschließen
Schritt 1 — Konfigurationsdateien beschaffen
| Datei | Zweck | Hinweise |
|---|---|---|
genesis.json (aktualisiert) | Für den Execution Client. Enthält die TTD und die einzelnen Fork-Zeitpunkte | Unterscheidet sich von der derzeit veröffentlichten Version |
config.yaml | Chain-Spezifikation für den Consensus Client | Definiert die Fork-Epochen und die Netzwerk-ID |
deposit_contract_block.txt | Blocknummer des Deposit Contract | |
genesis.ssz | Genesis-Zustand der Beacon Chain | Ca. 5,5 MB |
Diese Dateien werden im Verzeichnis metadata/ des Testnet-Repositorys bereitgestellt.
Schritt 2 — Geth auf der Versionsreihe v1.13 belassen
Verwenden Sie weiterhin Geth v1.13.5, die auf dieser Website verifizierte Version. Geth ab Version v1.14.0 kann derzeit nicht mit der Chain synchronisieren.
Für die Phasen Shapella, Dencun und Pectra wird eine neuere Version von Geth erforderlich sein. Die unterstützte Version wird auf dieser Seite bekannt gegeben, sobald der Zeitplan feststeht.
Schritt 3 — Einen Consensus Client einrichten
- Empfohlen: Lighthouse v7.0.1 (Docker-Image
sigp/lighthouse:v7.0.1) - Lighthouse wurde getestet und läuft stabil; andere Clients wurden nicht verifiziert
- Er kann auf demselben Host wie Ihr bestehendes Geth betrieben werden
- Bootnodes (ENR) für den Consensus Layer müssen konfiguriert werden (werden nach Festlegung bekannt gegeben)
- Für die Erstsynchronisierung empfehlen wir checkpoint sync (der Endpunkt wird nach Festlegung bekannt gegeben)
Schritt 4 — Geth und den Consensus Client über die Engine API verbinden
Beide kommunizieren über die authentifizierte Engine API (Standardport 8551). Erzeugen Sie ein gemeinsames JWT-Secret und konfigurieren Sie es auf beiden Seiten.
# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex
Auf der Geth-Seite hinzuzufügende Startoptionen:
--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost
Schritt 5 — Synchronisierung und Verbindung überprüfen
- Der Consensus Client hat zur Beacon Chain aufgeschlossen
- Das Log von Geth verzeichnet Fork-Choice-Updates über die Engine API
- Lassen Sie am Tag des Hardforks beide Clients in Betrieb. The Merge wird automatisch ausgelöst, sobald die konfigurierte TTD erreicht ist
2. Erforderliche Arbeiten in jeder Phase nach dem Hardfork
Für die Phasen Shapella, Dencun und Pectra müssen Sie nach unserer Ankündigung Ihre Konfiguration aktualisieren und neu starten.
| Phase | Execution Client | Consensus Client |
|---|---|---|
| Phase 2 — Shapella | shanghaiTime festlegen | CAPELLA_FORK_VERSION / CAPELLA_FORK_EPOCH |
| Phase 3 — Dencun | cancunTime festlegen | DENEB_FORK_VERSION / DENEB_FORK_EPOCH |
| Phase 4 — Pectra | pragueTime festlegen | ELECTRA_FORK_VERSION / ELECTRA_FORK_EPOCH |
Aktualisieren Sie Ihre Konfiguration nicht und führen Sie keinen Neustart nach eigenem Ermessen durch, bevor wir dies angekündigt haben.
3. Wenn Sie keine Maßnahmen ergreifen
- Nach dem Hardfork erhält der Knoten keine neuen Blöcke mehr und kann der Spitze der Chain nicht mehr folgen
- Anwendungen und Wallets, die über RPC mit diesem Knoten verbunden sind, können die neuesten Blöcke und Transaktionen nicht mehr abrufen
- Ein auf der alten Chain zurückgebliebener Knoten kann weiterhin Daten der eingestellten Chain zurückgeben
- Bitte beachten Sie, dass gewöhnliche Knoten niemals dem Slashing unterliegen (nur Validatoren sind vom Slashing betroffen)
4. Häufig gestellte Fragen
F. Muss ich mich als Validator registrieren oder 32 JOC hinterlegen?
Nein. Gewöhnliche Knoten, die keine Blöcke erzeugen, benötigen weder eine Registrierung im Launchpad noch Deposit-Daten. Erforderlich ist lediglich die oben beschriebene Konfigurationsänderung.
F. Muss ich meine bestehenden Chain-Daten löschen und neu synchronisieren?
Nein. Sämtliche bestehenden Chain-Daten und der Transaktionsverlauf bleiben erhalten.
F. Ändert sich die Chain ID?
Nein.
F. Benötige ich einen zusätzlichen Server?
Der Consensus Client kann auf Ihrem bestehenden Host betrieben werden, sofern dieser über ausreichend Reserven bei Festplattenspeicher und Arbeitsspeicher verfügt.
Kontakt
Bei Fragen zu diesem Hardfork wenden Sie sich bitte über das Kontaktformular an uns.