Vertiefung in Stardust

IOTAs Ledger Web3-fähig machen

TL;DR:
Stardust verwandelt IOTA in eine Infrastrukturschicht für Smart-Contract-Ketten und führt benutzerdefinierte Token ein. Der neue Ledger ist zu bedingten Übertragungen fähig und NFTs können als Wallets fungieren, während zusätzliche Protokollverbesserungen Knotenressourcen 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 Nutzen-Upgrade erhalten: Stardust baut auf dem letztjährigen Chrysalis-Netzwerk-Upgrade auf und fügt einen noch nie dagewesenen Nutzen hinzu. In diesem Blogbeitrag erkunden wir die Ursprünge von Stardust und die detaillierten Vorteile, die es mit sich bringen wird. Wenn Sie eine komprimierte Einführung suchen, lesen Sie 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 und stattdessen vereinfacht und an Industriestandards und Best Practices angepasst. Das Chrysalis-Protokoll läuft seither stabil im IOTA-Hauptnetz 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.

automatischer Handel mit Kryptowährungen

Stardust

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

Parallel zu unserer Arbeit an Coordicide haben wir das IOTA Smart Contracts (ISC) Protokoll auf dem IOTA 2.0 DevNet aufgebaut. Die ISC-Beta wurde im letzten Oktober im DevNet gestartet und das Basisprotokoll erhielt Unterstützung, 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 damit beginnen kann, Smart-Contract-basierte Anwendungsfälle auf dem IOTA-Mainnet zu entwickeln. 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.

iota schnell auf bitvavo kaufen

Shimmer Stardust Upgrade

Warum 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 noch nie dagewesenen Durchsatz, ist aber auf das IOTA-Basisprotokoll angewiesen, um die vertrauenswürdige Infrastruktur für die Interoperabilität bereitzustellen.

Suche Gastautoren

Das Schlüsselwort ist hier Infrastruktur. Stellen Sie sich den Tangle als Autobahnsystem vor: Es 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-Ketten ermöglicht, wobei jede dieser Ketten funktional einer Blockchain wie Ethereum entspricht, die über das IOTA Tangle verbunden ist.

automatischer Handel mit Kryptowährungen

Was ist Stardust?

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 gebührenfreie Eigenschaft des Protokolls bewahrt den Wert für Werttransfers zwischen den Ketten.
  • 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 Infrastrukturschicht für Smart-Contract-Ketten umzuwandeln, während es gleichzeitig zu einem Multi-Asset-Ledger wird. Darüber hinaus werden die neuen Ausgabetypen in Stardust es 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 Blogbeitrag näher beschrieben wird.

automatischer Handel mit Kryptowährungen

Smart Contracts Anforderungen

Was braucht eine IOTA Smart Contracts-Kette, 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 zweiten Schicht  (L2) Kette.
  3. Benutzerdefinierte Token für kettenübergreifende Vermögensübertragungen.
  4. Mittel zur Erleichterung der Benutzerinteraktion.

Stardust Smart Contracts

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.

Lassen Sie uns die Lösungen im Detail erkunden.

Ein neues Ledger-Konto

Stardust Ledger

Ein Ledger account 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.

Smart-Contracts Chain-Konten 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 Unterschrift leistet. Jedes Mal, wenn der Validatorensatz geändert wird, muss eine neue gemeinsame Adresse erstellt werden.

Daher kann das herkömmliche Adressenkonzept keine dauerhafte Adresse für Smart-Contract-Kettenkonten 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 zu generieren,
  • ihren Zustand und die Kontrollschlüssel über Transaktionen hinweg zu 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. Prüfen.

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-Ausgang zum ersten Mal im Ledger angelegt wird, generiert das Protokoll eine eindeutige Adresse, die im Ausgang 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:

  • Die Alias-Ausgabe 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 man das Eigentum an der Alias-Ausgabe selbst nachweist, d. h. indem man nachweist, dass man der Kontrolleur ist und die Ausgabe entsperren kann.

Speichern von staatlichen Verpflichtungen

Smart Contracts-Ketten sind wie Blockchains, die Statusaktualisierungen in Blöcken erzeugen. 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 Null-Wissen auf L1.

Stardust ermöglicht die Speicherung beliebiger Daten in Outputs über eine Funktion namens Metadatenfunktion. Smart Contracts-Ketten 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 das Hauptbuch 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 Hauptbuchs erforderlich. Hier kommen die Speicherdepots ins Spiel

Mechanismus für die Lagerhaltung

Speicherdepots schützen das Netzwerk vor übermäßigem „Staub“. Der Begriff „Staubschutz“ kommt von der Art und Weise, wie das Hauptbuch aufgebläht werden kann, indem Gelder in immer kleinere Stücke (genannt „Staub“) 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 Hauptbuch des Netzwerks erfordert eine kleine Menge an Daten, die von den Knoten verwaltet werden müssen. Daher kann Staub in Netzwerken, die keine Transaktionsgebühren verlangen, zu einem erheblichen Problem werden, wenn er nicht ordnungsgemäß entschärft 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 Hauptbuch 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.

Es ist auch zu beachten, dass die permanente Datenspeicherung auf allen Netzwerkknoten bereits durch die bloße Existenz 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 Token

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-Ketten 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 kettenübergreifende Vermögensübertragungen zwischen ISC-Ketten konzipiert ist. Kurz gesagt: Mit Stardust ist es nicht nötig, komplizierte Brücken zu bauen. Der IOTA Tangle, mit dem alle Ketten 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-Ketten, kann direkt auf dem L1 Tangle angebotsgesteuerte benutzerdefinierte Token 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-Ketten 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-Ketten kontrolliert werden.

Native Token

Fungible Token werden im Stardust-Protokoll durch native Token implementiert. Solche Token werden in Token-Foundries geprägt. Das Ledger-Konto, das die „Gießerei“ kontrolliert, wird als Emittent bezeichnet. Er 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, und alle möglichen Ausgabearten unterstützen den Besitz von Token, unabhängig davon, ob es sich um Smart-Contract-Kettenkonten 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.

Nicht-fungible Token

Im Gegensatz zu den zuvor beschriebenen vertretbaren benutzerdefinierten Token sind nicht vertretbare Token (NFTs) einzigartige Token im Ledger, die unveränderliche Metadaten enthalten. 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-Ketten 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 das NFT verbrannt wird, wird diese Kaution dem aktuellen Besitzer vollständig zurückerstattet.

Benutzerinteraktion mit Smart Contracts

Bisher wurden die Funktionen zum Einrichten von Smart-Contract-Ketten, zum Speichern von Zustandsverpflichtungen und zum kettenübergreifenden Transfer von Vermögenswerten erörtert. Wie interagieren normale Nutzer mit Ketten?

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

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

Wie der Name schon sagt, werden Off-Ledger-Anfragen direkt an die L2-Smart-Contract-Kette 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, Unlock Conditions und Output Features, implementiert wird.

Bedingungen für die Freigabe der Ausgabe

Eine On-Ledger-Anfrage ist eine Ausgabe einer Transaktion, die an die Adresse der Smart-Contract-Kette auf L1 gesendet wird. Daher sollte die Ausgabe nur von der Smart-Contract-Kette 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 Kette 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 Ketten 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 für On-Ledger-Anfragen: Man kann festlegen, dass die Smart-Contract-Kette nur den nativen Vermögenswert aus dem Output entnehmen kann, aber die Speicherkaution zurückgeben muss. Mit der Ablauffrist stellt der Nutzer sicher, dass die Anfrage entweder innerhalb der Frist von der Kette 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 man damit Smart-Contract-Anfragen zeitlich genau festlegen kann. Sobald die Frist abgelaufen ist, nimmt die Smart-Contract-Kette 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, darunter auch Swapping.

Ausgabe-Features

Features, die keinen Einfluss auf die eigentliche Freischaltung des Outputs haben, werden als Output Features definiert. Für Smart Contracts wurde bereits eines der wichtigsten Features 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 auszuführen sind.

Wenn Alice einen Smart Contract auf Kette 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 Kette 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 Kette A, dass eine neue On-Ledger-Anfrage auf ihrer Adresse liegt.
  • Kette 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 Statusaktualisierungs-Ankertransaktion abgerechnet wird.

Woher weiß die Kette, 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 seinem 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 Kette A eine Anfrage auf Kette B ausführt, was die Kompositionsfähigkeit von Smart Contracts auf die nächste Stufe hebt: die kettenü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

Bislang haben wir die Entstehungsgeschichte der meisten Funktionen des Stardust-Protokolls vorgestellt. Neben der Erfüllung der Anforderungen an 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ührt 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 ein Dritter Ihnen den korrekten Inhalt der Inputs, die Ihnen gehören, 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-Ketten. 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 Kette 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 erlaubnisfrei, d.h. jeder kann Datennachrichten mit beliebigem Inhalt senden, und die Nachrichten werden nicht wie Werttransaktionen durch Signaturen authentifiziert. Die Quelle der über 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. Anwendungsclients wollen in der Lage sein, die für sie interessanten Daten aus dem Tangle abzurufen, weshalb die Daten indiziert werden müssen, 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, z.B. um alle Netzwerkaktivitäten zu überwachen. 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 wetteifern, das kryptografische PoW-Puzzle als erstes zu lösen und dabei eine riesige Menge an Energie verschwenden, nehmen IOTA-Benutzer, 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 flüssigen 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 rekapitulieren, was wir bisher gelernt haben.

Stardust wurde als das Modul zur Unterstützung von Smart Contracts für das IOTA 2.0-Protokoll geboren. Erste Tests von ISC-Ketten im IOTA 2.0 DevNet brachten viele 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 neuen Funktionen 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. Letztendlich 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.

Original by Shimmer: https://blog.shimmer.network/a-deep-dive-into-stardust/

0 0 Stimmen
Artikel Bewertung
Abonnieren
Benachrichtige mich bei
guest
1 Kommentar
Meistgewählt
Neuestes Älteste
Inline-Rückmeldungen
Alle Kommentare anzeigen
MusicLover
Gast
6 Tage zuvor

Vielen Dank für diese tolle Übersetzung des englischen Originals.
Auch mit Englischkenntnissen, wird der Text in der Muttersprache einfach schneller verständlich. Ich freue mich sehr auf Eure kommenden Artikel!

1
0
Ich würde mich über Ihre Meinung freuen, bitte kommentieren Sie.x