Der XRP Ledger hat am 23. Oktober der Aktivierung eines Pakets von Software-Korrekturen einen Schritt näher gestanden, nachdem er die für die Genehmigung erforderlichen 29 Validator-Stimmen gesichert hat, obwohl sein geplantes Kreditsystem weiterhin unter der Abstimmungsschwelle des Netzwerks bleibt.
Zusammenfassung
- Das neueste Fehlerbehebungspaket des XRP Ledger hat 29 Validator-Stimmen gesichert und damit die Genehmigungsschwelle des Netzwerks erreicht.
- Das Update könnte am 23. Oktober aktiviert werden, wenn die Validatoren ihre Unterstützung während der erforderlichen zweiwöchigen Abstimmungsperiode aufrechterhalten.
- Das geplante Kreditsystem liegt weiterhin 10 Stimmen zurück, während seine unterstützende Vault-Funktion acht weitere benötigt.
- Die Korrekturen betreffen Kreditberechnungen, Vault-Buchhaltung, Token-Handhabung und andere Probleme bei der Transaktionsverarbeitung im gesamten XRPL.
- Der Kreditvorschlag würde festlaufzeitige Kredite ohne Sicherheiten unterstützen, wobei Broker genutzt werden, um die Kreditwürdigkeit der Kreditnehmer offchain zu bewerten.
Laut dem XRPL Dashboard hatte die als fixCleanup3_4_0 bekannte Änderung bis zum 19. Oktober Unterstützung von 29 der 35 Validatoren auf der standardmäßigen vertrauenswürdigen Liste des Netzwerks erhalten. Der Vorschlag durchläuft seine erforderliche zweiwöchige Genehmigungsperiode, wobei die Aktivierung für Freitag prognostiziert wird, falls diese Unterstützung anhält.
Das Update enthält Korrekturen, die Token-Transaktionen, Vault-Buchhaltung, automatisierte Market Maker und kreditbezogene Prozesse betreffen. Seine Aktivierung würde das Kreditsystem im Netzwerk nicht ermöglichen, da die wichtigsten Kredit- und Vault-Vorschläge separate Abstimmungen durchlaufen.
Die Änderung LendingProtocol hatte 19 unterstützende Validatoren, was 10 Stimmen weniger als die erforderlichen 29 bedeutet. SingleAssetVault, das die für Kredite verwendeten Mittel halten würde, hatte 21 Stimmen und benötigte acht weitere.
XRP-Ledger-Fehlerbehebung zielt auf Aktivierung am 23. Oktober ab
Die Änderung fixCleanup3_4_0 erreichte am 9. Oktober die erforderliche Validator-Mehrheit und begann damit eine 14-tägige Periode, während der die Unterstützung über 80 % bleiben muss.
Zum Kontrollpunkt am 19. Oktober hatte der Vorschlag etwa neun Tage dieser Wartezeit absolviert. Das Dashboard prognostizierte den 23. Oktober gegen 09:34 UTC als den Zeitpunkt, an dem die erforderliche Genehmigungsperiode enden würde.
Die tatsächliche Aktivierung könnte kurz danach erfolgen, da der XRP Ledger Änderungsentscheidungen in festgelegten Intervallen verarbeitet, die als Flag-Ledger bekannt sind.
Laut der Änderungsdokumentation des Netzwerks erfolgen diese Prüfungen alle 256 Ledger. Sobald die erforderliche Wartezeit verstrichen ist, zeichnet das Netzwerk die Änderungsentscheidung auf und wendet die aktualisierten Regeln in den nachfolgenden Ledgern an.
In der Momentaufnahme des Dashboards vom 19. Oktober hatte die Korrektur genau 29 Stimmen, sodass keine zusätzlichen unterstützenden Validatoren über das erforderliche Minimum hinaus vorhanden waren. Wenn einer dieser Validatoren seine Unterstützung vor Ablauf der Wartezeit zurückziehen würde, würde der Vorschlag unter die notwendige Mehrheit fallen.
Nach den Regeln des XRPL startet der Verlust dieser Mehrheit die zweiwöchige Genehmigungsperiode neu, sobald ausreichende Unterstützung wiederhergestellt ist. Der Aktivierungszeitpunkt am 23. Oktober ist daher eine Prognose und keine Bestätigung, dass das Update bereits wirksam geworden ist.
Serverbetreiber müssen Software ausführen, die genehmigte Änderungen erkennt. Laut der XRPL-Dokumentation können Server, die ältere Versionen ohne den erforderlichen Code verwenden, blockiert für Änderungen werden, sobald das Netzwerk beginnt, neue Regeln durchzusetzen.
XRPL-Entwickler veröffentlichten am 16. September Version 3.4.0 der xrpld-Serversoftware und empfahlen den Betreibern ein Upgrade, um die Kompatibilität aufrechtzuerhalten.
XRP-Ledger-Kreditsystem bleibt 10 Stimmen von der Genehmigung entfernt
Obwohl Teile der ausstehenden Korrektur mit Krediten zusammenhängen, hat der Kreditdienst des Netzwerks nicht genügend Validator-Unterstützung erhalten, um aktiviert zu werden.
Der LendingProtocol-Vorschlag, bekannt als XLS-66, erhielt im Snapshot vom 19. Oktober 19 der 35 Stimmen vertrauenswürdiger Validatoren. Der begleitende SingleAssetVault-Vorschlag, XLS-65, erhielt 21 Stimmen. Beide benötigen mindestens 29 Validatoren, die sie zwei aufeinanderfolgende Wochen lang unterstützen, bevor sie in Kraft treten.
Die Vorschläge müssen aktiviert werden, bevor das geplante Kreditsystem auf dem XRP Ledger Mainnet betrieben werden kann. Selbst wenn beide sofort die erforderliche Stimmenzahl erreichen würden, bedeutet die Zwei-Wochen-Wartefrist, dass sie nicht zusammen mit dem Fehlerbehebungspaket vom 23. Oktober aktiviert werden könnten.
Eine separate Änderung, LendingProtocolV1_1, erhielt 19 unterstützende Stimmen. Sie wurde in Version 3.4.0 eingeführt und schlägt Änderungen am Design von Kredit-Vaults und an der Bilanzierung von Kreditzinsen vor.
Die zusätzliche Änderung würde von neu erstellten Kredit-Brokern verlangen, geschlossene Vaults zu verwenden, bei denen Einzahlungen, Kreditvergabe und Abhebungen definierten Phasen folgen.
Der Vorschlag unterteilt diesen Prozess in Zeichnungs-, Investitions- und Rückzahlungsphasen.
Er würde die Zinsbilanzierung dahingehend ändern, dass Erträge erst erfasst werden, wenn Kreditnehmer tatsächlich Zahlungen leisten, anstatt alle geplanten Zinsen bei Kreditbeginn zu verbuchen.
Diese vorgeschlagenen Änderungen bleiben der Genehmigung durch die Validatoren unterworfen.
Im September berichtete crypto.news über die Softwareveröffentlichung und ihre beiden neuen Änderungen und merkte an, dass die Veröffentlichung funktionierenden Codes allein die neuen Kreditregeln nicht aktivierte.
Die neueste Validator-Zählung zeigt, dass das gebündelte Wartungsupdate schneller voranschreitet als die Finanzfunktionen, die es teilweise unterstützt.
Kreditdesign setzt auf Broker für Kreditnehmerprüfungen
Unter dem vorgeschlagenen XRPL-Kreditsystem würden Einleger Vermögenswerte in einen gemeinsamen Vault einzahlen, und ein Kredit-Broker würde unter Verwendung dieser gepoolten Mittel befristete Kredite arrangieren.
Das Ledger würde Kreditverpflichtungen, Rückzahlungen und andere damit verbundene Transaktionen aufzeichnen.
Kreditnehmer müssten keine Sicherheiten direkt über das Protokoll bereitstellen.
Stattdessen würden Kredit-Broker die finanzielle Lage und die Rückzahlungsfähigkeit der Kreditnehmer anhand von Prüfungen bewerten, die außerhalb der Blockchain durchgeführt werden. Diese Regelung würde den Brokern die Verantwortung dafür übertragen, zu entscheiden, welche Kreditnehmer qualifiziert sind und welche Kreditkonditionen sie erhalten.
Das veröffentlichte Design enthält einen optionalen Schutzmechanismus namens First-Loss-Kapital. Ein Broker könnte zusätzliche Vermögenswerte auf ein separates Konto einzahlen, um Verluste abzudecken, wenn Kreditnehmer ihre Kredite nicht zurückzahlen.
Der Schutz würde von dem bereitgestellten Betrag abhängen. Er würde nicht garantieren, dass Einleger nach einem Ausfall alle ihre Mittel zurückerhalten könnten. Die XRPL-Dokumentation erklärt, dass das Protokoll derzeit keine automatische On-Chain-Verwaltung von Sicherheiten oder Liquidation bietet.
Kredit-Broker hätten die Möglichkeit, einen Kredit als ausgefallen zu erklären, nachdem ein Kreditnehmer eine Zahlung versäumt hat und die entsprechende Nachfrist abgelaufen ist.
Das Protokoll soll institutionelle Kreditaktivitäten mit XRP und anderen auf dem Ledger ausgegebenen geeigneten Vermögenswerten unterstützen. Ripple hat die Entwicklung der Kreditvorschläge im Rahmen seiner Arbeit mit Finanzinstituten unterstützt.
Im August unterstützte Ripple beide Änderungen über seinen Validator, während sie unter der Aktivierungsschwelle blieben.
Ein separates Sicherheits-Re-Audit der Kreditvergabe im Juni meldete keine kritischen oder hochriskanten Befunde in den vom Cybersicherheitsunternehmen Halborn geprüften Änderungen.
Das Fehlen kritischer Befunde in dieser Prüfung bedeutete keine Netzwerkgenehmigung oder eine Garantie gegen zukünftige Softwareprobleme.
Neuestes Softwareupdate behebt Vault- und Transaktionsfehler
Die Versionshinweise zu xrpld 3.4.0 vom 16. September beschreiben mehrere Korrekturen, die in fixCleanup3_4_0 enthalten sind.
Eine Korrektur verhindert, dass bestimmte Wiederherstellungstransaktionen von automatisierten Market Makern die Liquiditätsanbieter-Token eines Nutzers zerstören, wenn eine Rundung dazu führen würde, dass keine zugrunde liegenden Vermögenswerte wiederhergestellt werden.
Weitere Änderungen betreffen Berechnungen, die verwendet werden, wenn Personen Gelder in Vaults einzahlen oder daraus abheben. Die Korrekturen sollen sicherstellen, dass die Vermögenssalden der Vaults und die Anzahl der an Einzahler ausgegebenen Anteile während Transaktionen konsistent bleiben.
Für die Kreditvergabe haben Entwickler Regeln aktualisiert, die Autorisierung, eingefrorene Vermögenswerte, Berechtigungsnachweise und Zahlungsziele abdecken. Die Versionshinweise geben Änderungen an, die betreffen, wie Kreditausfälle mit dem Einfrieren von Vermögenswerten interagieren und wie das Protokoll Abhebungen aus berechtigungsbeschränkten Vaults prüft.
Separate Anpassungen betreffen berechtigungsbeschränkte Transaktionen auf dezentralen Börsen, NFT-Angebote und die Treuhandabwicklung. Eine signaturbezogene Korrektur führt unterschiedliche kryptografische Präfixe für verschiedene Signaturrollen ein. Die Änderung verhindert, dass eine für eine Rolle bestimmte Signatur in einer anderen wiederverwendet wird.
Die Version verschärft außerdem Beschränkungen für bestimmte Token-Transaktionen und setzt Prüfungen durch, die zuvor nur in Software-Protokollen aufgezeichnet wurden. Diese Korrekturen sind in der Softwareversion enthalten, erfordern jedoch die entsprechende Änderung zur Aktivierung, bevor ihre neuen Transaktionsregeln im Mainnet durchsetzbar werden.
Die Version 3.4.0 ändert zusätzlich die Art und Weise, wie kompatible Server-Pakete verteilt werden, wobei signierte Linux-Installationspakete über die XRPL Foundation bereitgestellt werden.
Die Versionsmitteilung der Foundation weist Betreiber an, ihre Server auf Version 3.4.0 zu aktualisieren, um den Dienst aufrechtzuerhalten, während das Netzwerk die neuen Änderungen übernimmt.
