Die Entwicklungen kommen zu einem Zeitpunkt, an dem XRPL seine Rolle bei institutionellen Zahlungen, Stablecoins und tokenisierten Vermögenswerten ausbaut. Dadurch gewinnen eine zuverlässige Abwicklungsinfrastruktur und Schutzmaßnahmen für Finanztransaktionen zunehmend an Bedeutung.

$XRP Verlangsamung des Ledgers macht Herausforderungen bei der Transaktionsverarbeitung deutlich

Das Betriebsproblem trat am 21. Oktober auf, als einige Ledger länger als üblich für den Abschluss benötigten und so den üblichen Abwicklungsrhythmus der Blockchain von drei bis fünf Sekunden störten.

XRPL Operations erklärte, dass die meisten Ledger weiterhin normal abgeschlossen wurden. Die zeitweiligen Verzögerungen veranlassten Entwickler jedoch, das Verhalten des Netzwerks zu untersuchen und eine Softwarekorrektur vorzubereiten.

Als die Verzögerungen anhielten, stellte das Team Hub-, Validator- und Node-Betreibern eine empfohlene Konfigurationsänderung für xrpld bereit.

Laut dem Betriebsteam wurden die üblichen Abschlusszeiten bis zum 22. Oktober wiederhergestellt. Die Entwickler testeten jedoch weiterhin eine Point-Release-Version, die die zugrunde liegende Ursache beheben soll.

David Schwartz, einer der ursprünglichen Architekten von XRPL und ehemaliger Chief Technology Officer von Ripple, gab weitere Einblicke in mögliche Ursachen des Vorfalls.

Er sagte, sein eigener Hub habe nach einem früheren Vorfall, den er für unabhängig hielt, normal weitergearbeitet. Er startete ihn jedoch mit der empfohlenen Konfigurationsänderung neu.

Schwartz sagte:

„Ich verstehe, dass das Problem damit zusammenhing, dass Server zu sehr versuchten, zu viele Transaktionen in jedes Ledger aufzunehmen.“

Auf die Frage, ob dies darauf hindeute, dass XRPL an eine praktische Grenze seiner Transaktionsverarbeitungskapazität gestoßen sei, räumte Schwartz einen Zusammenhang zwischen dem Transaktionsvolumen und der Häufigkeit von Ledger-Abschlüssen ein.

Er fügte hinzu:

„Ja und nein. Wir können ein Ledger nicht öfter als alle 4 Sekunden abschließen. Eine Begrenzung der Zahl der Transaktionen pro Ledger legt also nicht unbedingt eine TPS-Grenze fest.“

Seine Äußerungen deuten auf einen möglichen Zielkonflikt zwischen der Verarbeitung einer größeren Zahl von Transaktionen in jedem Ledger und der Einhaltung gleichbleibender Abwicklungszeiten hin.

Die Entwickler haben jedoch nicht festgestellt, ob der Vorfall auf eine umfassendere Kapazitätsbeschränkung des Netzwerks oder auf ein Softwareverhalten zurückzuführen ist, das sich ohne Auswirkungen auf den Durchsatz korrigieren lässt.

Diese Unterscheidung hat kommerzielle Bedeutung, da XRPL Anwendungen anzieht, die eine vorhersehbare Abwicklung erfordern, darunter RLUSD-Stablecoin-Transfers, tokenisierte Wertpapiere und institutionelle Zahlungsdienste.

Weitere Störungen könnten die Transaktionsverarbeitung bei Diensten erschweren, die auf eine schnelle Bewegung von Geldern oder Sicherheiten angewiesen sind.

Die bevorstehende Softwareversion wird daher wichtig sein, um festzustellen, ob die Konfigurationsänderung eine dauerhafte Lösung bietet oder ob weitere Anpassungen nötig sind, um die Leistung bei höherem Transaktionsaufkommen aufrechtzuerhalten.

Rückschlag bei Validator-Abstimmung verzögert finanzielle Schutzmaßnahmen

Unabhängig davon hat XRPLs Änderung fixCleanup3_4_0 einen Rückschlag in der Governance erlitten, der die Aktivierung mehrerer Korrekturen an der Finanzinfrastruktur verzögern wird.

Die im September mit der xrpld-Version 3.4.0 eingeführte Änderung behebt technische Probleme im Zusammenhang mit Token-Berechtigungen, automatisierten Market Makern, Asset-Vaults, Kreditgeschäften und Escrow-Transaktionen.

Zu den Änderungen gehört die Behebung einer Schwachstelle bei der Delegierung von Berechtigungen, durch die ein Konto, das zum Vernichten bestimmter fungibler Token berechtigt ist, unter bestimmten Umständen zusätzliche Token hätte erstellen können.

Die Dokumentation des Netzwerks rät Emittenten davon ab, die betroffene Berechtigung PaymentBurn zu delegieren, bis die Korrektur aktiv ist.

Weitere Änderungen verbessern die Genauigkeit der Vault-Buchführung, setzen Schutzmaßnahmen für Token-Bestände durch und korrigieren die Transaktionsverarbeitung beim dezentralen Handel und bei Kreditfunktionen.

Die vorgeschlagenen Schutzmaßnahmen waren auf die Aktivierung am 23. Oktober zugesteuert, bevor die Unterstützung durch Validatoren kurzzeitig unter die für eine Änderung der Protokollregeln von XRPL erforderliche Supermehrheit fiel.

Damit eine Änderung aktiviert werden kann, verlangt XRPL die ununterbrochene Unterstützung von mehr als 80 % der vertrauenswürdigen Validatoren über 14 Tage.

Der vorübergehende Wegfall der Unterstützung am 21. Oktober setzte den bis dahin angesammelten Genehmigungszeitraum der Änderung zurück, obwohl die Unterstützung anschließend wieder über den erforderlichen Schwellenwert stieg.

Der Änderungstracker von XRPLWin nennt nun den 4. November als frühestmöglichen Aktivierungstermin, sofern die erneute Mehrheit bestehen bleibt.

Der XRPL-Mitwirkende Vet bestätigte, dass zusätzliche Validator-Stimmen den Countdown bis zur Aktivierung der Änderung wiederhergestellt hatten. Er stellte außerdem klar, dass fixCleanup3_4_0 ältere Protokollprobleme behebt und nichts mit den jüngsten Verzögerungen beim Abschluss von Ledgern zu tun hat.

Durch die Verschiebung verlängert sich der Zeitraum, bevor die betreffenden Schutzmaßnahmen für Token-Berechtigungen durchsetzbar werden. Außerdem verzögert sie Korrekturen, die die Buchführung und Transaktionsverarbeitung in der sich entwickelnden Kreditinfrastruktur von XRPL verbessern sollen.

Diese Infrastruktur benötigt weiterhin zusätzliche Protokollgenehmigungen, bevor native Kreditdienste starten können.

Ein weiterer Rückgang der Unterstützung durch Validatoren würde den Wartezeitraum für die Änderung erneut zurücksetzen und die Aktivierung möglicherweise über den 4. November hinaus verschieben.