IOTA Tokenization Framework Spezifikationen

TL;DR:
Heute veröffentlichen wir Spezifikationen für das neue Tokenization Framework für das IOTA Mainnet. Dieses zukünftige Upgrade wird das Mainnet-Protokoll zu einem Multi-Asset-Ledger mit Smart Contracts und nahtlosen Cross-Chain-Asset-Transfers transformieren. Native Token und NFTs leben innerhalb des Tangles und erben die Gebührenfreiheit und Skalierbarkeit der Basiswährung, des IOTA Coins. Ein vertrauensloser Brückenmechanismus des Native Tokenization Frameworks stellt sicher, dass Smart Contract Token mühelos in native Token eingewickelt und aus ihnen ausgewickelt werden können. Die Protokollspezifikationen werden derzeit öffentlich geprüft, und die Arbeit an der Testnet-Implementierung hat bereits begonnen.

[donation]

Tokenisierung ist eine der größten Innovationen im DLT-Bereich und ermöglicht völlig neue Anwendungsfälle und Geschäftsmodelle. IOTA hat die Tokenisierungslandschaft mit dem Native Tokenization Framework erkundet, das im Juni 2021 für das IOTA 2.0 DevNet veröffentlicht wurde.

In früheren Blogbeiträgen haben wir die neuartigen Anwendungsfälle und Möglichkeiten erläutert, die die Tokenisierung mit sich bringt, und gezeigt, wie leistungsfähig die Testnet-Implementierung des Frameworks ist. Benutzer können ihre eigenen Token und Vermögenswerte direkt auf dem Tangle prägen, die dann wie IOTA-Münzen gefühlt übertragbar sind.

Durch das Experimentieren mit digitalen Vermögenswerten im Entwicklungsnetzwerk haben wir eine Menge über die Grenzen unserer Konzepte gelernt. Wir sind einen Schritt zurück getreten und haben uns eine Welt vorgestellt, in der digitale Vermögenswerte ein wichtiger Baustein des gesamten IOTA-Technologie-Stacks sind. In diesem Token-Wunderland fließen die Vermögenswerte nahtlos und vertrauensvoll zwischen Smart-Contract-Ketten und Benutzerkonten. Sie können ohne zentralisierte Brückenlösungen verpackt oder entpackt werden. Es steht jedem frei, seine eigenen Token zu erstellen und zu verwalten. Schließlich geht es bei IOTA um Freiheit.

Wir sind stolz darauf, heute die Mainnet-Spezifikationen des IOTA Tokenization Frameworks zu präsentieren und laden die Community ein, diesen spannenden Bereich mit uns zu erforschen, während wir uns auf den Weg machen, das bisher größte Utility-Upgrade für das IOTA Mainnet durchzuführen.

Umwandlung von IOTA in ein Multi-Asset-Ledger

Die meisten DLTs fallen in die Kategorie der Single-Asset-Ledger, da sie nur in der Lage sind, das Eigentum an einer bestimmten Basiswährung innerhalb ihres Ledgers zu verfolgen. Multi-Asset-Ledger hingegen sind in der Lage, mehrere native Token in demselben Ledger zu verwalten, das auch die Basiswährung verwaltet. Da der Basis-Ledger von IOTA gebührenfreie Transaktionen ermöglicht, ist ein Multi-Asset-Ledger von IOTA in der Lage, gebührenfreie Transfers beliebiger nativer Token auszuführen, was eine einzigartige Neuerung in diesem Bereich darstellt.

Wir haben das Unspent Transaction Output (UTXO)-Modell des IOTA-Ledgers umgestaltet und erweitert, um ihn in einen vollwertigen Multi-Asset-Ledger zu verwandeln. Jedes Konto im Ledger ist in der Lage, native Token, die von Token Foundries geprägt wurden, zu halten und zu übertragen. Es ist nicht mehr notwendig, IOTA-Münzen zu „markieren“ oder zu „färben“: alle nativen Token sind eigenständige Token im Ledger, die von Foundries geprägt werden.

Native Token werden von den Nutzern in das IOTA-Ledger eingespeist; daher werden sie auch als benutzerdefinierte Token bezeichnet. Sie verbrauchen wertvolle Ressourcen der Knoten, die das Netzwerk unterhalten, vor allem Speicherplatz. Infolgedessen muss jedes Konto, das native Token hält, eine Kaution in IOTA-Münzen hinterlegen, um den übermäßigen Ressourcenverbrauch auszugleichen.

Token-Foundries

Der Ersteller des benutzerdefinierten Tokens, der als Emittent bezeichnet wird, hat die Kontrolle über die Token-Foundry und regelt die Prägung oder das Brennen von Token, die zur Foundry gehören.

Jeder kann Emittent werden und mit der Prägung seiner eigenen Token beginnen. Token-Foundries überlassen es den Emittenten, eine für ihre Anwendungsfälle geeignete Angebotskontrollpolitik zu wählen. So kann ein nativer Token in IOTA je nach dem Token-Schema der Foundry einen dynamischen, festen oder begrenzten Gesamtvorrat haben. Fortschrittlichere Schemata wie Minting oder Burning Flow Control werden mit fortschreitender Implementierung iterativ in das Framework integriert.

Die Entität des Emittenten kann eine einzelne Adresse, eine Multisignatur-Adresse, eine Schwellenwert-Multisignatur-Adresse mit beliebigen Teilnehmern und Schwellenwerten oder eine Smart-Contract-Kettenadresse sein. Es ist auch möglich, die Rechte des Emittenten auf andere Entitäten zu übertragen, aber es ist verboten, die bei der Einrichtung der „Gießerei“ definierte Angebotskontrollpolitik zu ändern, was eine unglaubliche Vielfalt von Anwendungsfällen ermöglicht, die weit über eine bloße Färbung von Token hinausgeht, die Anfang dieses Jahres eingeführt wurde.

Die Transparenz des Tokenization Framework ist für IOTA von größter Bedeutung. Foundries produzieren Token mit einer spezifischen Token-ID, die den global eindeutigen Identifikator der kontrollierenden Foundry und einige vordefinierte Token-Metadaten, wie zum Beispiel einen Namen, enthält. Basierend auf der Token-ID eines nativen Tokens ist es möglich, Informationen darüber abzuleiten:

• Vom Emittenten definierte Token-Tags, wie Name oder Ticker
• Kontoinformationen des Emittenten
• Das Token-Schema, d.h. die Politik der Angebotskontrolle
• Umlauf und maximaler Tokenvorrat
• Auf der Chain gespeicherte Token-Metadaten

Es besteht keine Notwendigkeit für Token-Register außerhalb der on-chain; alles über einen Token kann auf der on-chain dokumentiert und gespeichert werden, direkt im UTXO-Ledger von dem Tangle. Emittenten können sich dafür entscheiden, ihr On-Chain-Konto öffentlich bekannt zu geben, um die Transparenz ihrer Token zu erhöhen. Anhand einer Liste validierter Emittentenidentitäten, die mit realen Identitäten verknüpft sind, können Wallets automatisch die Authentizität aller nativen Token feststellen.

Non-fungible Wertmarken

Token-Foundries eignen sich hervorragend für fungible Token, können aber auch nicht-fungible Token (NFTs) produzieren. Eine Token-Foundry, die das maximale Angebot auf 1 festlegt, kontrolliert im Wesentlichen nur einen Token, der im Ledger weltweit einzigartig ist; es handelt sich also um einen NFT.

Die meisten NFTs repräsentieren das Eigentum an etwas Einzigartigem, wie einem digitalen Kunstwerk oder einem Sammlerstück. Daher müssen sie einen weltweit eindeutigen Bezeichner und eine Beschreibung des zugrunde liegenden Vermögenswerts haben. Letztere wird häufig als Metadaten kodiert, die der NFT beigefügt sind. Das Eigentum an dem Token bedeutet auch das Eigentum an den Metadaten.

Eine von der „Gießerei“ kontrollierte native NFT kann auf beliebige Konten im Hauptbuch übertragen werden, die On-Chain-Metadaten verbleiben jedoch bei der „Gießerei“. Außerdem behält der Emittent die Kontrolle über das Brennen der nativen NFT, nicht der eigentliche Eigentümer. Um die Risiken zu verringern, die damit verbunden sind, dass ein Emittent anstelle des aktuellen Eigentümers die Kontrolle hat, haben wir im Tokenization Framework eine erweiterte Unterstützung für NFTs mit einem eigenen NFT-Ausgabetyp hinzugefügt.

Mit ihrem eigenen Ausgabetyp werden NFTs zu Bürgern erster Klasse im IOTA-Ledger. Jeder kann eine NFT erstellen, die Folgendes hat:

• Eine weltweit eindeutige Kennung, die bei der Prägung zugewiesen wird. Diese Kennung fungiert auch als reguläre Iota-Adresse, sodass Ihre NFTs Fonds, native Token oder andere NFTs besitzen können.
• Unveränderlich angebrachte Metadaten, die den dem Token zugrunde liegenden Vermögenswert beschreiben. Sie werden bei der Prägung festgelegt und dürfen während der gesamten Lebensdauer der NFT nicht geändert werden.
• Geprüfte Emittentenadresse, die sich nie ändern darf. Das Protokoll stellt sicher, dass eine NFT mit einem verifizierten Emittenten nur in einer Transaktion erstellt werden kann, die vom Emittenten kryptografisch signiert ist.

Transaktionen mit NFTs sind gebührenfrei, wie jede andere IOTA-Transaktion, und der aktuelle Besitzer hat die volle Kontrolle darüber, ob er den Token mit den angehängten Metadaten überträgt oder brennt. Die NFT-Ausgabe wurde mit Blick auf die Interoperabilität von Smart Contracts entwickelt, daher ist es möglich, sie als Teil einer Smart-Contract-Anfrage zu senden, um sie zum Beispiel als Sicherheit in einer Smart-Contract-Kette zu hinterlegen oder sie zur Versteigerung anzubieten.

Tokenisierung von Smart Contracts

IOTA Smart Contracts sind eine Layer-2-Erweiterung des Basis-Ledgers, die die leistungsstarke Welt der Smart Contracts und der Programmierbarkeit des Ledgers für IOTA Realität werden lässt. Smart Contracts werden in Smart Contract Chains ausgeführt, die von Layer 2 Validatoren betrieben werden. Da Smart Contracts quasi eine vollständige Turing-Programmierbarkeit bieten, erwecken sie eine Fülle von komplexen Tokenisierungsschemata zum Leben.

In der Tat werden die meisten Token auf dem heutigen Markt über Smart Contracts erstellt. Jeder von ihnen führt ein lokales Ledger innerhalb des Smart Contracts, das aufzeichnet, wer was besitzt. Dies bietet umfangreiche Funktionen und Kompositionsmöglichkeiten. Allerdings gibt es auch einen Nachteil für große Blockchains: geringe Leistung und kostspielige Smart-Contract-Ausführung.

Aus diesem Grund hat IOTA seine Smart-Contract-Plattform so konzipiert, dass sie über parallele Ketten horizontal skaliert werden kann. Diese Strategie stellt jedoch eine große Herausforderung dar: Wie kommunizieren Smart-Contract-Ketten miteinander und übertragen Werte untereinander? Die Antwort liegt auf der Hand: Sie verlassen sich auf das Tangle und das Native Tokenization Framework, um diese Aufgabe zu erledigen.

Asset Wrapping

Es ist nicht nur möglich, native Assets in Smart-Contract-Ketten zu hinterlegen, sondern die Ketten selbst können auch als Emittenten von nativen Assets fungieren. Jeder Smart Contract kann daher native Token ausgeben, die transparent zu dem spezifischen Smart Contract auf der spezifischen Kette zurückverfolgt werden können. Dieser Mechanismus bildet die Grundlage für vertrauenswürdige, garantierte Vermögensbrücken über mehrere Ketten hinweg.

Ein Smart Contract, der Layer-2-Token (z. B. ERC-20-Token) innerhalb einer Kette handhabt, kann mit Core Contracts interagieren, um Layer-2-Token in native Layer-1-Assets zu verpacken oder native Token, die zum Smart Contract gehören, in ihre Layer-2-Darstellung zu entpacken. Die Logik für die Umwandlung von Vermögenswerten wird von der virtuellen Maschine (VM) der Kette bereitgestellt; die Smart Contracts müssen lediglich den entsprechenden Kernvertrag in der Kette aufrufen, um den Vorgang durchzuführen.

Eine wichtige Eigenschaft dieses mehrschichtigen Tokenisierungsansatzes ist die Flexibilität:

• Smart-Contract-Token der Schicht 2 sind vollständig programmierbar und anpassbar, aber sie sind mit möglichen Gebühren für die Ausführung von Smart Contracts verbunden.
• Native Token der Schicht 1 nutzen die Leistung und Sicherheit des IOTA-Ledgers; außerdem fallen für sie keine Übertragungsgebühren an.
• Smart Contract Token können nahtlos in native Token umgewandelt werden und umgekehrt. IOTA Smart Contracts bieten integrierte Unterstützung für Entwickler.

Die beiden Token-Klassen lassen sich am besten durch die Metapher von Banken und Bargeld verstehen. Smart-Contract-Ketten sind Banken, die denjenigen, die ein Konto auf der on-chain haben, eine breite Palette von finanziellen Vermögenswerten, IOUs, Produkten und Dienstleistungen (Smart-Contract-Token) anbieten. Die Bank kann sich dafür entscheiden, Bargeld (native Token) zu drucken, das die oben genannten Vermögenswerte repräsentiert, die dann unabhängig von der Kontrolle der Banken in der Wirtschaft zirkulieren können (Schicht 1, Tangle).

Smart-Contract-Anfragen

Die Interaktion mit Smart-Contract-Ketten von regulären Layer-1-IOTA-Konten aus erfolgt über On-Ledger-Anfragen, die an das Layer-1-Konto der Kette gesendet werden. Solche Anfragen können native Token oder NFTs enthalten, die Teil der Anfrage sind. Ein Nutzer könnte sich dafür entscheiden, einige native Vermögenswerte in einer Kette zu hinterlegen und der Kette zu befehlen, sie zu entpacken, um ihr volles Potenzial freizusetzen.

Einige mögliche Anwendungsfälle für native Token in intelligenten Verträgen:

• Der Eigentümer der Kette beschließt, Gebühren für die Ausführung von Smart Contracts mit einem bestimmten nativen Token zu akzeptieren.
• Ein bestimmter Smart Contract kann nur ausgeführt werden, wenn die Gebühren mit einem bestimmten nativen Token bezahlt werden.
• Ein intelligenter Vertrag erfordert die Hinterlegung eines bestimmten nativen Tokens, um Funktionen für den Nutzer freizuschalten.
• Die Privilegien von Smart Contracts sind an das Vorhandensein eines bestimmten nativen Tokens gebunden. Kontrollrechte sind übertragbar, anstatt sie fest im Smart Contract zu kodieren.
• Eine Spiele-DApp akzeptiert spielinterne Gegenstände als NFTs von einem verifizierten Emittenten.

Die obige Liste ist bei weitem nicht vollständig; sie bietet vielmehr einen kleinen Einblick in die Möglichkeiten, die mit IOTA-Smart Contracts und dem nativen Tokenization Framework möglich sind.

Was kommt als Nächstes?

Mit der Veröffentlichung der Mainnet (Chrysalis)-Protokollspezifikationen für Smart Contracts und Tokenisierung beginnt für IOTA eine spannende Zeit. Die Spezifikationen werden uns dabei helfen, die neuen Protokollfunktionen zu implementieren und sie in die bestehenden Frameworks, Client-Bibliotheken und Entwickler-Tools zu integrieren.

Unser erster Meilenstein ist ein Hornet-basiertes Testnetz, in dem das Tokenization Framework aktiviert ist. Während wir auf dem Weg dorthin sind, hat die Arbeit an der Integration von IOTA Smart Contracts mit dem neuen Protokoll bereits begonnen.

Wir laden die Community und unsere Partner ein, die vorgeschlagenen Protokolländerungen durchzulesen und uns bei der Optimierung des Designs zu helfen, indem sie uns ihr Feedback und ihre Kommentare mitteilen. Beteiligen Sie sich an der Konversation auf GitHub oder sprechen Sie direkt mit unserem Team im Channel #digital-assets auf Discord.

Original by Levante Pap: https://blog.iota.org/iota-tokenization-framework-specifications/