XRPL-Batch-Upgrade gewinnt wieder Validatorenstimmen: Warum der 9. Oktober weiterhin bedingt ist
Wichtige Erkenntnisse
- •BatchV1_1 hat zum 26. September 30 von 35 vertrauenswürdigen Validatorenstimmen zurückerhalten und damit ein neues Zweiwochen-Genehmigungsfenster im XRP Ledger gestartet.
- •XRPL-Amendments benötigen mehr als 80 % Validatorenunterstützung, also mindestens 29 von 35 Stimmen; der aktuelle Stand liegt eine Stimme über dieser Anforderung.
- •Der vorübergehende Verlust der Mehrheit am 25. September setzte die Genehmigungsfrist zurück und verschob die früheste bedingte Aktivierungsschätzung auf rund den 9. Oktober.
- •BatchV1_1 ist der korrigierte Nachfolger eines früheren Batch-Amendments, das vor der Mainnet-Aktivierung nach dem Auffinden einer Autorisierungsschwachstelle zurückgezogen wurde; Nutzergelder waren nicht betroffen.
- •Die Aktivierung kann nur durch eine im Ledger verzeichnete EnableAmendment-Pseudo-Transaktion bestätigt werden, nicht allein durch Dashboard-Stimmenzahlen.

Das XRPL Dashboard verzeichnete bei einer Prüfung um 04:43 UTC am 26. September 30 Ja-Stimmen unter den 35 von ihm erfassten vertrauenswürdigen Validatoren. Diese Zahl startet ein neues Genehmigungsfenster für das BatchV1_1-Amendment – sie führt für sich allein nicht zum Abschluss des Aktivierungsprozesses.
Wichtigste Punkte:
- BatchV1_1 hat 30 von 35 Validatorenstimmen zurückerhalten.
- Die bisherige Zweiwochen-Frist wurde zurückgesetzt.
- Mindestens 29 Stimmen müssen nun halten.
- Der 9. Oktober ist ein frühestes, bedingtes Datum.
- Die Aktivierung im Ledger bestätigt das Upgrade.
Das Datum wurde zurückgesetzt, obwohl die Stimmenzahl wiederhergestellt wurde
BatchV1_1 erreichte am 15. September 30 unterstützende Validatoren. Nach dem ursprünglichen Zeitplan hätte das eine Aktivierung um den 29. September bedeutet. Die Mehrheit wurde dann am 25. September aufgehoben und noch am selben Tag wiederhergestellt, wodurch sich die Schätzung um rund 10 Tage verschob.
Das Dashboard identifiziert die Flag-Ledgers, bei denen die frühere Mehrheit aufgehoben und die neue erfasst wurde. Es gibt keinen Aufschluss darüber, warum die vorübergehende Änderung erfolgte, und nennt keine Begründungen einzelner Validatoren. Die bestätigte Entwicklung ist der Reset selbst: Ein Amendment benötigt durchgehende Unterstützung über das gesamte Fenster, selbst wenn seine Stimmenzahl später wieder denselben Wert erreicht.
Das macht den 9. Oktober zu einer bedingten Schätzung, die aus dem aktuellen Mehrheitsstand des Ledgers abgeleitet ist. Sie kann vor der Aktivierung erneut verschieben.
Dreißig Ja-Stimmen liegen eine Stimme über der Grenze
Die XRPL-Schwelle wird oft zu „80 % Unterstützung" verkürzt, doch die Regel ist strenger: Ein Amendment benötigt mehr als 80 % Unterstützung durch vertrauenswürdige Validatoren. Bei 35 Validatoren im überwachten Set des Dashboards entsprechen 28 Stimmen genau 80 %. BatchV1_1 benötigt 29 Ja-Stimmen, um seine Mehrheit zu erreichen oder zu bewahren.
Die aktuelle Zahl von 30 entspricht rund 85,7 %. Sie liegt eine Stimme über der 29-Stimmen-Anforderung. Ein Rückgang von 30 auf 29 würde den Countdown unberührt lassen; ein Rückgang auf 28 würde an dem betreffenden Flag-Ledger einen erneuten Reset auslösen.
Der XRPL-Amendment-Prozess prüft die Stimmen rund um Flag-Ledgers, typischerweise etwa alle 15 Minuten. Diese Flag-Ledgers fungieren als wiederkehrende Kontrollpunkte, an denen die Unterstützung gemessen wird, und die Zweiwochen-Frist läuft nur, solange die Stimmenzahl über der Schwelle bleibt. Hat ein Amendment seine Unterstützung von mehr als 80 % zwei Wochen lang gehalten, gilt die Änderung dauerhaft für alle nachfolgenden Ledger-Versionen.
Servercode und Mainnet-Regeln sind getrennte Stufen
Coindoo hat zuvor erklärt, wie BatchV1_1 verbundene Zahlungsanweisungen koordinieren kann. Diese Funktionalität ist nicht der Punkt, den der Reset aufwirft. Die aktuelle Frage ist, ob das korrigierte Amendment den Validierungsprozess abschließen kann, der erforderlich ist, damit diese Transaktionsregeln im Mainnet in Kraft treten.
Die Verfügbarkeit in der Serversoftware macht ein Amendment für die Validator-Abstimmung wählbar, während sich das Mainnet-Verhalten erst ändert, nachdem das Netzwerk es aktiviert. Diese Trennung ist der Grund, warum ein Dashboard-Datum als live-Schätzung des Governance-Fortschritts und nicht als Produkt-Ankündigung zu lesen ist.
Warum der frühere Sicherheits-Rückzug jetzt relevant ist
BatchV1_1 ist der korrigierte Nachfolger eines früheren Batch-Amendments, das vor der Mainnet-Aktivierung zurückgezogen wurde, nachdem Forscher eine Autorisierungsschwachstelle gefunden hatten. Die ursprüngliche Version wurde nie aktiv, daher waren Mainnet-Nutzergelder nicht gefährdet.
Laut der XRPL-Schwachstellen-Disclosure enthielt die Ersatz-Version Änderungen an den Signatur- und Autorisierungsprüfungen und durchlief eine weitere Überprüfung, bevor sie zur Abstimmung zurückkehrte. Der Vorgang zeigt, wie der Prozess wie vorgesehen funktioniert: Code, der in Serversoftware verfügbar wird, kann noch gestoppt werden, bevor er Mainnet-Regeln verändert. Das neue14-Tage-Fenster ist der aktuelle Governance-Test für diese überarbeitete Implementierung.
Die Bestätigung, auf die zu achten ist, erfolgt im Ledger
Der 9. Oktober ist nur relevant, wenn die Mehrheit über das gesamte Fenster besteht. Die Bestätigung erfolgt über eine im Ledger aufgezeichnete EnableAmendment-Pseudo-Transaktion, wonach BatchV1_1 zu einer aktiven Mainnet-Regel für nachfolgende Ledgers wird.
Bis dieses Ereignis eintritt, ist die relevante Neuigkeit die Kontinuität der Validator-Mehrheit. Das Dashboard bietet eine nützliche Ansicht des aktuellen Countdowns, aber der Aktivierungsdatensatz des Ledgers wird entscheiden, ob das korrigierte Batch-Amendment tatsächlich die Schwelle zur live-XRPL-Infrastruktur überschritten hat.
Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Validatorenunterstützung und Amendment-Status können sich ändern.