Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

WASMVM XLS-102

Der Entwurf definiert die deterministische WebAssembly-Laufzeit, Gasregeln und Host-Funktionen für XRPL-Erweiterungen. Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Netzwerkstatus
Kein Netzwerk-Amendment
XLS
XLS-102
Spec-Status
Draft
Spec-Stand
22.06.2026

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

WASM lässt Implementierungsspielraum bei Laufzeit, Gaszählung und Host-Zugriffen. Ohne eine verbindliche Engine und stabile ABI könnten Nodes denselben Bytecode unterschiedlich bewerten und den Konsens verlieren.

Wie ist der Mechanismus im aktuellen Draft gedacht?

Jede Ausführung erhält eine neue, isolierte WASM-Instanz und ein festes Gasbudget. Instruktionen, Speicheroperationen und Host-Funktionen verbrauchen deterministische Kosten; nur definierte Host-Funktionen dürfen Ledger-Daten lesen oder das Data-Feld des eigenen Hostobjekts ändern. Nicht deterministische Funktionen wie native Fließkommazahlen, Zufall, Systemzeit und Host-I/O bleiben ausgeschlossen.

Wie verbindlich ist das?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
XRPL besitzt keine allgemeine, konsensfähige WASM-Laufzeit mit verbindlicher ABI und Gasbewertung.Smart Escrows und spätere Erweiterungen könnten geprüften Bytecode in einer begrenzten, reproduzierbaren Sandbox ausführen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nutzer erhalten keine neue Transaktion allein durch XLS-102. Sie wären indirekt betroffen, wenn Smart Escrows oder Verträge ihren Code in dieser VM ausführen.

Wallets und App-Entwickler

Entwickler müssen mit einer stabilen Host-ABI, eigener Speicherverwaltung und klaren Puffergrößen arbeiten. Normale Systemfunktionen stehen in der Sandbox nicht zur Verfügung.

Börsen und Emittenten

Institutionen könnten deterministische Compliance- oder Freigabelogik verwenden, müssen Bytecode und Gasbedarf aber vorab prüfen und simulieren.

Node-Betreiber

Validatoren tragen die Ausführungskosten. Die UNL kann Bytecode-, Gas- und Speichergrenzen anpassen oder die Berechnungsgrenze im Fehlerfall auf null setzen.

Welche Grenzen und Risiken bleiben?

  • XLS-102 ist ein Draft und führt selbst weder Transaktion noch Ledger-Objekt noch RPC ein.
  • Der erste Host-Funktionsumfang gilt nur für Smart Escrow.
  • Pro Host-Funktionsaufruf dürfen höchstens 1 MiB die WASM-Grenze passieren und höchstens 1 KiB aus dem Ledger gelesen oder dorthin geschrieben werden.
  • WASM 1.0 bietet keine automatische Speicherbereinigung. Der aufrufende Code muss Speicher selbst reservieren und wiederverwenden.
  • Code kann keine historischen Ledger-Daten lesen, keine Verzeichnisse beliebig durchlaufen und keine rohen Ledger-Objekte direkt verändern.
  • Fließkomma, Zufall, Host-System-I/O und andere nicht deterministische Funktionen sind ausgeschlossen.
  • Die ABI ist nach Aktivierung dauerhaft kompatibel zu halten; neue oder geänderte Host-Funktionen benötigen weitere Amendments.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Gas entsteht durch WASM-Instruktionen, Speicheroperationen und Host-Funktionen. Ein überschrittenes Budget beendet die Ausführung sofort.
  • Bytecodegröße, Berechnungsgrenze und Gaspreis sollen UNL-votierbar sein. XLS-102 nennt dafür noch keine endgültigen globalen Startwerte.
  • Einzelne Host-Funktionen tragen feste Entwurfswerte, etwa 60 Gas für ldgr_index, 5.000 Gas für cache_le und 1.000 Gas für set_data.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • keine neuen Transaktionstypen; Ausführung zunächst über EscrowFinish

Ledger-Objekte

  • Escrow als erstes Hostobjekt
  • FeeSettings für votierbare Limits

Felder und Flags

  • Gas / GasLimit / GasPrice
  • BytecodeSizeLimit
  • lineare WASM-Speicherseiten zu 64 KiB
  • set_data als einzige schreibende Host-Funktion im ersten Umfang

API-Methoden

  • ldgr_index / parent_ldgr_time / parent_ldgr_hash
  • home_le_field / home_le_inner
  • cache_le / le_field / le_inner
  • Transaktions-, Keylet-, NFT- und Trace-Host-Funktionen

Invarianten

  • Dieselben Eingaben müssen auf allen Nodes denselben Gasverbrauch und dasselbe Ergebnis erzeugen.
  • Jede Ausführung startet in einer neuen VM-Instanz ohne wiederverwendeten Speicherzustand.

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Vorschlag weiter?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Der Entwurf muss fachlich reifen und kann sich noch grundlegend ändern oder verworfen werden. Erst ein passendes rippled-Amendment würde eine getrennte Netzwerkabstimmung auslösen.

Wo steht es in seiner Amendment-Familie?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen