XRP-Ledger-Validatoren haben das korrigierte BatchV1_1-Amendment auf einen bedingten Pfad zur Aktivierung am 29. September um 14:06:41 UTC gesetzt. Dreißig von 35 vertrauenswürdigen Validatoren unterstützten das Amendment und liegen damit über der Schwelle von 28 Stimmen. Die Mehrheit zeigte sich erstmals am 15. September on-ledger. Nach den Regeln von XRPL muss die Unterstützung zwei Wochen lang über 80% bleiben, daher bleibt der Termin bedingt. Das Amendment ersetzt eine frühere Version, die zurückgezogen wurde, nachdem Forscher im Februar eine kritische Autorisierungsschwachstelle gefunden hatten, noch bevor sie jemals das Mainnet erreichte.
Warum es wichtig ist
Der Vorfall bestätigte die Wirksamkeit von XRPLs Amendment-Firewall. Das ursprüngliche Batch-Amendment befand sich noch in der Abstimmungsphase, als Forscher einen Signer-Loop-Bug meldeten, der frühzeitig Erfolg zurückmeldete, statt die verbleibenden Signer zu prüfen. Wäre er live gegangen, hätte ein gefälschter Eintrag die Transaktion eines Opfers ohne dessen Schlüssel ausführen können, wobei die Offenlegung von XRPL Labs bestätigt, dass niemals Gelder gefährdet waren.
BatchV1_1 ersetzt diesen Pfad durch ein neu geschriebenes Autorisierungsschema gemäß der XLS-56-Spezifikation. Jede BatchSigner-Signatur bindet nun das äußere Konto, seine Sequenznummer oder sein Ticket, den Batch-Modus, die geordneten Hashes aller inneren Transaktionen sowie sämtliche verschachtelten Signer. Damit sind sowohl der gemeldete Bug als auch angrenzende Replay-Vektoren geschlossen.
Marktauswirkung
Die Protokollkorrektur verlagert das Risiko auf die Implementierung. Ein äußerer Batch kann tesSUCCESS zurückgeben, selbst wenn innere Transaktionen fehlschlagen. Clients müssen daher jeden inneren Ergebnisscode prüfen. BatchV1_1-Unterstützung wurde am 6. August mit xrpld 3.3.0 ausgeliefert, und Server, die nicht aufrüsten, werden nach der Aktivierung amendment-blocked. xrpl.js 5.0.0 erstellte Signaturen auf Basis der älteren Payload und wird mit temBAD_SIGNATURE abgelehnt. Kompatible Unterstützung kommt mit 5.1.0.
Die Aktivierung belegt die Verfügbarkeit des Protokolls, nicht aber Adoption oder XRP-Nachfrage. Die Signale, auf die es danach ankommt: Werden veraltete Nodes blockiert, häufen sich Signaturfehler bei alten Client-Versionen, und stellen Wallets und Explorer Multi-Account-Batches verständlich dar?
Häufig gestellte Fragen
-
Wann wird XRPLs BatchV1_1-Amendment aktiviert?
Bedingt am 29. September um 14:06:41 UTC, sofern die Validator-Unterstützung über den erforderlichen Zweiwochenzeitraum hinweg über 80% bleibt. Derzeit unterstützen 30 von 35 vertrauenswürdigen Validatoren das Amendment, über der Schwelle von 28 Stimmen.
-
Was war die Schwachstelle im ursprünglichen XRPL-Batch-Amendment?
Ein Signer-Loop-Bug meldete frühzeitig Erfolg, wenn er auf einen Signer für ein neu erstelltes Konto stieß. Ein gefälschter Eintrag, der vorgab, ein Opferkonto zu autorisieren, hätte so ohne dessen Schlüssel ausgeführt werden können. Gelder waren nie gefährdet.
-
Warum kann ein XRPL-Batch Erfolg zeigen, während innere Transaktionen fehlschlagen?
Ein äußerer Batch kann tesSUCCESS zurückgeben, selbst wenn eine oder mehrere innere Transaktionen fehlschlagen. Außerhalb des ALLORNOTHING-Modus ist eine teilweise Ausführung beabsichtigt. Clients müssen die Metadaten und den Ergebnisscode jeder inneren Transaktion prüfen.
-
Welche Softwareversionen unterstützen BatchV1_1?
xrpld 3.3.0 lieferte die BatchV1_1-Unterstützung am 6. August aus, und xrpl.js 5.1.0 fügte das überarbeitete Signaturformat hinzu. Version 5.0.0 erzeugt Signaturen, die BatchV1_1-Nodes mit temBAD_SIGNATURE ablehnen, und veraltete Server riskieren, amendment-blocked zu werden.
-
Bedeutet die Aktivierung von BatchV1_1 eine höhere Nachfrage nach XRP?
Nicht für sich genommen. Abstimmung und Software-Releases stellen nur die Protokollverfügbarkeit sicher. Aussagekräftige Signale folgen erst nach der Aktivierung, etwa blockierte Nodes, Signaturfehler auf alten Clients und die Darstellung von Batches in Wallets und Explorern.