Radix (XRD) – DeFi-Engine mit Cerberus und Scrypto

Viele Smart-Contract-Plattformen stoßen im DeFi-Alltag an ähnliche Grenzen: Je mehr Nutzer gleichzeitig handeln, desto stärker müssen Transaktionen in eine Reihenfolge gezwungen werden. Das bremst Durchsatz (wie viele Transaktionen pro Zeit) oder erhöht Komplexität beim Entwickeln. Radix versucht, genau diese Reibungspunkte mit einer auf DeFi zugeschnittenen Architektur zu adressieren: Ein Ledger, das „Ressourcen“ (Tokens/Assets) nativ abbildet, eine Ausführungsumgebung, die Zustände sauber kapselt, und ein Konsensdesign, das parallele Ausführung gezielt erlaubt.

Wofür Radix konzipiert ist: DeFi ohne globale Engpässe

Radix positioniert sich als Layer-1 für DeFi, bei dem zwei Ziele im Vordergrund stehen: parallele Verarbeitung ohne ständiges „Alles-gegen-Alles“-Serialisieren und eine Entwickleroberfläche, die typische Smart-Contract-Fallen reduziert. Der Fokus liegt weniger auf „beliebigen Apps“, sondern auf Finanzlogik wie Pools, Lending, Derivaten und Asset-Transfers.

Warum klassische Account-Modelle bei DeFi oft serialisieren

In vielen Blockchains teilen sich zahlreiche Transaktionen denselben globalen Zustand: Kontostände, Nonces, zentrale Contracts. Sobald mehrere Transaktionen auf dieselben Daten zeigen, müssen Validatoren eine eindeutige Reihenfolge festlegen. Das ist korrekt, aber es verhindert Parallelität: Wenn zwei Swaps denselben Pool betreffen, konkurrieren sie um denselben State-Teil.

Radix versucht, State-Konflikte feingranularer zu definieren. Entscheidend ist dabei, dass ein DeFi-System nicht zwingend „ein großer Zustand“ sein muss, sondern aus vielen voneinander abgrenzbaren Teilen besteht (z. B. einzelne Pools, Vaults, Komponenten).

Eine andere Basiseinheit: Ressourcen statt nur Bytes

Radix behandelt Assets nicht nur als Zahlen in einer Map, sondern als „Ressourcen“, die sich wie echte, nicht kopierbare Dinge verhalten können. Dieses Modell beeinflusst sowohl die Sicherheit (was darf überhaupt dupliziert werden?) als auch die Ausführung (welcher State-Teil wird berührt?). Im Zentrum stehen dabei native Ressourcen und Container wie Vaults, die Besitz und Zugriff explizit machen.

Wie das Ledger Zustände schneidet: Shards, Substates und Abhängigkeiten

Damit Parallelität funktioniert, muss klar sein, welche Teile des Ledgers eine Transaktion liest oder schreibt. Radix nutzt dafür ein Substate-Konzept: Zustand wird in kleinere Einheiten zerlegt, die präziser gelockt (gesperrt) werden können als ein kompletter Smart Contract.

Substates als präzise „Lock“-Einheiten

Ein Substate ist ein adressierbarer Zustandsteil, etwa ein bestimmter Vault-Inhalt oder eine Komponenteneigenschaft. Wenn eine Transaktion nur diesen Substate ändern muss, blockiert sie nicht automatisch andere, unabhängige Substates. So kann ein Swap in Pool A parallel zu einem Deposit in Pool B laufen, solange keine gemeinsamen Substates betroffen sind.

Deterministische Abhängigkeiten statt „Best Effort“-Parallelität

Parallel ausführen ist in Blockchains nur dann sinnvoll, wenn das Ergebnis deterministisch bleibt (alle Knoten kommen zum selben Resultat). Radix erreicht das, indem Transaktionen ihre betroffenen Substates präzise identifizieren und damit Konflikte formal beschreibbar werden. Konflikte werden dann nicht „wegoptimiert“, sondern sauber erkannt und seriell abgearbeitet – nur eben auf möglichst kleiner Fläche.

Cerberus-Konsens: Parallelität über viele Konsensgruppen

Der Konsensmechanismus von Radix ist darauf ausgelegt, nicht immer das gesamte Netzwerk in jeden einzelnen Konsensschritt zu zwingen. Stattdessen wird Konsens dort gebildet, wo er benötigt wird: bei den Shards/Substates, die eine Transaktion tatsächlich berührt. Die zugrundeliegende Idee wird oft unter dem Begriff Cerberus-Konsens zusammengefasst.

Welche Aufgabe Konsens hier erfüllt

Konsens sorgt dafür, dass alle Validatoren dieselbe Reihenfolge und Gültigkeit relevanter Zustandsänderungen akzeptieren. In einem sharded Setting bedeutet das: Nicht jede Transaktion muss von „allen“ finalisiert werden, sondern von den Gruppen, die für die betroffenen Substates zuständig sind. Das kann Parallelität erhöhen, wenn viele Transaktionen voneinander unabhängig sind.

Was bei Cross-Shard-Transaktionen schwierig ist

DeFi braucht häufig atomare Abläufe (alles oder nichts): Ein Swap darf nicht „halb“ passieren. Wenn mehrere Shards betroffen sind, muss die Plattform sicherstellen, dass entweder alle beteiligten Zustände committen oder keiner. Technisch sind hierfür koordinierte Commit-Protokolle nötig, die unter Netzwerkausfällen sauber bleiben. Der Anspruch von Radix ist, Atomizität auch bei shard-übergreifenden Aktionen zu erhalten, ohne den Normalfall zu verlangsamen.

Ausführungsschicht: Die Radix Engine als DeFi-Laufzeit

Bei Radix liegt viel Logik nicht nur „im Code“, sondern im Systemmodell: Assets, Berechtigungen und Komponenten sind zentrale Bausteine. Die Ausführungsschicht organisiert, wie Transaktionen Ressourcen bewegen und wie Komponenten dabei interagieren. Das wird häufig als Radix Engine beschrieben.

Komponenten, Vaults und Buckets: Bauteile für Finanzlogik

Statt alles als frei formbare Datenstruktur zu modellieren, verwendet Radix primitive Konzepte:

• Komponenten: Zustandsbehaftete Module, vergleichbar mit Contract-Instanzen, aber mit stärker strukturiertem Zugriff.

• Vaults: Speicherorte für Ressourcen unter Kontrolle einer Komponente (z. B. Pool-Reserven).

• Buckets: Temporäre Container, um Ressourcen innerhalb einer Transaktion zu bewegen (z. B. Input/Output eines Swaps).

Für DeFi ist das praktisch, weil typische Muster (Einzahlen, Auszahlen, Gebühren, LP-Anteile) direkt über Ressourcenflüsse abbildbar werden. Gleichzeitig wird es schwieriger, unabsichtlich „Geld aus dem Nichts“ zu erzeugen, weil nicht-fungible und fungible Ressourcen systemseitig als nicht kopierbar definiert werden können.

Autorisierung als Kernproblem: Rollen und Proofs

Viele Sicherheitslücken entstehen nicht durch komplizierte Kryptografie, sondern durch falsche Rechte: Wer darf minten, wer darf Parameter ändern, wer darf Liquidität abziehen? Radix setzt hier auf ein modelliertes Berechtigungssystem: Transaktionen können „Proofs“ (Nachweise) über Besitz oder Rollen vorlegen, um bestimmte Methoden aufzurufen. So wird Zugriffskontrolle weniger zu „selbstgestricktem Code“ und mehr zu deklarativen Regeln.

Scrypto: Smart Contracts mit Fokus auf Ressourcen-Sicherheit

Radix bringt mit Scrypto eine auf Ressourcen ausgerichtete Smart-Contract-Entwicklung. Ziel ist, häufige Fehlerklassen zu reduzieren, etwa fehlerhafte Token-Buchhaltung oder unerwartete Reentrancy-Pfade (wiederholter Eintritt in eine Funktion durch externe Aufrufe). Zentral ist das Zusammenspiel aus Sprache, Laufzeit und dem Ressourcenmodell. Im Kontext von Radix gilt Scrypto als das Entwickler-Interface zur Engine.

Warum „resource-oriented“ in der Praxis hilft

Ein alltagsnahes Beispiel: Ein Swap nimmt Token A an, berechnet die Ausgabe in Token B und überträgt Token B an den Nutzer. In klassischen Modellen ist das oft ein Mix aus Kontoständen und internen Buchungen. Bei Radix wird dieser Ablauf als Bewegung von Ressourcen-Containern gedacht: Ein Bucket mit Token A wird in die Komponente gegeben, die Komponente gibt einen Bucket mit Token B zurück. Das reduziert die Zahl impliziter Annahmen, weil Ressourcen explizit übergeben und zurückgegeben werden.

Composability ohne „Zustands-Salat“

DeFi lebt von Komposition: Ein Nutzer will in einer Transaktion swappen, collateral hinterlegen und einen Kredit ziehen. Damit das sicher ist, müssen Zwischenschritte sauber modelliert sein. Radix setzt darauf, dass Ressourcenflüsse über Buckets/Vaults nachvollziehbar bleiben. Komposition wird dadurch nicht „automatisch sicher“, aber typische Fehler wie versehentlich falsche Token-Instanzen oder vergessene Rückübertragungen lassen sich strukturell besser verhindern.

Transaktionsablauf: Von Manifest bis Finalität

Um den Stack greifbar zu machen, hilft ein Blick auf den Ablauf einer Transaktion. Radix verwendet ein Transaktionsformat, das Schritte und Ressourcenbewegungen explizit beschreibt. Dieses Konzept wird häufig als Transaction Manifest bezeichnet.

Schrittfolge als lesbares „Rezept“

Ein Manifest beschreibt, welche Komponenten aufgerufen werden, welche Ressourcen aus dem Wallet bereitgestellt werden und welche Outputs erwartet sind. Für Wallets und Tools ist das hilfreich: Der Nutzer sieht eher, „was passieren soll“ (z. B. „10 Token A gehen in Pool X, mindestens 9.8 Token B kommen zurück“), statt nur einen undurchsichtigen Contract-Call zu signieren.

Konflikte, Locks und Commit

Beim Einreichen einer Transaktion werden die betroffenen Substates identifiziert und gelockt. Wenn es keine Konflikte gibt, können andere Transaktionen parallel laufen. Bei Konflikten entscheidet die Reihenfolge der Finalisierung. Das Ziel ist: so viel Parallelität wie möglich, ohne Atomizität oder Determinismus zu verlieren.

Einordnung im Ökosystem: Abgrenzung und typische Grenzen

Radix adressiert vor allem zwei Problemklassen: Skalierung über Parallelität und Sicherheit durch ein ressourcenorientiertes Modell. Trotzdem bleiben technische Trade-offs.

Wann der Ansatz besonders gut passt

• Viele unabhängige DeFi-Interaktionen gleichzeitig (z. B. viele Pools/Markets), bei denen sich State selten überschneidet.

• Apps, die stark von korrekter Asset-Logik abhängen und von systemseitigen Ressourcen-Primitive profitieren.

• Workflows, bei denen Wallet-Transparenz wichtig ist, weil das Manifest die Absicht besser ausdrücken kann.

Wo Komplexität trotzdem bleibt

Parallele Ausführung löst nicht alle Engpässe. Wenn viele Nutzer auf denselben Hotspot zugreifen (z. B. ein einzelner dominanter Pool), entsteht weiterhin Konkurrenz um die gleichen Substates. Außerdem muss der Tooling-Stack (Wallets, Explorer, SDKs) das Ressourcenmodell korrekt darstellen, sonst entstehen neue UX-Risiken.

Praktische Schritte für die technische Bewertung eines Radix-dApps

Wer ein Radix-Projekt einschätzen will, kann mit wenigen, sehr technischen Prüfpunkten starten. Entscheidend ist weniger „wie komplex der Code ist“, sondern ob Ressourcenflüsse, Rechte und Zustandsgrenzen sauber modelliert sind.

• Transaktionsabsicht prüfen: Zeigt das Manifest klar, welche Ressourcen rein- und rausgehen und ob Slippage-Grenzen (Mindestoutput) gesetzt sind?

• Rollenmodell ansehen: Gibt es administrative Methoden, und sind sie über Rollen/Proofs streng begrenzt (z. B. Parameter-Updates, Mint/Burn)?

• State-Hotspots identifizieren: Berührt die Hauptfunktion nur wenige Substates (Hotspot-Risiko) oder ist der Zustand über mehrere Komponenten verteilt?

• Ressourcen-Typen kontrollieren: Wird eindeutig zwischen fungiblem Token, NFT und spezialisierten Ressourcen unterschieden (z. B. LP-Positionen als eigene Resource)?

Verwandte Bausteine im Web3-Stack: Oracles und L2-Designs

DeFi funktioniert selten isoliert. Preisfeeds und Dateninputs kommen häufig über Oracles; Skalierungsdiskussionen werden oft über Rollups geführt. Für den Kontext lohnt eine Einordnung in angrenzende Architekturthemen: Oracles (Datenintegrität und Liveness) und L2-Konzepte (Ausführung vs. Datenverfügbarkeit). Dazu passen vertiefende Artikel wie Pyth Network im Pull-Oracle-Design, Chainlink und Datenfeeds/Interoperabilität sowie zkSync Era als Beispiel für ZK-Rollup-Architektur.