Die vorgeschlagene Smart-Escrow-Funktion des XRP Ledger ist in ihrer Testphase vorangeschritten. Am 5. Oktober kündigte Mayukha Vadari, Staff Software Engineer bei RippleX, deren Arbeit sich auf die Programmierbarkeit des XRPL konzentriert, die nachte neunte Smart-Escrow-Devnet-Version an. Laut ihrer Versionsnotiz ist das Testnetz auf eine neue Infrastruktur umgezogen und ersetzt die eingestellten wasm.devnet.rippletest.net-Endpunkte durch wasm-devnet.dev.ripplex.io. Die vorgeschlagene Funktion soll Escrow-Zahlungen auf dem Ledger eingeschränkten, benutzerdefinierten Regeln folgen lassen.

Ein neues Devnet gibt Smart Escrow einen breiteren Test

Die Adressänderung ist nur ein Teil des Updates. Entwickler benötigen eine gemeinsame Umgebung, in der ihre Verträge, Wallets, Bibliotheken und Node-Konfigurationen nach denselben Regeln ausgeführt werden können – eine Arbeit, die besonders wichtig wird, wenn Code darüber entscheidet, ob gesperrte Mittel freigegeben werden dürfen.

Vadari erklärte, das Projekt befinde sich weiterhin in Überprüfung und Testphase, während das Team das Framework und den Code absichere. Das Devnet bietet einen Ort, um Kompatibilitäts- und Sicherheitsprobleme aufzudecken, bevor Smart Escrow für das Live-Netzwerk in Betracht gezogen werden kann.

Smart Escrow ergänzt gesperrte Mittel um eine programmierbare Bedingung

Das XRPL unterstützt bereits Escrow-Zahlungen mit einfachen Freigabebedingungen, eine Fähigkeit, die das Mainnet seit Ende 2017 anbietet. Mittel können nach einer festgelegten Zeit verfügbar werden oder wenn jemand die erforderliche kryptografische Erfüllung bereitstellt. Diese Regeln eignen sich für einf Vereinbarungen, obwohl eine Anwendung möglicherweise einen namentlich benannten Genehmiger, ein verifiziertes Ereignis oder mehrere gemeinsam geprüfte Bedingungen benötigt.

Betrachten wir einen Käufer, der XRP für einen Verkäufer sperrt: Der Escrow wird erst freigegeben, wenn ein namentlich genannter Notar die Lieferung bestätigt, während eine Frist es dem Käufer ermöglicht, die Mittel zurückzuholen, falls diese Bestätigung nie eintrifft. Smart Escrow ist für solche Fälle konzipiert. Ein kleines WebAssembly-Programm würde bei der Erstellung des Escrows hinterlegt und ausgeführt, wenn jemand versucht, ihn abzuschließen. Das Programm bewertet die vereinbarte Regel und bestimmt, ob die Freigabe erfolgen kann.

Vorgeschlagene Änderungen am XRP Ledger werden in öffentlichen XLS-Vorschlägen (XRP Ledger Standard) dokumentiert. Die XLS-0100-Smart-Escrows-Spezifikation listet mögliche Verwendungszwecke auf, von Compliance-Sperren und Meilensteinzahlungen bis hin zu Token-Vesting, Auktionsmechaniken und oraclebasierten Bedingungen. Jeder Anwendungsfall beruht auf derselben Kernidee: Die Regeln zur Freigabe der Mittel werden in den Escrow geschrieben, bevor das Geld gesperrt wird.

Beschränkungen sollen das Netzwerk und die Mittel schützen

Jedes System, das Code rund um eine Zahlung ausführt, braucht klare Grenzen. Jeder XRPL-Validator muss beim Abschluss eines Escrows zum selben Ergebnis kommen; andernfalls könnte sich das Netzwerk nicht auf den Zustand des Ledgers einigen.

Smart-Escrow-Code läuft daher in einer eingeschränkten Umgebung. Er kann nicht frei externe Dienste aufrufen oder auf Dateien zugreifen und unterliegt Grenzen bei Speicher- und Rechenressourcen. Diese Grenzen verhindern, dass ein schlecht geschriebener Vertrag übermäßige Ressourcen verbraucht oder bei Validatoren zu widersprüchlichen Ergebnissen führt, und sie sollen verhindern, dass Mittel eingesperrt bleiben.

Der Vorschlag verlangt außerdem, dass jeder Smart Escrow mit Bytecode eine CancelAfter-Zeit enthält. Nutzer hätten damit einen Weg, gesperrte Mittel zurückzuholen, wenn eine Bedingung nicht erfüllt werden kann, eine Vertragspartei nicht handelt oder der Code einen Fehler enthält.

Ripples Smart-Escrow-Entwicklerbibliothek enthält bereits Beispiele mit Notargenehmigung, Berechtigungsprüfungen, Oracle-Daten und NFT-Eigentum. Diese Beispiele zeigen, welche Arten von Regeln Entwickler testen können, während das Devnet aufzeigt, ob das zugrunde liegende System sie konsistent verarbeitet.

Die neunte Version aktualisiert die Mechanik hinter diesen Regeln

Version neun reorganisiert, wie das Netzwerk Smart-Escrow-Code ausführt. Vadari erklärte, die WebAssembly-Integration sei von C++ auf Rust umgestellt worden, wodurch Gas-Abrechnung, Fehlerbehandlung und Validierungsprüfungen über einen einzigen Einstiegspunkt laufen. Ihre Versionsnotiz schätzt eine 30- bis 50-prozentige Verbesserung bei Host-Funktionsaufrufen – ein technisches Maß, das für Entwickler relevant ist, die Escrow-Logik erstellen und testen.Assembly selbst ist ein in Sandboxen ausgeführtes Codeformat, das weit über das XRP Ledger hinaus verwendet wird – Polkadot, NEAR und mehrere Cosmos-basierte Chains führen Smart Contracts darauf aus – und Rust gehört zu den gängigsten Sprachen dafür.

Auch die Softwarebibliotheken haben sich geändert. Entwickler werden gebeten, sich vom eingestellten All-in-One-Paket zu trennen und stattdessen separate Common- und Escrow-spezifische Bibliotheken zu verwenden, um ihre Anwendungen anschließend gegen das neue Devnet erneut zu testen. Ein lokal kompilierbarer Vertrag muss weiterhin mit dem Netzwerk, seinem Transaktionsformat und den umliegenden Tools funktionieren.

Das ist der praktische Wert dieser Version: Sie gibt Teams eine stabilere Umgebung, um Probleme zu finden, die erst auftreten, wenn mehrere Infrastrukturkomponenten zusammenarbeiten müssen.

Bedingter Escrow könnte automatisierte Zahlungen ergänzen

Kontrollierte Freigaberegeln könnten auch die Arbeit des XRP Ledger an KI-Zahlungen in XRP und RLUSD, Ripples an den Dollar gekoppeltem Stablecoin, ergänzen. Ein Agent kann eine Zahlung vorbereiten, während Smart Escrow die Umstände definieren könnte, unter denen bereits im Escrow hinterlegte Mittel bewegt werden dürfen.

Diese Aufteilung gibt Anwendungen Raum, Routine-Schritte zu automatisieren, ohne die Bedingungen für die Freigabe von Geldern unklar zu lassen. Wallet, Zahlungsanforderung und Escrow erfüllen jeweils unterschiedliche Rollen, wodurch sich leichter nachvollziehen lässt, wo eine Entscheidung getroffen wurde, falls etwas schiefgeht.

Smart Escrow braucht noch einen Weg ins Mainnet

Smart Escrow bleibt ein Entwurfsvorschlag und keine Live-Funktion des XRP Ledger. Eine Live-Version würde eine formale Änderung erfordern – den Mechanismus des Ledgers zur Einführung von Protokolländerungen, bei dem Validatoren Unterstützung signalisieren und Upgrades erst nach breitem Konsens aktiviert werden – sowie weitere Implementierung und Sicherheitsüberprüfungen, gefolgt von einem Aktivierungsprozess im Mainnet.

Der neunte Devnet-Build gibt Entwicklern einen besseren Ort, um die vorgeschlagenen Regeln zu testen. Sein Fortschritt wird anhand erfolgreicher Migrationen, Sicherheitsfunde und der Reaktion der breiteren XRPL-Community gemessen, während sich die Funktion einem möglichen Mainnet-Pfad nähert.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlageberatung dar. Smart Escrow befindet sich in Entwicklung; Spezifikationen, Zeitplan und Weg ins Mainnet können sich ändern.