Die XRP-Ledger-Entwickler haben am 16. September xrpld Version 3.4.0 veröffentlicht und damit zwei Amendment-Pakete hinzugefügt, die vorgeschlagene native Lending-Funktionen überarbeiten und mehrere Transaktionspfade härten, während Serverbetreiber zum Upgrade aufgefordert werden.
Zusammenfassung
- XRPL Version 3.4.0 führt zwei Amendments ein, die Lending-Änderungen sowie ein gebündeltes Protokoll-Fix-Paket abdecken.
- LendingProtocolV1_1 fügt geschlossene Vaults und Cash-Basis-Rechnungslegung hinzu, aber die Mainnet-Aktivierung erfordert weiterhin anhaltenden Validator-Konsens.
- Serverbetreiber werden zur schnellen Aktualisierung aufgefordert, da die XRPL Foundation nun signierte Linux-Pakete verteilt.
- fixCleanup3_4_0 härtet Vaults, AMMs, MPTs, Escrow, Signierung, Credentials und permissioned Trading-Verhalten über Transaktionspfade hinweg.
- Das neue Lending-Amendment hängt von XLS-65 und XLS-66 ab, die weiterhin unter den Aktivierungsschwellen liegen.
Die offizielle Veröffentlichung von XRPL besagt, dass Version 3.4.0 LendingProtocolV1_1 und fixCleanup3_4_0 einführt, während fixAMMOverflowOffer außer Dienst gestellt wird, nachdem sein Verhalten nach dem Amendment dauerhaft Teil des Protokolls geworden ist.
Die Softwareveröffentlichung bedeutet nicht, dass eines der neuen Amendments im Mainnet aktiv ist. Der Amendment-Prozess von XRPL erfordert, dass ein Vorschlag kontinuierlich zwei Wochen lang mehr als 80 % Unterstützung von vertrauenswürdigen Validatoren erhält, bevor seine Regeln aktiv werden.
Lending V1.1 fügt geschlossene Vaults und Cash-Rechnungslegung hinzu
Die 3.4.0-Veröffentlichung von XRPL besagt, dass LendingProtocolV1_1 das Design von Single Asset Vaults und des Lending Protocol ändert, indem geschlossene Vaults mit definierten Zeichnungs-, Investitions- und Rückzahlungszeiträumen eingeführt werden.
Die technische Dokumentation von Ripple besagt, dass Einzahler während der Zeichnungsphase Vermögenswerte hinzufügen oder abheben können. Während der Investitionsphase werden Einzahlungen und Abhebungen gestoppt, während Vermögenswerte Kredite finanzieren können. Die Rückzahlung beginnt, sobald die Investitionsphase endet, sodass Einzahler ihren Anteil nach Fälligkeit der Kredite zurückerhalten können.
Sobald LendingProtocolV1_1 aktiv wird, besagt die Dokumentation von XRPL, dass neue Kreditvermittler nur an geschlossene Vaults angehängt werden können. Bestehende Kreditbeziehungen, die unter früheren Regeln entstanden sind, werden gesondert behandelt, damit ausstehende Positionen weiter verwaltet werden können.
Das Rechnungslegungsmodell ändert sich gleichzeitig. Die Dokumentation von Ripple besagt, dass neue Vaults Zinsen erst dann erfassen, wenn Kreditnehmer tatsächlich Zahlungen leisten.
Unter dem früheren Modell wurden alle geplanten Zinsen bei der Kreditvergabe erfasst. Die Cash-Basis-Rechnungslegung lässt unbezahlte zukünftige Zinsen bis zum Zahlungseingang außerhalb der Vault-Einnahmen, was AssetsTotal, Kreditschuldenberechnungen und die buchhalterische Behandlung von Zahlungsausfällen beeinflusst.
Die V1.1-Regeln würden ältere Vaults nicht rückwirkend umstellen. Die Dokumentation von Ripple besagt, dass Vaults, die unter der vorherigen Rechnungslegungsmethode erstellt wurden, dieses Modell nach der Aktivierung von V1.1 beibehalten.
Wie in der früheren Berichterstattung zu Amendments berichtet, hatte der Validator von Ripple bereits im August für die zugrunde liegenden Vorschläge SingleAssetVault und LendingProtocol gestimmt, aber die Validator-Zustimmung blieb deutlich unter dem für die Mainnet-Aktivierung erforderlichen Niveau.
XRPL 3.4.0 bündelt eine große Anzahl von Transaktionskorrekturen
Die zweite Änderung, fixCleanup3_4_0, enthält Korrekturen für Kredite, Vaults, Automated Market Maker, Multi-Purpose Tokens, NFTs, Escrow, permissionierten Handel und Kontenautorisierung.
Die offizielle Veröffentlichung besagt, dass eine Änderung verhindert, dass AMMClawback die Liquiditätsanbieter-Token eines Inhabers verbrennt, während null zugrunde liegende Vermögenswerte zurückgewonnen werden, wenn die MPT-Rundung den berechneten Rückgewinnungsbetrag auf null reduziert.
Eine weitere Korrektur stärkt die MPT-Invarianten. XRPL-Entwickler sagten, dass die Prüfungen ValidMPTBalanceChanges und ValidMPTTransfer, die zuvor Protokolle generierten, im Rahmen der Änderung durchgesetzt werden und weiterhin gelten, wenn Transaktionen fehlschlagen.
Für Single Asset Vaults listet die Veröffentlichung Präzisions- und Rundungsänderungen bei Einzahlungen, Auszahlungen und Rückforderungen auf. Die Regeln sollen sicherstellen, dass aufgezeichnete Vermögenswerte, verfügbare Vermögenswerte und ausstehendes Anteilsangebot übereinstimmen, wenn Konvertierungen Präzisionsgrenzen erreichen.
Der permissionierte Handel erhält mehrere Korrekturen. Das Paket schließt gelöschte Domain-Angebote von einer Permissioned DEX-Invariante aus, verschärft Domain-Prüfungen und korrigiert, wie abgelaufene Anmeldeinformationen entfernt werden, wenn OfferCreate- oder Payment-Transaktionen ausgeführt werden.
Das Signierungsverhalten erhält eine separate Absicherung. Die Veröffentlichung besagt, dass Version 3.4.0 unterschiedliche Signierungs-Hash-Präfixe für Gegenpartei- und Sponsor-Signaturen zuweist, sodass eine für eine Rolle erstellte Signatur nicht als die andere wiedergegeben werden kann.
Die Veröffentlichung enthält eine tiefergehende Knoten-Härtung außerhalb des Änderungspakets. Entwickler behoben einen unbegrenzten Datenbankzugriff über TMGetLedger, begrenzten die Größe eingehender TMTransactions-Listen und führten eine Gebühr für Transaktionen ein, die nicht deserialisiert werden können.
XRPL-Entwickler sagten, dass Version 3.4.0 Phase-Eins-Korrekturen enthält, die sich aus MPT- und DEX-Audit- und Attackathon-Ergebnissen ergeben. Die Veröffentlichung identifiziert diese Korrekturen nicht als Beweis für einen aktiven Exploit im Mainnet.
In früheren Upgrade-Berichten hatte Version 3.3.0 bereits Code für mehrere separate Vorschläge eingeführt, darunter korrigierte Batch-Funktionalität, gesponserte Gebühren und vertrauliche MPT-Transfers, wobei vor der Aktivierung noch die Genehmigung durch Validatoren erforderlich ist.
Die Validator-Genehmigung trennt weiterhin die Veröffentlichung von der Aktivierung
Die offiziellen Änderungs-Regeln von XRPL besagen, dass die Installation von Software, die eine Änderung enthält, einem Server nur den Code gibt, der benötigt wird, um die vorgeschlagenen Regeln zu verstehen. Validatoren entscheiden separat, ob sie für die Aktivierung stimmen.
Der aktuelle XRPLF-Feature-Code listet sowohl LendingProtocolV1_1 als auch fixCleanup3_4_0 als unterstützt auf, während das DefaultNo-Abstimmungsverhalten beibehalten wird. Eine Default-No-Einstellung bedeutet, dass das Ausführen der Software selbst keine zustimmende Änderungsstimme abgibt, wenn ein Betreiber keine andere Wahl konfiguriert hat.
Die zugrunde liegenden Kreditkomponenten sind noch nicht aktiviert. Ein Schnappschuss vom 17. September basierend auf Validator-Verlaufsdaten der XRPL Foundation zeigte, dass 16 von 35 vertrauenswürdigen Validatoren SingleAssetVault unterstützen und 13 von 35 LendingProtocol unterstützen.
Diese Zahlen sind zeitkritisch und stammen von einem unabhängigen Netzwerk-Tracker, nicht von einer festen Zahl, die in den Versionshinweisen veröffentlicht wurde. Die offizielle Regel bleibt mehr als 80 % Unterstützung, die zwei aufeinanderfolgende Wochen aufrechterhalten wird.
Die neue V1.1-Änderung hängt von der zugrunde liegenden Kreditarchitektur ab. Die aktuelle XLS-66-Spezifikation beschreibt festlaufzeitige, unbesicherte Kredite unter Verwendung von Mitteln, die über Single Asset Vaults gepoolt werden, während die Kreditwürdigkeitsprüfung und Risikobewertung des Kreditnehmers off-chain bleiben.
Dieselbe Spezifikation bleibt als Entwurf klassifiziert. Keine für dieses Update überprüfte Quelle zeigte ein Mainnet-Darlehen, das über das vorgeschlagene native Protokoll ausgeführt wurde, oder ein Aktivierungsdatum für LendingProtocolV1_1.
Knotenbetreiber erhalten jetzt Pakete von der XRPL Foundation
Version 3.4.0 ändert den Vertriebsweg für Linux-Serverpakete. Die offizielle Veröffentlichung besagt, dass Debian- und RPM-Pakete jetzt über packages.xrplf.org gehostet und mit einem Schlüssel der XRPL Foundation signiert werden.
XRPL-Entwickler forderten Serverbetreiber auf, 3.4.0 „so schnell wie möglich“ zu installieren, um die Dienstkontinuität aufrechtzuerhalten. Die veröffentlichten DEB- und RPM-Dateien enthalten SHA-256-Prüfsummen, damit Betreiber heruntergeladene Pakete vor der Installation überprüfen können.
GitHub listet 3.4.0 jetzt als neueste unveränderliche xrpld-Version, gebunden an Commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17. Das Repository gibt an, dass das Release-Tag und der Versions-Commit verifizierte Signaturen tragen.
Dasselbe Release zieht fixAMMOverflowOffer zurück. Nach dem Amendment-Modell von XRPL wird die Korrektur dadurch nicht rückgängig gemacht. Es entfernt veraltetes Verhalten vor dem Amendment, nachdem die neuen Regeln als dauerhaftes Protokollverhalten etabliert wurden.
Client-Unterstützung und Sicherheitsüberprüfung sind noch in Entwicklung
Anwendungsbibliotheken bewegen sich parallel zum Server-Release. Die Historie des JavaScript-Clients von XRPLF listet die Unterstützung für LendingProtocolV1_1 im nicht veröffentlichten Abschnitt nach xrpl.js 5.2.0 auf, das am 11. September veröffentlicht wurde.
Die Historie des Binary-Codec zeigt, dass Version 2.11.0 bereits die rollenspezifischen Sponsor- und Counterparty-Signaturpräfixe enthält, die von fixCleanup3_4_0 verwendet werden, zusammen mit Protokolldefinitionen, die aus xrpld 3.4.0 generiert wurden.
Die Sicherheitstests der Lending-Arbeit wurden getrennt von der Validator-Abstimmung fortgesetzt. Sherlock sagte in einer Überprüfung vom 27. August, dass Ripple eine ausschließlich KI-basierte Untersuchung des Lending Protocol V1.1 über seine Audit Engine begonnen habe.
Sherlock sagte, es werde nach Abschluss der Überprüfung weitere Informationen veröffentlichen, aber in seinen für diesen Bericht geprüften öffentlichen Materialien wurden keine endgültigen V1.1-Ergebnisse gefunden. Frühere Tests deckten eine frühere Version des Lending-Systems ab; frühere unabhängige Audit-Berichterstattung berichtete, dass Halborns früheres Re-Audit keine kritischen oder hochriskanten Probleme fand, während ein mittleres, zwei niedrige und zwei informative Feststellungen identifiziert wurden.
