04’Nov’21
Übersetzung des Blogartikel von Autor Levente Pap, IOTA Foundation.
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 Tangle und erben die gebührenfrei und skalierbare Natur der Basiswährung, dem IOTA Coin. Ein vertrauenswürdiger Brückenmechanismus des Native Tokenization Frameworks stellt sicher, dass Smart-Contract-Token mühelos in native Token ge-wrapped (dt. eingewickelt) und aus ihnen aus-ge-wrapped (dt. ausgewickelt) werden können. Die Protokollspezifikationen werden derzeit überprüft und die Arbeit an der Testnet-Implementierung hat bereits begonnen.
Die 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 erforscht, welches für das IOTA 2.0 DevNet im Juni 2021 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 Assets (dt. Vermögenswerte) direkt auf dem Tangle minten (dt. prägen), die dann wie IOTA-Coins gebührenfrei übertragbar sind.
Durch das Experimentieren mit digitalen Assets 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 Assets ein wichtiger Baustein des gesamten IOTA-Technologie-Stacks sind. In diesem Token-Wunderland fließen die Assets nahtlos und vertrauensvoll zwischen Smart-Contract-Chains und Benutzerkonten. Sie können ohne zentralisierte Brückenlösungen ge-wrapped oder un-wrapped werden. Es steht jedem frei, seine eigenen Token zu erstellen und zu verwalten. Schließlich geht es bei IOTA um Freiheit.
Heute sind wir stolz darauf, 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.
Die Umwandlung von IOTA in einen 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, in dem auch die Basiswährung geführt wird. Da der Basis-Ledger von IOTA gebührenfrei Transaktionen ermöglicht, ist ein Multi-Asset-Ledger von IOTA in der Lage, gebührenfrei 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 werden, zu halten und zu übertragen. Es ist nicht mehr notwendig, IOTA-Coins zu “taggen” oder zu “färben” > Keine Colored Coins mehr: alle nativen Token sind eigenständige Token im Ledger, die von Foundries (dt. Gießerei/Prägerei) ins Leben gerufen werden.
Native Token werden von den Nutzern in den IOTA-Ledger injiziert; daher werden sie auch als user-defined tokens (dt. Nutzer-definiert) bezeichnet. Sie verbrauchen wertvolle Ressourcen der Nodes, die das Netzwerk unterhalten, vor allem Speicherplatz. Infolgedessen muss jedes Konto, das native Token hält, eine Kaution in IOTA-Coins hinterlegen, um den übermäßigen Ressourcenverbrauch zu kompensieren.
Token-Foundries
Der Schöpfer des nutzerdefinierten Tokens, der als Emittent bezeichnet wird, hat die Kontrolle über die Token-Foundry und regelt die Mint- oder Burn-Aktivität (dt. prägen oder verbrennen) der Token, die zur Foundry gehören.
Jeder kann Emittent werden und mit dem Minten 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 z.B. Minting oder Burning Flow Control, werden iterativ zum Framework hinzugefügt, während die Implementierung voranschreitet.
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-Chainadresse sein. Es ist auch möglich, Emittentenrechte auf andere Entitäten zu übertragen, aber es ist verboten, die bei der Einrichtung der Foundry definierte Angebotskontrollpolitik zu ändern, was eine unglaubliche Vielfalt von Anwendungsfällen ermöglicht, die weit über eine bloße Färbung von Token (Colored Coins) 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 über folgende Punkte 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 Chain; alles über einen Token kann on-chain dokumentiert und gespeichert werden, direkt im UTXO-Ledger vom 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 Emittenten-Identitäten, die mit realen Identitäten verknüpft sind, können Wallets automatisch die Authentizität aller nativen Token feststellen.
Non-Fungible Token
Token-Foundries eignen sich hervorragend für fungible Token, aber sie können auch nicht-fungible Token (NFTs) produzieren. Ein Token-Foundry, der den maximalen Vorrat auf 1 festlegt, kontrolliert im Wesentlichen nur einen Token, der im Ledger global einzigartig ist; daher handelt es sich 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 Foundry kontrollierte native NFT kann auf beliebige Konten im Ledger übertragen werden, die On-Chain-Metadaten verbleiben jedoch bei der Foundry. Außerdem behält der Emittent die Kontrolle über das Burning 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:
- Einen weltweit eindeutigen Identifikator, der beim Minting zugewiesen wird. Diese Kennung fungiert auch als reguläre Iota-Adresse, so dass Ihre NFTs Fonds, native Token oder andere NFTs besitzen können.
- Unveränderlich angehängte Metadaten, die den zugrunde liegenden Vermögenswert des Tokens beschreiben. Sie werden beim Minting festgelegt und dürfen während der gesamten Lebensdauer des NFT nicht geändert werden.
- Geprüfte Emittentenadresse, die sich nie ändern darf. Das Protokoll stellt sicher, dass ein 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 transferiert oder burnt. Die NFT-Output 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-Chain zu hinterlegen oder sie zur Versteigerung anzubieten.
Tokenisierung von Smart Contracts
IOTA Smart Contracts sind eine 2-Layer-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 2-Layer 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, in dem aufgezeichnet wird, wem was gehört. 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 Chains horizontal skaliert werden kann. Diese Strategie stellt jedoch eine große Herausforderung dar: Wie kommunizieren Smart-Contract-Chains 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 erfüllen.
Asset Wrapping
Es ist nicht nur möglich, native Assets in Smart-Contract-Chains zu hinterlegen, sondern die Chains selbst können auch als Emittenten von nativen Assets auftreten. Jeder Smart Contract kann daher native Token ausgeben, die transparent zu dem spezifischen Smart Contract auf der spezifischen Chain zurückverfolgt werden können. Dieser Mechanismus bildet die Grundlage für vertrauenswürdige, garantierte Asset-Bridges über mehrere Chains hinweg.
Ein Smart Contract, der 2-Layer-Token (z. B. ERC-20-Token) innerhalb einer Chain handhabt, kann mit Core Contracts interagieren, um 2-Layer-Token in native 1-Layer Assets zu wrappen oder native Token, die zum Smart Contract gehören, in ihre 2-Layer-Repräsentation zu un-wrappen. Die Logik für das Wrappen von Assets wird von der virtuellen Maschine (VM) der Chain bereitgestellt; Smart Contracts müssen lediglich den entsprechenden Core Contract auf der Chain aufrufen, um den Vorgang durchzuführen.
Eine wichtige Eigenschaft dieses Multi-Layer-Tokenization-Ansatzes ist die Flexibilität:
- Smart-Contract-Token des 2-Layer 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 des 1-Layer nutzen die Leistung und Sicherheit des IOTA-Ledgers; außerdem fallen für sie keine Transaktionsgebühren an.
- Smart Contract Token können nahtlos in native Token umgewandelt werden und umgekehrt. IOTA Smart Contracts bieten integrierte Supportfunktionen für Entwickler.
Die beiden Token-Klassen lassen sich am besten durch die Metapher von Banken und Bargeld verstehen. Smart-Contract-Chains sind Banken, die denjenigen, die ein Konto auf der Chain haben, eine breite Palette von finanziellen Assets, IOUs, Produkten und Dienstleistungen (Smart-Contract-Tokens) anbieten. Die Bank kann sich dafür entscheiden, Bargeld (native Token) zu drucken, das die oben genannten Assets repräsentiert, die dann in der Wirtschaft ( 1-Layer, Tangle) unabhängig von der Kontrolle der Banken zirkulieren können.
Smart-Contract-Anfragen
Die Interaktion mit Smart-Contract-Chains von regulären IOTA-Konten des 1-Layer erfolgt über On-Ledger-Anfragen, die an das 1-Layer-Konto der Chain 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 Assets in einer Chain zu hinterlegen und der Chain zu befehlen, sie zu un-wrappen, um ihr volles Potenzial freizusetzen.
Einige mögliche Anwendungsfälle für native Token in Smart Contracts:
- Der Eigentümer der Chain beschließt, Gebühren für die Ausführung von Smart Contracts in 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 Smart Contract 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 das, was mit IOTA Smart Contracts und dem nativen Tokenization Framework möglich ist.
Was kommt als Nächstes?
Mit der Veröffentlichung der Mainnet (Chrysalis)-Protokollspezifikationen für Smart Contracts und Tokenization 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.
Quellen
https://blog.iota.org/iota-tokenization-framework-specifications/