Tokenisierung

Tokenisierung ist ein Prozess, bei dem physische oder digitale Assets durch Token dargestellt werden, die auf einer Blockchain übertragen, verfolgt und gespeichert werden können.

Indem Sie Vermögenswerte als Token darstellen, können Sie das Blockchain-Ledger verwenden, um den Status und das Eigentum an einem Vermögenswert festzulegen, und Standardfunktionen der Blockchain-Plattform verwenden, um das Eigentum an einem Vermögenswert zu übertragen.

Blockchain App Builder umfasst die Tokenisierungsunterstützung: Tokenklassen und -methoden werden automatisch generiert, und zusätzliche Tokenmethoden werden bereitgestellt, damit Entwickler komplexe Geschäftslogik für Token erstellen können. Das automatisch generierte Projekt enthält Tokenlebenszyklusklassen und -funktionen, CRUD-Methoden und zusätzliche Token-SDK-Methoden und unterstützt die automatische Validierung von Argumenten, das Marshalling/Unmarshalling und die transparente Persistenzfunktion. Mit diesen Controller-Methoden können Sie Token initialisieren, den Zugriff kontrollieren, Konten einrichten, Rollen verwalten und den Lebenszyklus von Token verwalten.

Das folgende Diagramm zeigt die Tokenarchitektur, die von Blockchain App Builder implementiert wird, einschließlich der Token-API und des Token-SDK.Tokenarchitekturdiagramm

Automatisch generierte Token-API
Blockchain App Builder generiert automatisch Methoden zur Unterstützung von Token und Token-Lebenszyklen. Mit diesen Methoden können Sie Token initialisieren, Rollen und Accounts verwalten und andere Tokenlebenszyklusaufgaben ohne zusätzliche Codierung abschließen.
Token-SDK
Das Token-SDK enthält Methoden, mit denen Sie komplexe Geschäftslogik für Tokenanwendungen entwickeln können.
Multiversion Concurrency Control (MVCC)-Optimierung
Die MVCC-Optimierung für Token Chaincode kann Fehler bei Transfer-, Mint-, Burn- und Hold-Vorgängen reduzieren.

Token und das Konto-/Saldenmodell

Blockchain App Builder unterstützt fungible und nicht fungible Token.

Fungible Token haben einen austauschbaren Wert. Jede Menge fungierbarer Token hat denselben Wert wie jede andere gleiche Menge derselben Tokenklasse. Nicht fungible Token sind einzigartig. Token können auch ganz oder fraktioniert sein. Bruchzeichen können in kleinere Teile unterteilt werden, basierend auf einer bestimmten Anzahl von Dezimalstellen.

Token können auch durch Verhaltensweisen beschrieben werden. Unterstützte Verhaltensweisen für fungible Token: mintable, transferable, divisible, holdable, burnable und roles (minter, burner und holder). Unterstützte Verhaltensweisen für nicht fungible Token sind: mintable, transferable, singleton, indivisible, burnable und roles (minter und burner).

Das Tokenisierungsfeature verwendet ein Konto-/Saldenmodell, um tokenisierte Assets als Salden in einem Konto darzustellen. Konten ähneln typischen Bankkonten, bei denen Einzahlungen und Überweisungen und andere Zustandsübergänge den Saldo eines Kontos beeinflussen. Der Saldo jedes Kontos wird global verfolgt, um sicherzustellen, dass die Transaktionsbeträge gültig sind. Der Saldo (für fungible Token) und die Transaktionshistorie werden ebenfalls verfolgt.

Jeder Benutzer, der Token besitzt oder tokenbezogene Vorgänge zu einem beliebigen Zeitpunkt ausführt, muss über ein Konto im Netzwerk verfügen. Jedes Konto wird durch eine eindeutige ID (account_id) identifiziert. Die Account-ID wird erstellt, indem ein Benutzername oder eine E-Mail-ID (user_id) des Instanzeigentümers oder des Benutzers, der bei der Instanz angemeldet ist, mit der Mitgliedsdienstanbieter-ID (org_id) des Benutzers in der aktuellen Netzwerkorganisation kombiniert wird. Für die Kontoerstellung werden einsatzbereite Methoden bereitgestellt. Da die Konto-ID die Organisations-ID enthält, können Benutzer über mehrere Organisationen hinweg unterstützt werden.

Tokenstandards

Blockchain App Builder erweitert die Standards und Klassifizierungen des Token Taxonomy Framework, des ERC-721-Standards und des ERC-1155-Standards, um die Anatomie und das Verhalten von Token zu definieren.

ERC-1155 ist ein Standard, der sowohl fungible als auch nicht fungible Token (NFTs) unterstützt. ERC-721 ist ein Standard für NFTs. Das Token Taxonomy Framework wurde von der Token Taxonomy Initiative entwickelt. Weitere Informationen finden Sie unter Tokentaxonomie-Framework.

In der folgenden Tabelle werden die Tokentypen beschrieben, die Blockchain App Builder unterstützt:
Standard Unterstützte Tokentypen
Token-Taxonomie-Framework
  • fraktionierte fungible Token
ERC-721
  • ganze nicht fungible Token
ERC-1155
  • ganze fungierende Token
  • fraktionierte fungible Token
  • ganze nicht fungible Token
  • Fraktionale nicht fungible Token

Tokenisierungsablauf

Da Blockchain App Builder die Tokenisierung unterstützt, indem die Syntax der Eingabespezifikationsdatei erweitert wird, erstellen Sie tokenspezifische Projekte auf die gleiche Weise wie andere Projekte, entweder mit der CLI oder in Visual Studio Code.

Weitere Informationen zum Erstellen von Projekten mit Blockchain App Builder finden Sie unter Eingabespezifikationsdatei.

Tokenworkflowdiagramm
Ein typischer Tokenisierungsablauf folgt diesen grundlegenden Schritten:
  • Entscheiden Sie, welcher Tokenstandard verwendet werden soll.
  • Entscheiden Sie, welches Tokenverhalten angegeben werden soll (mintable, transferable, divisible, indivisible, singleton, holdable, burnable und roles).
  • Definieren Sie das Tokenasset und seine Eigenschaften in der Eingabespezifikationsdatei.
  • Erstellen Sie das Chaincode-Projekt aus der Eingabespezifikationsdatei. Dadurch wird ein gerüstetes Projekt erstellt, einschließlich eines Modells, das die Tokenassetdefinition und ihre Eigenschaften enthält, und eines Controllers, der das Verhalten und die Methoden des Tokens enthält.
  • Das Chaincode-Projekt bereitstellen und testen.
Nachdem Sie ein tokenbasiertes Projekt bereitgestellt haben, führt der typische Ablauf zum Erstellen von Token und zum Abschließen von Lebenszyklusvorgängen die folgenden Schritte aus:
  • Ein Token-Chaincode wird bereitgestellt. Die an die Initialisierungsmethode übergebenen Benutzer in der Liste werden zu Token Admin-Benutzern des Chaincodes.
  • Ein tokenisiertes Asset wird initialisiert. Dadurch wird token_id erstellt, eine eindeutige ID für diese bestimmte Instanz des Tokens.
  • Konten müssen für jeden Benutzer erstellt werden, der Token oder vollständige tokenbezogene Vorgänge besitzt.
  • Wenn das Verhalten roles für das Token angegeben ist, müssen Rollen Benutzern zugewiesen werden, bevor sie tokenbezogene Vorgänge abschließen können.
  • Tokenlebenszyklusmethoden können dann basierend auf den Verhaltensweisen verwendet werden, die für das Tokenasset angegeben wurden. Beispiel: Sie können eine Methode zum Mintieren von Token für ein Konto aufrufen.

Zugriffskontrolle

Die Tokenisierungsunterstützung umfasst eine Zugriffskontrollfunktion, die sowohl rollenbasierte als auch eigentumsbasierte Kontrollmechanismen unterstützt.

Mit rollenbasierter Kontrolle können Benutzer bestimmte Methoden mit einer zugehörigen Rolle aufrufen, wie Token Admin oder Token Minter. Mit eigentumsbasierter Kontrolle können Sie den Zugriff von Benutzern auf Assets einschränken, deren Eigentümer sie nicht sind. Mit der eigentumsbasierten Zugriffskontrolle können bestimmte Methoden von den Benutzern aufgerufen werden, die Eigentümer der Assets sind, wie Token Owner oder Account Owner. Spezifische Informationen zur Zugriffskontrolle für Methoden finden Sie in den einzelnen Einträgen für die Methoden, die in den folgenden Themen dokumentiert sind:
Die rollenbasierte Zugriffskontrolle unterstützt folgende Personas:
Tokenadministration
Token Admin-Benutzer können zugewiesen werden, wenn ein Token Chaincode bereitgestellt wird. Die Benutzerinformationen Token Admin werden in der Statusdatenbank gespeichert. Ein Token Admin-Benutzer kann Token Admin-Berechtigungen für andere Benutzer erteilen und entfernen. Ein Token Admin-Benutzer kann seine eigenen Token Admin-Berechtigungen nicht entfernen. Ein Token Admin-Benutzer kann jedem Benutzer die Rolle Org Admin, Minter, Burner oder Notar zuweisen.
Organisationsadministrator
Die erweiterten Token Taxonomy Framework-Methoden unterstützen die Rolle Org Admin. Ein Token Admin-Benutzer kann die Rolle Org Admin jedem Benutzer zuweisen. Org Admin-Benutzer haben Administratorberechtigungen, jedoch nur innerhalb ihrer Organisation. Sie können Konten erstellen oder Kontensalden anzeigen, jedoch nur für Benutzer in ihrer Organisation. Org Admin-Benutzer mit einer Minter-, Burner- oder Notarrolle können diese Rolle anderen Benutzern in ihrer Organisation zuweisen.
Tokenminter
Ein Benutzer, dem die Minter-Rolle zugewiesen ist, ist eine Token Minter-Rolle und kann Token prägen.
Token-Burner
Ein Benutzer, dem die Brennerrolle zugewiesen ist, ist eine Token Burner und kann Token brennen.
Tokennotar
Ein Benutzer, dem die Notarrolle zugewiesen ist, ist Token Notary. Eine Token Notary fungiert als Dritter bei Transaktionen zwischen Zahlern und Zahlungsempfängern. Eine Token Notary kann entweder den Abschluss einer Tokenübertragung von einem Zahler an einen Zahlungsempfänger auslösen oder die Token stattdessen auf das Konto des Zahlers zurückgeben.
Vault-Manager
Ein Benutzer, dem die Vault-Rolle zugewiesen ist, ist Vault Manager. Die Vault Manager kann eine gesperrte NFT entsperren. Die Vault-Rolle gilt nur für die erweiterten ERC-721- und ERC-1155-Standards. Die Zuweisung der Vault-Rolle zu einem Benutzer ist eine Voraussetzung für das Sperren von NFTs. Der Vault-Rolle kann nur ein Benutzer pro Chaincode zugewiesen werden.
Tokenauditor
Nur Digital Assets Edition: Die erweiterten Token Taxonomy Framework-Methoden unterstützen die Rolle Token Auditor. Diese Rolle ähnelt der Rolle Token Admin, hat jedoch nur Lesezugriff.
Organisationsauditor
Nur Digital Assets Edition: Die erweiterten Token Taxonomy Framework-Methoden unterstützen die Rolle Org Auditor. Diese Rolle ähnelt der Rolle Org Admin, hat jedoch nur Lesezugriff.
Die eigentumsbasierte Zugriffskontrolle unterstützt die folgenden Personas:
Accounteigentümer
Jeder Benutzer mit einem Account ist ein Account Owner.
Tokeneigentümer
Jeder Benutzer, der derzeit Eigentümer eines nicht fungierbaren Tokens ist, ist die Token Owner dieses Tokens.

Rollenbasierte Zugriffskontrolle und eigentumsbasierte Zugriffskontrolle werden auch in einigen Methoden kombiniert. Beispiel: Mit der rollenbasierten Zugriffskontrolle kann ein Benutzer mit der Rolle "Miner" Token erstellen. Mit einer eigentumsbasierten Zugriffskontrolle kann ein nicht fungierbarer Tokeneigentümer die benutzerdefinierten Eigenschaften eines Tokens ändern, die Tokenmetadaten jedoch nicht ändern. Wenn ein Benutzer mit der Rolle "Miner" ein nicht fungierbares Token (NFT) erstellt, wird er Eigentümer der NFT. Als Eigentümer dieser NFT können sie die benutzerdefinierten Eigenschaften ändern (für ein Art Collection Token ist der Tokenpreis eine benutzerdefinierte Eigenschaft). Nachdem der Tokenersteller die NFT an einen anderen Benutzer übertragen hat, wird der zweite Benutzer zum Eigentümer, und der Benutzer, der das Token erstellt hat, ist nicht mehr der Eigentümer des Tokens. Aufgrund der eigentumsbasierten Zugriffskontrolle kann der neue Eigentümer jetzt einen benutzerdefinierten Eigenschaftswert aktualisieren, der vorherige Eigentümer kann dies jedoch nicht mehr tun. Aufgrund der rollenbasierten Zugriffskontrolle kann der vorherige Eigentümer immer noch eine NFT prägen, der neue Benutzer jedoch nicht.

Sie können auch eigene Zugriffskontrollfunktionen schreiben oder die Zugriffskontrolle deaktivieren. Der automatisch generierte Code, der den Zugriff kontrolliert, wird in den folgenden Beispielen angezeigt.

TypeScript:
await this.Ctx.<Token Standard>Auth.checkAuthorization(...)
Start:
auth, err := t.Ctx.<Token Standard>Auth.CheckAuthorization(...)

Hinweis:

Um die automatisch generierte Zugriffskontrollfunktion zu entfernen, entfernen Sie die vorherige Codezeile aus Ihrem TypeScript- oder Go-Projekt.

MVCC Optimierung

Hyperledger Fabric-Datenbanken verwenden MVCC (Multiversions Concurrency Control), um Doppelausgaben und Dateninkonsistenzen zu vermeiden.

Wenn derselbe Status aktualisiert wird, überschreibt eine neue Version des Datensatzes die alte Version. Wenn nebenläufige Anforderungen zur Aktualisierung desselben Schlüssels in einem Block vorhanden sind, wird möglicherweise ein MVCC_READ_CONFLICT-Fehler generiert.

Um MVCC-Fehler bei Transfer-, Mint-, Burn- und Hold-Vorgängen zu reduzieren, können Sie die MVCC-Optimierung für Token Chaincode aktivieren. Diese Optimierung funktioniert nur auf Oracle Blockchain Platform. Standardmäßig ist die Optimierung deaktiviert. Um die Optimierung zu aktivieren, führen Sie den entsprechenden folgenden Schritt aus.

  • CLI: Geben Sie den booleschen Parameter -m oder --enable_mvcc_optimization mit dem Befehl ochain init an. Standardmäßig ist der Parameter auf false gesetzt. Um die Optimierung zu aktivieren, fügen Sie der ochain init-Befehlszeile -m true hinzu.
  • Visual Studio Code: Wenn Sie einen Chaincode erstellen, wählen Sie im Fenster Chaincode erstellen die Option MVCC-Optimierung aktivieren aus.

Gehen Sie folgendermaßen vor, um die Optimierung mit Chaincode zu verwenden, der in früheren Versionen von Blockchain App Builder erstellt wurde:

  1. Nachdem Sie die neueste Version von Blockchain App Builder installiert haben, aktualisieren Sie den Chaincode wie unter Chaincode-Projekte in der CLI upgraden und Chaincode-Projekte in Visual Studio Code upgraden beschrieben.
  2. Bearbeiten Sie die Datei .ochain.json im Root-Ordner des Chaincodes, um enableMvccOptimization auf true zu setzen.
  3. Synchronisieren Sie den Chaincode, der die Optimierung hinzufügt und zwei neue Ordner im Stammordner des Chaincodes erstellt: statedb und tokens. Weitere Informationen zur Synchronisierung finden Sie unter Änderungen an Spezifikationsdatei mit generiertem Quellcode synchronisieren und Änderungen an Spezifikationsdatei mit generiertem Quellcode synchronisieren.

Weitere Methoden zur Umgehung von MVCC_READ_CONFLICT-Fehlern umfassen die Wiederholungsanforderungen der Clientanwendung, wenn dieser Fehler generiert wird, oder die Verwendung einer Queue zum Erfassen gleichzeitiger Anforderungen, bevor sie an das Blockchain-Netzwerk gesendet werden. Weitere Informationen finden Sie unter Read-Write set semantics in der Hyperledger Fabric-Dokumentation.

Hinweis:

Die MVCC-Optimierung funktioniert nicht in hybriden Netzwerken, die sowohl Oracle Blockchain Platform- als auch Hyperledger Fabric-Peers umfassen, oder beim Testen in einem lokalen Hyperledger Fabric-Netzwerk. Aktivieren Sie die MVCC-Optimierung nicht in hybriden Netzwerken, da dies zu Inkonsistenzen zwischen Peers führen kann.