Großer Einblick in Stardust

IOTAs Ledger Web3-fähig machen

31. Mai 2022

TL;DR:
Stardust verwandelt IOTA in eine Infrastrukturschicht für smart contracts und führt personalisierte Token ein. Der neue Ledger kann Übertragungen an Bedingungen knüpfen und NFTs können als Wallets fungieren, während zusätzliche Protokollverbesserungen die Ressourcen der Nodes (Knoten) schützen, clientseitige Vertrauensannahmen eliminieren und die Lastausgleichsfähigkeiten des Netzwerks verbessern. Stardust debütiert auf dem neuen Shimmer-Netzwerk, bevor es auf das IOTA-Mainnet portiert wird.

Das IOTA-Protokoll wird nach Chrysalis sein größtes Funktions-Upgrade erhalten: Stardust baut auf dem letztjährigen Chrysalis-Netzwerk-Upgrade auf und bietet einen noch nie dagewesenen Nutzen. In diesem Blogbeitrag erkunden wir die Ursprünge von Stardust und die Vorteile, die es mit sich bringen wird. Wenn Sie eine komprimierte Einführung suchen, lesen Sie den Beitrag Stardust in a nutshell.

Das Chrysalis-Upgrade vom letzten Jahr brachte wesentliche Verbesserungen für die Leistung, Stabilität, Zuverlässigkeit und Sicherheit von IOTA. Gleichzeitig wurden unnötig komplexe und unorthodoxe Konzepte abgeschafft, stattdessen vereinfacht und an Industriestandards und Best Practices angepasst. Das Chrysalis-Protokoll läuft seither stabil im IOTA-Mainnet und die Bemühungen um das Protokoll konzentrieren sich auf Coordicide mit dem Ziel einer vollständigen Dezentralisierung, die derzeit durch die IOTA 2.0 DevNet-Implementierung getestet wird.

Warum brauchen wir dann Stardust als Zwischenschritt zwischen Chrysalis und Coordicide?

Parallel zu unserer Arbeit an Coordicide haben wir das IOTA Smart Contract (ISC) Protokoll auf dem IOTA 2.0 DevNet aufgebaut. Die ISC-Beta wurde im letzten Oktober im DevNet gestartet und das Basisprotokoll erhielt Funktionalitäten, um Smart Contracts angemessen zu unterstützen.

Wir haben in dieser Phase viel gelernt und festgestellt, dass die Bedürfnisse von ISC auf dem aktuellen IOTA-Protokoll durch die Dezentralisierungsbemühungen von Coordicide nicht vollständig abgedeckt werden. Daher ist es ein logischer Schritt, die neuen Protokollfunktionen so schnell wie möglich auf das IOTA-Mainnet zu portieren, damit unsere Community mit der Entwicklung von Smart-Contract-basierten Anwendungsfällen auf dem IOTA-Mainnet beginnen kann. Das Stardust-Upgrade ermöglicht es uns, die Unterstützung von Smart Contracts im Mainnet noch vor Coordicide zu aktivieren.

Stardust wird auf Shimmer, dem Staging-Netzwerk von IOTA, debütieren und wird gründlichen Tests und einer Validierung durch die Community unterzogen. Bis es im IOTA Mainnet auftaucht, wird unsere Community Zeit gehabt haben, das neue Protokoll in- und auswendig zu lernen und Anwendungen und Werkzeuge zu entwickeln. Auf diese Weise können dApps zusammen mit dem neuen Protokoll auf dem IOTA-Mainnet starten.

Wieso Stardust?

Natürlich stellt sich dann die Frage: Warum müssen wir das aktuelle IOTA-Protokoll ändern, um die Ausführung von Smart Contracts darauf zu ermöglichen?

Die Antwort ist einfach. Der von ISC verwendete Second-Layer-Ansatz ermöglicht eine horizontale Skalierung und einen Spitzen-Durchsatz, ist aber auf das IOTA-Basisprotokoll angewiesen, um die vertrauenslose Infrastruktur für die Interoperabilität bereitzustellen.

Das Schlüsselwort ist hier Infrastruktur. Stellen Sie sich den Tangle als Autobahnsystem vor: Er ermöglicht den freien Verkehr von Personen und Gütern zwischen den Staaten, so wie das Stardust-Protokoll den Austausch von digitalen Vermögenswerten und Informationen zwischen Smart-Contract-Chains ermöglicht, wobei jede dieser Chains funktional einer Blockchain wie Ethereum entspricht, die über den IOTA Tangle verbunden sind.

IOTA eignet sich gut als Grundlage für darauf aufbauende Distributed Ledger Technology (DLT)-Netzwerke, denn:

• Die asynchrone Natur des Tangle und des UTXO-Ledger-Modells ermöglicht die parallele Verarbeitung von Transaktionen.
• Die “feeless”-Eigenschaft des Protokolls bewahrt den Wert bei Wertübertragungen zwischen Chains.
• Das UTXO-Modell kann mit spezieller Anwendungslogik für vertrauenslose atomare Operationen erweitert werden.

Derzeit ist der Chrysalis-Ledger für eine einzige Anwendung optimiert: Zahlungen in Kryptowährungen. Stardust zielt darauf ab, dies zu ändern und IOTA in eine Infrastrukturebene für smart Contracts zu verwandeln, während es gleichzeitig zu einem Multi-Asset-Ledger wird. Darüber hinaus werden es die neuen Ausgabetypen in Stardust ermöglichen, beliebige Daten direkt in den Ledger-Status zu schreiben, was bedeutet, dass diese Datensätze nicht nach einiger Zeit von den Mainnet-Knoten gelöscht werden, wie es bei reinen Datennachrichten auf dem Tangle der Fall ist.

Ein anschauliches Beispiel dafür wäre das DID-Dokument, das in IOTA Identity verwendet wird. Bisher war der Anwendungsfall davon abhängig, dass permanente Knoten in der Lage waren, eine bestimmte DID zu Verifizierungszwecken abzurufen. Mit einem DID-Dokument, das im IOTA-Ledger-Status gespeichert ist, wäre es auf jedem einzelnen Mainnet-Knoten verfügbar, solange sein Besitzer bereit ist, sein IOTA-Speicherdepot zu sperren, was weiter unten in diesem Blog-Beitrag genauer beschrieben wird.

Smart Contract Anforderungen

Was braucht eine IOTA-Smart-Contract-Chain, um auf der IOTA-Infrastrukturschicht zu laufen?

1. Ein Ledger-Konto mit einer permanenten Adresse, die von einem rotierenden Komitee kontrolliert wird, um Token zu senden und zu empfangen.
2. Einen Ort zum Speichern von Zustandsverpflichtungen der Schicht 2 (L2) Chain.
3. Benutzerdefinierte Token für chainübergreifende Vermögensübertragungen.
4. Mittel zur Erleichterung der Benutzerinteraktion.

Chrysalis unterstützt keine dieser Funktionen. Das Design des Stardust-Protokolls stellt eine neuartige Lösung für die oben genannten Herausforderungen dar, indem es die Transaktionsvalidierung und die Freigabe von Ausgaben im Layer 1 (L1) Ledger um konfigurierbare Skripte, sogenannte Ausgabetypen, Freigabebedingungen und Ausgabefunktionen erweitert.

Sehen wir uns die Lösungen im Detail an.

Ein neues Ledger-Konto

Ein Ledger-Konto ist in der Regel eine Adresse, die direkt von einem geheimen, privaten Schlüssel abgeleitet ist. Der Eigentümer kann Transaktionen mit dem geheimen Schlüssel unterzeichnen, und jeder kann im Ledger überprüfen, ob die Unterschrift gültig ist oder nicht.

Die Konten der Smart-Contract-Chains werden jedoch von einer Reihe von Validierern kontrolliert, die zusammen eine gemeinsame Schwellenwert-Signaturadresse erzeugen, die nur freigeschaltet werden kann, wenn eine bestimmte Anzahl von Parteien ihre Unterschriften leistet. Jedes Mal, wenn der Validatorensatz geändert wird, muss eine neue gemeinsame Adresse erstellt werden.

Folglich kann das herkömmliche Adressenkonzept keine dauerhafte Adresse für Smart-Contract-Chainkonten bereitstellen. Stattdessen ist eine neue Denkweise in Bezug auf Ledger-Konten erforderlich:

Wie wäre es, wenn wir auf Protokollebene eindeutige Adressen generieren und verfolgen könnten, die die für die Unterzeichnung von Transaktionen verwendeten privaten Schlüssel austauschen können?

Damit dies funktioniert, müssen wir herausfinden, wie wir:

• Eindeutige Adressen deterministisch generieren,
• ihren Zustand und die Kontrollschlüssel über Transaktionen hinweg erhalten.

Die erste Herausforderung ist die einfachste. Jede Transaktion im Ledger ist eindeutig, daher könnten wir eine eindeutige Adresse aus dem Inhalt der Transaktion ableiten, die sie erzeugt. Check.

Die zweite Herausforderung erfordert eine Änderung der Transaktionsvalidierungsregeln des Ledgers, um die Definition zusätzlicher Beschränkungen im Zusammenhang mit Transaktionen zu ermöglichen. Außerdem ist eine neue Datenstruktur erforderlich, um die eindeutige Adresse und die Informationen über den Eigentümer der Adresse zu speichern. Zusammenfassend lässt sich sagen, dass wir einen neuen Ausgabetyp entwerfen müssen, der Daten enthält und, wenn er in Transaktionen eingebunden ist, eine zusätzliche Validierungslogik ausführt.

Die Alias-Ausgabe implementiert diese Datenstruktur und führt die Alias-Adresse als ein Ledger-Konto ein. Wenn ein Alias-Output zum ersten Mal im Ledger angelegt wird, generiert das Protokoll eine eindeutige Adresse, die im Output selbst gespeichert wird, zusammen mit den mit privaten Schlüsseln gesicherten Adressen, die ihn derzeit kontrollieren. Diese Kontrolleure des Alias-Kontos können die Ausgabe in Transaktionen einbeziehen, um sie gemäß den in ihrem konfigurierbaren Validierungsskript festgelegten Regeln zu ändern.

Im Moment reicht es aus, zu wissen, dass die Validierung dies gewährleistet:

• Der Alias-Output selbst ist auf der Ausgabeseite der Transaktion vorhanden. Sein Zustand wird persistiert.
• Controller-Rollen können auf jede andere Adresse im Ledger übertragen werden.
• Alle unter der permanenten Alias-Adresse gesperrten Mittel im Ledger können entsperrt werden, indem der Besitz des Alias-Outputs selbst nachgewiesen wird, d. h. indem man nachweist, dass man der Kontrolleur ist und den Output entsperren kann.

Speicherung von Zustandsverpflichtungen

Smart Contraccts sind wie Blockchains, die Statusaktualisierungen in Blöcken vornehmen. Jeder Block identifiziert den Zustand der Blockchain, der diesem spezifischen Block entspricht. Mit der Verankerung des L2-Zustands auf L1 meinen wir die Aufzeichnung einer kryptografischen Verpflichtung zum aktuellen L2-Blockchain-Zustand innerhalb der Alias-Ausgabe. Dies ist vorteilhaft, um den L2-Blockchain-Zustand vertrauensvoll mit dem L1-Blockchain-Zustand zu synchronisieren und öffnet die Tür für eine zukünftige Verifizierung der L2-Zustandsaktualisierung mit “Zero-Knowledge” auf L1.

Stardust ermöglicht die Speicherung beliebiger Daten in Outputs über eine Funktion namens Metadatenfunktion. Smart Contracts sind daher in der Lage, ihre Zustandsverpflichtungen direkt in ihrem Ledger-Konto zu speichern.

Die Frage der Datenspeicherung in Outputs wirft jedoch ein Schlaglicht auf ein allgemeineres Problem: die Größe des Ledgers. Je größer dieser ist, desto größer ist die Belastung der physischen Hardware, auf der die Netzknoten laufen. Wir alle wissen, dass es in der physischen Welt keine unendlichen Ressourcen gibt, daher ist ein System zur Regulierung der Datenspeicherung und damit der Größe des Ledgers erforderlich. Hier kommen die Speicherdepots ins Spiel.

Mechanismus der Speicherablagerung

Speicherdepots schützen das Netz vor übermäßigem Dust (Staub). Der Begriff “Dustprotection” kommt von der Art und Weise, wie der Ledger aufgebläht werden kann, indem Gelder in immer kleinere Stücke (genannt “Dust”) verteilt werden, die alle Netzwerkknoten dazu zwingen, mehr und mehr Konten zu speichern, die nur eine winzige Menge an Token enthalten. Ein Beispiel: Zum Zeitpunkt der Erstellung dieses Artikels könnte ein Angreifer für den Preis von 100 Dollar 100.000.000 Adressen erstellen, die jeweils einen IOTA enthalten. Jeder Eintrag im Ledger des Netzwerks erfordert eine kleine Menge an Daten, die von den Knoten verwaltet werden müssen. Daher kann Dust in Netzwerken, die keine Transaktionsgebühren verlangen, zu einem erheblichen Problem werden, wenn er nicht ordnungsgemäß angegangen wird.

Chrysalis hat bereits eine Lösung für dieses Problem implementiert, wenn auch nicht ohne Vorbehalte. Das Problem der Aufblähung der Datenbank ist in Chrysalis weniger transparent, da die Ledger-Einträge feststehend und von geringer Größe sind. Außerdem ist es nicht möglich, benutzerdefinierte Daten in Ledger-Konten zu speichern.

Stardust führt eine neue Lösung ein, bei der die Datenmenge, die in Ledger-Konten gespeichert werden kann, im Verhältnis zur Höhe der darin enthaltenen Mittel (Einlagen) begrenzt wird. Durch das Halten von Guthaben wird Speicherplatz im Ledger gemietet. Es ist wichtig zu wissen, dass der Speicherplatz auf der Grundlage einer knappen Ressource reguliert werden muss; andernfalls könnte die Größe des Ledgers ins Unendliche wachsen.

Außerdem ist zu beachten, dass die permanente Datenspeicherung auf allen Netzwerkknoten bereits durch das bloße Vorhandensein eines Ledger-Kontos erzwungen wird. Daher muss ein Konto über ein Mindestguthaben verfügen, damit es eingerichtet werden kann. Dieselben Grundsätze gelten auch für Bitcoin und Cardano, doch sind Angriffe auf die Datenbank aufgrund der abschreckenden Transaktionsgebühren dort weniger wahrscheinlich.

Benutzerdefinierte Tokens

Sobald Token auf Smart-Contract-Plattformen eingesetzt werden konnten, wuchs die Zahl der neuen Token (wie ERC-20 oder ERC-721) im Kryptobereich exponentiell. Sie sind ein wichtiger Bestandteil des dApp-Ökosystems und helfen Projekten bei der Kapitalbeschaffung, der Umsetzung neuartiger Governance-Strukturen oder dem Zugang zu einzigartigen Funktionen.

ISC unterstützt die Ethereum Virtual Machine (EVM) und die Erstellung solcher Token auf L2. Aber wenn benutzerdefinierte Token auf Layer 2 erstellt werden, wie können solche Token zwischen verschiedenen Smart Contract Chains verschoben werden? Andere Netzwerke erfordern in der Regel die Implementierung einer Bridge, um zwischen zwei Chains übersetzen zu können, aber diese Bridges sind stark zentralisiert, stellen hochwertige Ziele dar und werden daher häufig gehackt, wie der jüngste Ronin-Bridge-Hack zeigt.

Stardust implementiert das IOTA Tokenization Framework, das als protokollintegrierte, vertrauenslose und atomare Brückenlösung für chainübergreifende Vermögensübertragungen zwischen ISC-Chains konzipiert ist. Kurz gesagt: Mit Stardust ist es nicht nötig, komplizierte Brücken zu bauen. Der IOTA Tangle, mit dem alle Chains verbunden sind, ist die Brücke.

Das Kernstück des Frameworks ist die Umwandlung des IOTA-Ledgers in einen Multi-Asset-Ledger. Jeder, einschließlich der Smart-Contract-Chains, kann angebotsgesteuerte benutzerdefinierte Token direkt auf dem L1 Tangle erstellen. Dies ist die Grundlage für das Asset-Wrapping, einen Mechanismus, der die Erstellung von L1-Repräsentationen von Assets ermöglicht, die von Smart-Contract-Chains stammen. Nach dem Wrapping und der Darstellung auf der IOTA-Basisschicht können Vermögenswerte gebührenfrei an eine andere Adresse im IOTA-Ledger gesendet werden, einschließlich Adressen, die von anderen L2-Chains kontrolliert werden.

Native Token

Austauschbare (fungible) Token werden im Stardust-Protokoll über native Token implementiert. Solche Token werden in sogenannten “Token-Foundries” geprägt. Das Ledger-Konto, das diese “Gießerei” kontrolliert, wird als Emittent bezeichnet. Es hat das Recht, Token in seinem Besitz zu schmelzen und damit den Gesamtbestand zu verringern, während Inhaber Token verbrennen können (wodurch sie nicht aus dem Gesamtbestand, sondern aus dem zirkulierenden Bestand entfernt werden).

Transaktionen mit nativen Token erfolgen über reguläre Überweisungen. Alle möglichen Ausgabearten unterstützen den Besitz von Token, unabhängig davon, ob es sich um Smart-Contract-Chain-Konten oder reguläre Adressen handelt. Aufgrund des oben beschriebenen Speicherdepot-Mechanismus muss ein Transfer immer die Basiswährung des Netzwerks enthalten, um den Netzwerkspeicher zu decken, was reine native Token-Transfers etwas komplizierter macht. Seien Sie versichert, dass alle Anforderungen durch grafische Benutzeroberflächen wie Firefly von den Endbenutzern abstrahiert werden. Wir werden die Anforderungen für native Vermögensübertragungen später in diesem Blogbeitrag untersuchen.

Die erste Version von Stardust wird mit Unterstützung für das Simple Token Scheme starten. Token-Schemata definieren die Regeln für die Angebotskontrolle, d.h. was Token-Emittenten tun dürfen. Das einfache Schema legt eine Obergrenze für das Gesamtangebot an Token fest und garantiert, dass die Emittenten keine Möglichkeit haben, das Angebot über das bei der Erstellung der Token festgelegte Höchstangebot hinaus aufzublähen.

Non-fungible Token

Im Gegensatz zu den zuvor beschriebenen austauschbaren benutzerdefinierten Token sind nicht austauschbare Token (NFTs) einzigartige Token im Ledger, die unveränderliche Metadaten mit sich führen. Sie werden in Stardust als eigenständiger Ausgabetyp, genannt NFT-Ausgabe, implementiert. Das zuvor beschriebene Konzept eines permanenten Smart-Contract-Adresskontos passt hier sehr gut, daher ist die NFT-Ausgabe eigentlich ein Cousin der Alias-Ausgabe, aber mit zusätzlichen Vorteilen.

NFTs in Stardust:

• Sie erhalten bei der Prägung eine weltweit eindeutige Kennung, die auch als permanente, vom aktuellen Besitzer kontrollierte Adresse fungiert.
• Können bei der Prägung mit einem unveränderlichen Datensatz versehen werden, den die NFT während ihrer gesamten Lebensdauer mit sich führt,
• Kann bei der Prägung auch mit einer unveränderlichen Emittentenidentität versehen werden.
• Kann andere NFTs, Token oder beliebige Vermögenswerte sowohl auf der Basisschicht als auch auf Smart-Contract-Chain besitzen. Jede NFT funktioniert als eigenständige Brieftasche mit einer permanenten Adresse.
• Sie können von ihren Besitzern verbrannt werden, um z. B. Token freizugeben, die in ihnen gesperrt sind und als Lagerstätte benötigt werden.

Das Minting eines NFT ist so kostengünstig wie das Senden einer regulären Überweisung: Es ist sogar gebührenfrei! Da NFTs jedoch zusätzliche Daten mit sich führen können, müssen die Emittenten der NFT-Ausgabe genügend Token zuführen, um die Speicherkaution zu decken. Wenn die NFT verbrannt wird, wird diese Kaution dem aktuellen Besitzer vollständig zurückerstattet.

Benutzerinteraktion mit smarts Contracts

Bisher wurden die Funktionen zur Einrichtung von Smart-Contract-Chains, zur Speicherung von Zustandsverpflichtungen und zur chainübergreifenden Übertragung von Vermögenswerten erörtert. Wie interagieren normale Nutzer mit Chains?

ISC definiert zwei Arten der Interaktion mit Smart-Contract-Chains:

• On-Ledger-Anfragen, die vom Basisprotokoll ausgehen,
• Off-Ledger-Anfragen, die direkt an die L2-Chain gesendet werden.

Wie der Name schon sagt, werden Off-Ledger-Anfragen direkt an die L2-Smart-Contract-Chain gesendet und sind daher für das Stardust-Protokoll nicht von Interesse. On-Ledger-Anfragen hingegen erfordern eine spezielle Unterstützung durch das Basisprotokoll, die in Stardust über zwei neue Ausgänge, die Entsperrbedingungen und die Ausgangsmerkmale, implementiert wird.

Ausgabe von Entsperrungsbedingungen

Eine On-Ledger-Anfrage ist eine Ausgabe einer Transaktion, die an die Adresse der Smart-Contract-Chain auf L1 gesendet wird. Daher sollte der Ausgang nur von der Smart-Contract-Chain entsperrt werden können, damit die Anfrage bearbeitet werden kann.

In Stardust wird diese Funktion durch die “Address Unlock Condition” unterstützt, die lediglich eine Verallgemeinerung des “Output-Locking-Konzepts” in Chrysalis ist und um die neuen Adresstypen erweitert wurde.

Eine On-Ledger-Anforderung kann native Vermögenswerte in die Chain einbringen (native Token oder NFTs). Wie bereits erwähnt, ist es nicht möglich, native Token ohne Einbeziehung der Basiswährung zu senden, und es ist eine ziemlich harte Anforderung an die Benutzer, immer Basis-Token zusammen mit nativen Token in Chains zu hinterlegen. Daher ermöglicht eine neue Bedingung für die Rückgabe von Speicherdepots die automatische Rückforderung von Speicherdepots für Outputs durch den Absender.

Wenn Alice genau einen AliceCoin an Bob senden möchte, würde sie eine Ausgabe an Bobs Adresse mit dem Speicherdepotbetrag von IOTA-Token + 1 AliceCoin erstellen und eine Rückgabebedingung definieren, dass sie den Speicherdepotbetrag von IOTA-Token zurückerwartet. Bob kann diese Ausgabe nur dann in einer Transaktion verbrauchen, wenn er Alice mindestens diesen Betrag an IOTAs zurückerstattet.

Was passiert, wenn Bob die Ausgabe nie verbraucht? Das Depot von Alice ist für immer gesperrt! Deshalb ist Alice klug genug, auch für die Ausgabe eine Ablaufsperrbedingung zu definieren. Sie kann eine Ablauffrist festlegen, bis zu der Bob die Ausgabe verbrauchen muss, andernfalls geht das Eigentum an der Ausgabe ausschließlich an Alice zurück.

Dies funktioniert auch gut bei On-Ledger-Anfragen: Man kann festlegen, dass die Smart-Contract-Chain nur den nativen Vermögenswert aus der Ausgabe entnehmen kann, aber die Speicherkaution zurückgeben muss. Mit der Ablauffrist stellt der Nutzer sicher, dass die Anfrage entweder innerhalb der Frist von der Chain bearbeitet oder ganz abgebrochen wird. Dies ist ein einzigartiges Merkmal von Stardust und dem ISC-System.

Eine weitere praktische Funktion ist die “Timelock-Unlock-Bedingung“, die verhindert, dass die Ausgabe freigegeben wird, bis die Timelock-Frist eingehalten wird. Warum ist dies so wichtig? Weil Sie damit Smart-Contract-Anfragen genau timen können. Sobald die Frist abgelaufen ist, nimmt die Smart-Contract-Chain die Anfrage auf und führt sie aus.

Diese Freigabebedingungen werden derzeit von Stardust unterstützt, weil sie für Smart Contracts erforderlich sind, aber im Diskussionsforum des Tangle Improvement Proposal (TIP) Repository kursieren viele Ideen, zu denen auch das Swapping gehört.

Output-Funktionen

Features, die keinen Einfluss auf die eigentliche Freischaltung des Outputs haben, werden als Output-Features definiert. Für Smart Contracts wurde eines der wichtigsten Features bereits erwähnt: das Metadaten-Feature. Dieses ist auch für Nutzer und On-Ledger-Anfragen essentiell. Das Metadaten-Feature des Outputs enthält die eigentlichen Aufrufdaten, d. h. die Anweisungen, die von den Smart Contracts ausgeführt werden sollen.

Wenn Alice einen Smart Contract auf Chain A von ihrem IOTA-Konto aus aufrufen möchte:

• Sie bereitet eine IOTA-Transaktion vor, in der sie eine Ausgabe (On-Ledger-Anfrage) mit Geldmitteln an die permanente Adresse von Chain A erstellt.
• Im Metadatenmerkmal der Ausgabe kodiert sie die Aufrufdaten: “Aufruf des Einstiegspunkts X von Smart Contract Y mit den Parametern A, B und C”.
• Sobald die Transaktion auf IOTA bestätigt wird, erkennt Chain A, dass eine neue On-Ledger-Anfrage auf ihrer Adresse liegt.
• Chain A nimmt die Anfrage auf und führt den im Metadaten-Feature kodierten Aufruf aus, wodurch der L2-Zustand der Blockchain fortgeschrieben und das Ergebnis auf IOTA über eine Zustandsaktualisierungsverankerungstransaktion abgerechnet wird.

Woher weiß die Chain, dass Alice die Ausgabe erstellt hat, d. h. dass die Anfrage unter Alices Namen ausgeführt werden soll? Sie hat keinen Zugriff auf die IOTA-Transaktion, sondern nur auf deren Ergebnis. Und selbst wenn sie Zugang hätte, was wäre, wenn Bob und Alice in derselben Transaktion Anfragen stellen würden?

Die Stardust-Lösung ist die Absenderfunktion. Ausgaben können ihre Absender explizit angeben, während die Transaktionsvalidierung sicherstellt, dass die Absenderadresse auf der Eingangsseite der Transaktion freigeschaltet ist. Daher muss der Eigentümer der Absenderadresse zugestimmt haben, die On-Ledger-Anfrage unter ihrem Namen auszuführen.

Beachten Sie, dass On-Ledger-Anfragen von jeder IOTA-Adresse gesendet werden können, auch von NFT-Adressen und Alias-Adressen. Letzteres macht es möglich, dass Chain A eine Anfrage auf Chain B ausführt, was die Kompositionsfähigkeit von Smart Contracts auf die nächste Stufe hebt: die chainübergreifende Kompositionsfähigkeit. Ersteres, das Senden von Smart-Contract-Anfragen von NFT-Adressen aus, eröffnet neue Möglichkeiten für dApp-Entwickler, da bestimmte Smart-Contract-Funktionen nur für NFT-Inhaber verfügbar gemacht werden können.

Alle Freischaltbedingungen und Funktionen werden sowohl von Basic Outputs, die das primäre Vehikel für On-Ledger-Anfragen sind, als auch von NFT Outputs unterstützt.

Zusätzliche Protokollverbesserungen

Bisher haben wir die Entstehungsgeschichte der meisten Funktionen des Stardust-Protokolls dargestellt. Neben der Erfüllung der Anforderungen von Smart Contracts gibt es jedoch noch weitere Verbesserungen im Vergleich zu Chrysalis.

Replay-Schutz

Transaktionen in DLT sind signierte Anweisungen, die den Zustand des Ledgers verändern. Die Existenz paralleler Netzwerke mit der gleichen Ledger-Funktionalität (man denke an Shimmer und IOTA) eröffnet die Möglichkeit von Replay-Angriffen, d.h. wenn ein Angreifer eine gültige signierte Transaktion in einem anderen Netzwerk erneut ausgibt.

Um auch nur die geringste Möglichkeit eines solchen Angriffs zu verhindern, fügt Stardust ein Feld für die Netzwerkkennung in den Inhalt der signierten Transaktionen ein. Dies hat zur Folge, dass eine Transaktion, selbst wenn sie ansonsten korrekt ist, in einem anderen als dem vorgesehenen Netz aufgrund der nicht übereinstimmenden Netzkennung sofort zurückgewiesen wird.

Verpflichtung zu Eingaben

In einem UTXO-basierten Ledger referenzieren Transaktionen die Inputs, die sie verbrauchen wollen, durch ihre eindeutigen Identifikatoren. Die Kunden sammeln den Inhalt der Eingänge, indem sie auf die Identifikatoren der Eingänge in den Knoten zugreifen. Wenn Sie keinen eigenen Knoten betreiben, spricht Ihre Wallet wahrscheinlich mit einer Explorer- oder Indexer-Anwendung, die wiederum Daten von einem Netzwerkknoten abruft. Können Sie sich darauf verlassen, dass eine dritte Partei Ihnen den korrekten Inhalt der Ihnen gehörenden Inputs zur Verfügung stellt, um eine Transaktion zu erstellen? Was ist, wenn deren Infrastruktur gehackt wird?

Glücklicherweise müssen Sie sich bei Stardust nicht auf Dritte verlassen. Transaktionen enthalten ein Inputs-Commitment-Feld, das (wie der Name schon sagt) eine kryptografische Zusage für den Inhalt der Inputs der Transaktion darstellt. Sollte Ihre Wallet aus irgendeinem Grund mit bösartigen Daten versorgt worden sein und eine Transaktion auf der Grundlage dieser Daten konstruiert haben, wird das Netzwerk feststellen, dass es eine Diskrepanz zwischen dem, was das Netzwerk für Ihre Eingaben hält, und dem, was Ihre Wallet tut, gibt.

Dieser Mechanismus schützt nicht nur die Nutzer, sondern auch die Smart-Contract-Chains. Ein Angreifer könnte in der Lage sein, die Verbindung von L2-Validatoren zu L1-Knoten zu unterbrechen und den Inhalt von Anfragen zu ersetzen, um die Gelder der Nutzer zu stehlen, aber mit diesem Sicherheitsmechanismus würden solche böswilligen Transaktionen vom Basisprotokoll zurückgewiesen werden, was dazu führt, dass die Chain erkennt, dass sie unterbrochen wurde, weil sie keine gültige Statusaktualisierung erzeugt hat.

Auslagerung der Datenverarbeitung aus dem Kernprotokoll

IOTA ist insofern einzigartig, als dass es im Tangle reine Datentransaktionen ermöglicht. Anwendungsfälle, die auf dieser Funktion aufbauen, stehen jedoch vor zwei großen Problemen:

• Der Tangle ist “permissionless”, d.h. jeder kann Datennachrichten mit beliebigem Inhalt senden, und die Nachrichten werden nicht wie Werttransaktionen durch Signaturen authentifiziert. Die Quelle der über den Tangle veröffentlichten Daten ist durch das Kernprotokoll nicht identifizierbar.
• Datenverwendungsanwendungen sind häufig auf strukturierte, gefilterte und verarbeitete anwendungsspezifische Daten angewiesen. Solche Funktionen belasten die Netzknoten, auf denen das Kernprotokoll läuft, unnötig.

Ein Beispiel für letzteres ist die Datenindexierungsfunktion, die in der Chrysalis-Aktualisierung enthalten ist. Datenanwendungs-Clients wollen in der Lage sein, Daten aus dem Tangle zu holen, die für sie von Interesse sind, daher müssen die Daten indiziert werden, um Client-Abfragen zu unterstützen. Wie oben beschrieben, hindert Chrysalis niemanden daran, Indizes mit Daten zu spammen, wodurch die Client-Funktionalität möglicherweise unterbrochen wird, wenn keine Gegenmaßnahmen ergriffen werden.

Stardust entfernt jegliche Datenverarbeitung aus dem Kernprotokoll, da die Unterstützung von anwendungsspezifischen Verarbeitungsanforderungen im Kernprotokoll nicht durchführbar ist – und außerdem würde dies die Knotenleistung und damit den Transaktionsdurchsatz im Netz gefährden.

Daten in Stardust werden über “Tagged Data Payloads” veröffentlicht, die vom Protokoll als Binärdaten behandelt werden. Es wird empfohlen, dass die Verarbeitung und Offenlegung von anwendungsspezifischen Daten, die über diese Nutzdaten veröffentlicht werden, durch Protokolle der zweiten Schicht erfolgen. Ein großer Vorteil dieses Konzepts ist seine Flexibilität: Jede Anwendung kann ihre eigenen Anforderungen definieren und implementieren – zum Beispiel die Authentifizierung von Daten-Nutzdaten auf der Grundlage digitaler Signaturen, die Indizierung durch benutzerdefinierte Felder oder die Validierung von Nutzdaten anhand erwarteter Datenstrukturen.

Die überarbeitete Knotensoftware bietet eine Remote Procedure Call (gRPC)-Schnittstelle, genannt IOTA Node Extension (INX), für externe Anwendungen, um mit den Knoten zu interagieren, zum Beispiel um alle Netzwerkaktivitäten abzuhören. Datenanwender werden ermutigt, ihre eigenen Datenverarbeitungsanwendungen zu entwickeln und sie über INX mit dem Tangle zu verbinden.

Um mit dieser neuen Architektur konsistent zu bleiben, entfernt Stardust auch die Ledger-Indizierung aus dem Kernprotokoll und implementiert eine Ledger-Indizierungsanwendung über ein INX-Modul.

Dynamischer Proof of Work

Proof of Work (PoW) wird derzeit in IOTA zur Überlastungskontrolle eingesetzt. Jede Transaktion muss eine kleine Menge an Rechenarbeit beinhalten, damit sie als gültig angesehen wird. Während in Blockchain-Netzwerken die Miner darum konkurrieren, das kryptografische PoW-Puzzle als erstes zu lösen und dabei eine riesige Menge an Energie verschwenden, nehmen IOTA-Nutzer, die Transaktionen an das Netzwerk übermitteln, an einer kooperativen Anstrengung teil.

Chrysalis hat einen festen PoW-Schwierigkeitsfaktor für eine Einheit von Daten, die an das Netzwerk übermittelt werden. Daher ist die tatsächliche Komplexität der Herausforderung für eine Transaktion nur von ihrer Länge abhängig.

Das Stardust-Protokoll sieht einen dynamischen PoW-Schwierigkeitsfaktor vor, der von der Überlastung des Netzes abhängt. Der zusätzliche Nutzen des Protokoll-Upgrades könnte zu einer höheren Netzaktivität führen. Erreicht diese Belastung einen bestimmten Schwellenwert nahe der Grenze der Durchsatzkapazität des Netzes, passt das Protokoll den PoW-Schwierigkeitsfaktor selbst an. Wenn die Belastung sinkt, kehrt sich der Prozess um und senkt den Schwierigkeitsgrad, bis der Schwellenwert wieder erreicht ist.

Dieser Mechanismus wird vom Netz nach dem allerersten “fluid” Protokoll-Upgrade unterstützt, d. h. die Funktion wird im bereits laufenden Netz ohne Ausfallzeiten aktiviert. Die Knotensoftware wird derzeit überarbeitet, um viele weitere solcher zukünftigen Protokoll-Upgrades zu ermöglichen.

Zusammenfassung

Damit haben wir die Liste der neuen Protokollfunktionen in Stardust abgeschlossen. Lassen Sie uns zusammenfassen, was wir bisher gelernt haben.

Stardust wurde als Modul zur Unterstützung von Smart Contracts für das IOTA 2.0-Protokoll geboren. Erste Tests von ISC-Chains im IOTA 2.0 DevNet brachten eine Menge Erkenntnisse und Verbesserungen für den Prototyp. Stardust wurde als ein eigenständiges Protokollmodul identifiziert, das bereits auf das IOTA Mainnet portiert werden kann und einen großen Schritt in Richtung IOTA 2.0 in einer Produktionsumgebung darstellt.

Shimmer wird mit dem Stardust-Protokoll starten, um es gründlich zu testen und zu validieren, bevor es im Mainnet eingeführt wird. Dies gibt auch genügend Zeit für Community-Projekte, um ihre dApps zu entwickeln und zu testen, bevor sie schließlich auf IOTA eingeführt werden.

Um dem IOTA-Ledger ein noch nie dagewesenes Maß an Nutzen zu verleihen, führt Stardust ein:

• Neue Arten von Ledger-Konten.
• Mehrere neue Ausgabetypen.
• Bedingungen und Funktionen für die Freigabe von Ausgaben.
• Gebührenfreie native Token und NFTs.
• Mechanismen zum Auslagern der Datenverarbeitung.

Nicht nur Smart-Contract-Chains werden die neue Funktion nutzen können, sondern auch normale Nutzer und zukünftige Innovatoren.

Darüber hinaus zielt eine Reihe von Protokollverbesserungen und Architekturänderungen darauf ab, die Sicherheit, die Leistung und das Netzwerkverhalten in Zeiten starker Überlastung zu verbessern.

Wie geht es weiter?

Die Spezifikationen des Stardust-Protokolls wurden gründlich überprüft, und die Umsetzung ist in vollem Gange. Der Prototyp der Knotensoftware befindet sich in der internen Alpha-Testphase, während die Entwicklung von Clients und Werkzeugen auf Hochtouren läuft. Ein wichtiger Teil dieser Bemühungen ist die Unterstützung der Wallet-Bibliothek für die neuen Ledger-Modelle und -Konzepte sowie die neuen Benutzerinteraktionsabläufe der Firefly-Wallet.

Parallel dazu arbeitet das ISC-Team Tag und Nacht an der Überarbeitung mehrerer Schlüsselkomponenten der ISC-Knoten-Software für Stardust. In der Entwicklung befindet sich eine neue virtuelle ISC-Maschine namens Stardust VM, die mit den neuen Funktionen des Basisprotokolls vollständig kompatibel ist.

Stardust wird in den öffentlichen Betatest gehen, sobald die Entwicklerwerkzeuge implementiert sind und die Alpha-Tests der Knotensoftware zufriedenstellende Ergebnisse liefern. Die Hauptzielgruppe für öffentliche Betatests sind Entwickler und vor allem Community-Projekte.

Shimmer wird mit Stardust und einem kompletten Satz von Benutzerwerkzeugen an den Start gehen, damit auch Nichttechniker die Magie des zusätzlichen Nutzens des neuen Protokoll-Upgrades erleben können. Schließlich wird Stardust zusammen mit ISC und Smart Contracts seinen Weg ins IOTA Mainnet finden, um die Web3-Innovation im IOTA-Ökosystem zu beschleunigen. Klingt aufregend? Begeben Sie sich mit uns auf diese Reise und verfolgen Sie die Stardust-Entwicklung auf GitHub, tragen Sie zu einem Tangle Improvement Proposal bei, teilen Sie Ihre eigenen Ideen mit oder engagieren Sie sich in der Community auf Discord, um mehr über die Möglichkeiten von Stardust zu erfahren.

---

Quelle:

Shimmer Blog Artikel: Deep Dive into Stardust