Kernpunkte
- Stellar kombiniert native Operationen mit in Rust geschriebenen Soroban-Smart-Contracts.
- On- und Off-Ramps verbinden Überweisungen im Netzwerk mit Geld außerhalb des Netzwerks.
- Vermögenswert, Emittent und Einlösebedingungen müssen getrennt identifiziert werden.
Was ist Stellar?
Stellar bietet eine Grundlage für die Übertragung von Werten und die Emission von Assets, mit nativen Netzwerkfunktionen und Soroban-Contracts für zusätzliche Logik. Eine Anwendung kann eine Zahlungsoperation nutzen oder programmierbare Regeln benötigen, je nachdem, was mit dem Asset geschehen soll.
Die Unterscheidung ist wichtig, um keine unnötige Komplexität hinzuzufügen. Eine einfache Übertragung und ein Produkt mit bedingten Freigaben haben einen unterschiedlichen Umfang. Das Design muss außerdem den Emittenten des Assets und die Beziehung zwischen dessen digitalem Saldo und etwaigen Lieferpflichten außerhalb des Netzwerks identifizieren.
So funktioniert es
Stellar bestätigt Operationen über sein Konsensprotokoll. Transaktionen können native Funktionen enthalten oder Soroban-Contracts aufrufen. Im zweiten Fall wird der Code mit Werkzeugen entwickelt, die für die WebAssembly-Umgebung des Netzwerks kompilieren.
Die SEP-Standards beschreiben Schnittstellen, die von Diensten des Ökosystems genutzt werden, darunter On- und Off-Ramps, die digitale Vermögenswerte mit anderen Zahlungssystemen verbinden. Die Anwendung muss sowohl die On-Chain-Transaktion als auch den externen Status der Ein- oder Auszahlung verfolgen. Diese Prozesse können unabhängig voneinander fehlschlagen oder sich verzögern und erfordern einen Abgleich.
Stellar unterscheidet native Ledger-Operationen von der Ausführung von Soroban-Contracts. Trustlines drücken Beziehungen zu emittierten Assets aus, während Contracts und persistente Daten eigene Ressourcen und einen eigenen Speicherzyklus haben. Ein Design, das beides kombiniert, muss klären, wo jeder Saldo liegt und welche Autorisierung jede Aktion benötigt.
Was Stellar leistet
Stellar kann sich für Anwendungen in den Bereichen Zahlungen, Mittelverteilung und emittierte Assets eignen, wenn Dienste vorhanden sind, die den gesamten Weg des Nutzers abdecken. Soroban erweitert den Einsatzbereich, wenn das Produkt Regeln braucht, die sich nicht in nativen Operationen abbilden lassen.
Bei Metlabs prüfen wir, wer das Geld erhält, welches Asset bewegt wird und wie die Einlösung abgewickelt wird. Danach entscheiden wir zwischen Zahlungsintegration, eigenem Contract oder einer Kombination. Die Entscheidung umfasst Schlüsselkontrolle, Fehlerbehandlung und eine Rückverfolgbarkeit, mit der das Operations-Team Vorfälle klären kann.
Bei Zahlungen, die an einen Ein- oder Auszahlungsanbieter angebunden sind, ist die On-Chain-Übertragung eine Etappe des Ablaufs. Der Bankstatus, die Prüfungen des Anbieters und die Auszahlung an den Empfänger folgen externen Prozessen. Es werden Referenzen aufbewahrt, die den Abgleich beider Seiten und die Bearbeitung von Rückerstattungen ermöglichen. Bei Soroban ist zudem die Gültigkeitsdauer der Daten und gegebenenfalls deren Wiederherstellung zu berücksichtigen, denn die Verfügbarkeit des Zustands gehört zur Wartung der Anwendung.
Grenzen und Auswahlkriterien
Eine auf Stellar bestätigte Übertragung belegt nicht, dass eine Banküberweisung abgeschlossen ist, und garantiert nicht die Verpflichtungen eines Emittenten. On- und Off-Ramps und externe Dienste haben eigene Prozesse, Bedingungen und Verfügbarkeiten. Das Produkt muss diese Abhängigkeiten abbilden.
Soroban bringt Programmierbarkeit, aber auch Tests, Wartung und die Verwaltung des Contract-Speichers mit sich. XRPL kann eine Alternative für native Operationen sein; ein EVM-Netzwerk kann passen, wenn die Abhängigkeiten in Solidity liegen. Der Vergleich muss den gesamten Weg des Geldes umfassen und nicht nur die Netzwerkgebühr.
