XRP Ledger

XRP Ledger bietet Finanzfunktionen innerhalb des Protokolls, statt für jede Operation einen Allzweck-Contract zu verlangen. Eine Anwendung kann etablierte Transaktionstypen nutzen, um XRP zu bewegen oder emittierte Vermögenswerte zu verwalten.

Diese Architektur verändert die Implementierungsarbeit: Zuerst wird geprüft, ob die nativen Operationen das Produkt abdecken. Danach werden Konten, Berechtigungen und die buchhalterische Integration entworfen. Der Name eines Vermögenswerts reicht zu seiner Identifizierung nicht aus; bei emittierten Vermögenswerten zählt auch, wer ihn emittiert und welche Bedingungen er festlegt.

Konten senden signierte Transaktionen, die den Zustand des Ledgers verändern. Die Server stellen APIs bereit, um Operationen zu übermitteln und ihr Ergebnis abzufragen; der Konsens bestimmt, welcher Zustand validiert wird. Die Tauschfunktionen und die verschiedenen Zahlungstypen gehören zum Funktionsumfang des Protokolls.

Die Integration muss Sequenznummern, Gebühren, Reserven und Validierungszustände handhaben. Bei emittierten Vermögenswerten ist zudem die Beziehung zwischen Emittent und Inhaber zu prüfen. Ein zuverlässiges Backend gleicht das validierte Ergebnis ab, bevor es eine Buchung oder eine Lieferung abschließt.

Operationen werden durch den Konsens des Ledgers bestätigt; eine Antwort auf die Übermittlung ist kein validiertes Ergebnis. Die Integration muss die Transaktion verfolgen, bis ihre endgültige Aufnahme und ihr Ergebnis bekannt sind, und dabei ihre Gültigkeitsgrenze berücksichtigen. Konten benötigen außerdem Reserven, und bestimmte Ledger-Einträge erhöhen den reservierten Saldo.

XRPL kann für Zahlungs- oder Emissionsprodukte geeignet sein, wenn seine nativen Funktionen die erforderlichen Regeln abdecken. Es erlaubt die Bewertung von Abläufen, die Übertragungen und Rückverfolgbarkeit benötigen, ohne für jede Aktion einen eigenen Contract einzuführen.

Unser Ansatz ist, den Geschäftsprozess auf die verfügbaren Transaktionstypen abzubilden. Passt eine Regel nicht hinein, wird entschieden, ob sie im Backend gelöst werden muss oder eine andere Architektur nötig ist. Vor der Automatisierung von Zahlungen werden außerdem die Schlüsselverwahrung und die Identifizierung des Empfängers definiert.

In einem Ablauf mit emittierten Vermögenswerten bestimmen die Trust Lines und die Optionen des Emittenten, welche Salden ein Konto halten und welche Operationen es ausführen kann. Das Produkt muss diese Bedingungen erklären, bevor es Mittel entgegennimmt. Destination Tags können helfen, Empfänger innerhalb gemeinsam genutzter Dienste zu identifizieren, ersetzen aber weder Identifizierungskontrollen noch Abstimmung. Der Fall einer Überweisung ohne die vom Empfänger geforderte Referenz wird ausdrücklich getestet.

Das Protokoll ersetzt nicht die Pflichten des Emittenten und macht einen Token nicht schon für sich genommen zu einem durchsetzbaren Anspruch. Die digitale Repräsentation muss mit den Bedingungen des Produkts übereinstimmen. Die Auswahl der Validatoren und die Verfügbarkeit der Server sind zudem operative Abhängigkeiten, die bekannt sein müssen.

Eine mit XRPL verbundene EVM-Sidechain hat eigenen Konsens, eigene Vermögenswerte und eigene Infrastruktur. Sie ist nicht damit zu verwechseln, Solidity direkt im Haupt-Ledger auszuführen. Stellar oder ein EVM-Netzwerk können je nach benötigter Programmierbarkeit und den Integrationen der Anwendung Alternativen sein.