Ein Protokolldatum ist eine Bedingung, kein Kalendereintrag
Victoria Shinder2 Min. LesezeitVier der heutigen Meldungen enthalten ein Datum, und jedes Mal ist das Datum das Unzuverlässigste daran.
Im XRP Ledger lief die Frist für das Amendment Batch auf eine Aktivierung Ende September zu. Die Zustimmung der Validatoren fiel kurz unter 80 Prozent, die Zwei-Wochen-Uhr begann neu, und frühestes Datum ist nun der 9. Oktober - vorausgesetzt, 30 von 35 Validatoren, also ein Abstand von ein oder zwei Stimmen, bleiben dabei. Bei Zcash verlegte Zebra 6.4.0 das Supportende des Knotens auf etwa den 2. November, damit Betreiber für NU7 bereit sind, das vorläufig für den 5. November geplant ist; binnen zwei Tagen waren 6.4.0 und sein Folge-Release wegen eines aus der Ferne auslösbaren Absturzes zurückgezogen. Bei Solana läuft Alpenglow im Devnet und Testnet mit dem Ziel von 150 ms Finalität, einen Mainnet-Termin gibt es nicht; das Dashboard der Stiftung zeigte heute Morgen im Devnet 322 ms. Und The Clearing House erwartet, dass sein Netz für tokenisierte Einlagen im ersten Halbjahr 2027 öffnet.
Warum sich das Datum verschiebt
Ein Blockchain-Upgrade geschieht nicht, wenn es jemand ansetzt. Es geschieht, wenn eine Bedingung erfüllt ist - eine lange genug gehaltene Mehrheit, genug aktualisierte Knoten, ein Testnetz, das sich gut genug verhält, um echtes Geld zu riskieren. Das gemeldete Datum ist der Zeitpunkt, an dem die Bedingung erfüllt wäre, wenn sich nichts ändert - und ändern kann sich immer etwas: Ein Validator startet mit anderer Stimme neu, ein Fuzzer findet einen Absturz, ein Leistungsziel hält in der Simulation, aber noch nicht im Live-Netz.
Das ist gewollt und kein Versagen. Die XRPL-Regel, nach der ein einziger Einbruch die Uhr zurücksetzt, sorgt dafür, dass ein Amendment nur bei dauerhafter Zustimmung aktiv wird. Dass Zebra die eigenen Releases binnen Stunden zurückzieht, ist der Prozess, der funktioniert. Die Kosten tragen die, die eine Prognose als Zusage behandelt haben - eine Börse, die einen von Batch abhängigen Start auf den 30. September gelegt hat, oder ein Betreiber, der mit Monaten zwischen dem NU7-Release und dem Upgrade gerechnet hat.
Wie man dagegen plant
Die Bedingung verfolgen, nicht die Schlagzeile. Bei XRPL-Amendments ist das der Mehrheitszeitpunkt, den jeder rippled-Server über die Methode feature liefert, plus vierzehn Tage. Bei Netzwerk-Upgrades sind es die Aktivierungshöhe in der Knotensoftware und das Supportfenster in den Release Notes. Bei Konsensänderungen sind es die Live-Messwerte, die das Projekt veröffentlicht, im Vergleich zum Ziel. Dann den Plan mit dem Spielraum bauen, den die Bedingung vorgibt: Ein Start, der Batch braucht, ist ein Start für "zwei Wochen, nachdem sich die Zustimmung stabilisiert hat", und ein Knoten-Update, das vor einem Hard Fork liegen muss, plant man am Tag des Releases ein, nicht in der Woche vor dem Fork.