Tutorial zur TON-Projektentwicklung (1): So erstellen Sie ein NFT auf der TON-Kette aus Quellcode-Perspektive

Autor: @Web3Mario (https://x.com/web3_mario)

Zusammenfassung: Im Anschluss an den vorherigen Artikel über. TON Technischer Einführungsartikel Ich habe die offiziellen Entwicklungsdokumente von TON in dieser Zeit eingehend studiert und habe das Gefühl, dass es immer noch einige Hindernisse beim Lernen gibt. Der aktuelle Dokumentinhalt scheint eher einem internen Entwicklungsdokument zu ähneln, was nicht sehr ist freundlich zu neuen Entwicklern. Daher versuche ich, eine Reihe von Artikeln über die TON Chain-Projektentwicklung auf der Grundlage meines eigenen Lernverlaufs zusammenzustellen. Ich hoffe, dass sie für alle hilfreich sein werden, damit sie schnell mit TON DApp beginnen können Entwicklung. Sollten sich beim Schreiben Fehler eingeschlichen haben, können Sie mich gerne korrigieren und gemeinsam lernen.

Was sind die Unterschiede zwischen der Entwicklung von NFT in EVM und der Entwicklung von NFT in TON Chain? ing one

FT oder NFT Es ist normalerweise das grundlegendste Bedürfnis für DApp-Entwickler. Deshalb nutze ich dies auch als Einstiegspunkt zum Lernen. Lassen Sie uns zunächst die folgenden Unterschiede zwischen der Entwicklung eines NFT im EVM-Technologie-Stack und in der

TON Chain

verstehen.NFT basierend auf EVM wählt normalerweise den Standard von ERC-721. Das sogenannte NFT bezieht sich auf eine unteilbare Art von Krypto-Asset, und jedes Asset ist einzigartig, das heißt, es weist bestimmte exklusive Eigenschaften auf. Und ERC-721 ist ein gängiges Entwicklungsparadigma für diese Art von Vermögenswerten. Werfen wir einen Blick darauf, welche Funktionen ein gemeinsamer ERC721-Vertrag erfüllen muss und welche Informationen erfasst werden. Das Bild unten zeigt eine ERC721-Schnittstelle. Sie sehen, dass im Gegensatz zu FT in der Überweisungsschnittstelle nicht der Betrag, sondern die zu übertragende tokenId eingegeben werden muss.Diese tokenId ist auch die grundlegendste Verkörperung der Einzigartigkeit von NFT. Um mehr Attribute zu tragen, wird natürlich normalerweise für jede tokenId ein Metadaten aufgezeichnet Metadaten ist ein externer Link, der andere skalierbare Daten des NFT speichert, wie z. B. einen Link zu einem PFP-Bild, bestimmte Attributnamen usw.

Für Entwickler, die mit Solidity oder objektorientiert vertraut sind, ist es einfach, einen solchen Smart Contract zu implementieren, solange die im Vertrag erforderlichen Datentypen definiert sind, wie z Einige Schlüsselzuordnungen Beziehung mapping und entsprechende Änderungslogik für diese Daten entsprechend den erforderlichen Funktionen entwickeln, können Sie ein NFT implementieren.

Allerdings ist in TON Chain alles anders. Es gibt zwei Hauptgründe für den Unterschied:

• Die Datenspeicherung in TON basiert auf Cell, und die Cell desselben Kontos wird durch einen gerichteten azyklischen Graphen implementiert. Dies bedeutet, dass die zu speichernden Daten nicht unbegrenzt wachsen können, da bei einem gerichteten azyklischen Diagramm die Abfragekosten durch die Tiefe der Daten bestimmt werden. Wenn sich die Tiefe ins Unendliche erstreckt, können die Abfragekosten zu hoch sein Der Vertrag steckt in einem Deadlock-Problem fest.
• Um eine hohe Parallelitätsleistung zu erzielen, hat TON die serielle Ausführungsarchitektur aufgegeben und stattdessen ein auf Parallelität ausgelegtes Entwicklungsparadigma, das Actor-Modell, übernommen, um die Ausführungsumgebung umzugestalten. Dies hat Auswirkungen. Smart Contracts können sich gegenseitig nur asynchron aufrufen Beachten Sie, dass dieses Prinzip gelten muss, unabhängig davon, ob es sich um einen Statusänderungstyp oder einen schreibgeschützten Typ handelt gefolgt, außer Darüber hinaus müssen Sie sorgfältig überlegen, wie Sie mit dem Daten-Rollback umgehen, wenn der asynchrone Aufruf fehlschlägt. Natürlich wurden im vorherigen Artikel weitere technische Unterschiede ausführlich besprochen. Dieser Artikel konzentriert sich auf die Entwicklung intelligenter Verträge und wird daher nicht behandelt. Die beiden oben genannten Designprinzipien machen einen großen Unterschied zwischen der intelligenten Vertragsentwicklung in

TON

und EVM.In der ersten Diskussion wussten wir, dass ein NFT-Vertrag einige Mapping-Beziehungen, also mapping, definieren muss, um NFT-bezogene Daten zu speichern. Das wichtigste ist Eigentümer. Dieses Mapping speichert die Zuordnungsbeziehung der Besitzeradresse einer bestimmten TokenID entsprechend NFT, die den Besitz und die Übertragung von NFT bestimmt Es handelt sich um eine Änderung dieser Eigentumsverhältnisse. Da es sich hierbei um eine Datenstruktur handelt, die theoretisch unbegrenzt sein kann, muss sie so weit wie möglich vermieden werden. Daher wird offiziell empfohlen, die Existenz unbegrenzter Datenstrukturen als Standard für das Sharding zu verwenden. Das heißt, wenn ähnliche Anforderungen an die Datenspeicherung bestehen, wird stattdessen das Master-Slave-Vertragsparadigma verwendet und die jedem Schlüssel entsprechenden Daten werden durch die Erstellung von Unterverträgen verwaltet. Und verwalten Sie globale Parameter über den Hauptvertrag oder helfen Sie bei der Abwicklung der internen Informationsinteraktion zwischen Unterverträgen.

Dies bedeutet auch, dass der NFT in TON auch mit einer ähnlichen Architektur entworfen werden muss. Jeder NFT ist ein unabhängiger Untervertrag, der Dinge wie die Eigentümeradresse speichert, Metadaten und andere exklusive Daten, und ein Hauptvertrag wird zur Verwaltung globaler Daten wie NFT-Name, Symbol, Gesamtangebot usw. verwendet.

Nach der Klärung der Architektur besteht der nächste Schritt darin, die Kernfunktionsanforderungen zu lösen. Aufgrund der Einführung dieser Master-Slave-Vertragsmethode Es ist also notwendig zu klären, welche Funktionen vom Hauptvertrag getragen werden Welche Funktionen werden vom Untervertrag übernommen und welche internen Informationen werden zwischen den beiden kommuniziert und wie werden die vorherigen Daten zurückgesetzt, wenn ein Ausführungsfehler auftritt? Normalerweise ist es vor der Entwicklung eines komplexen Großprojekts erforderlich, ein Klassendiagramm zu übergeben und den Informationsfluss untereinander zu klären und nach einem internen Anruffehler sorgfältig über die Rollback-Logik nachzudenken. Natürlich das oben genannte NFT Die Entwicklung ist einfach, aber eine ähnliche Überprüfung kann auch durchgeführt werden.

Lernen und entwickeln Sie TONintelligente Verträge aus dem Quellcode

TONEntwerfen Sie eine Klasse C Sprache, statische Typsprache mit dem Namen Func als Smart Contract Dann lassen Sie uns lernen, wie man TON Smart Contracts aus dem Quellcode entwickelt. Ich habe das NFT-Beispiel im offiziellen Dokument von TON ausgewählt, um es vorzustellen du selbst. Ein einfaches TON NFT Beispiel wird in diesem Fall umgesetzt. Werfen wir einen Blick auf die Vertragsstruktur, die in zwei funktionale Verträge und drei notwendige Bibliotheken unterteilt ist.

Diese beiden Hauptfunktionsverträge sind nach den oben genannten Grundsätzen gestaltet. Schauen wir uns zunächst den Code des Hauptvertrags nft-collection an:

Dies führt den ersten Wissenspunkt ein, wie man Daten in TON Smart Contracts dauerhaft speichert. Wir wissen, dass die dauerhafte Speicherung von Daten in Solidity von EVM gemäß den Parametern durchgeführt wird Normalerweise werden die Statusvariablen des Smart Contracts automatisch beibehalten und basierend auf dem neuesten Wert nach der Ausführung gespeichert. Dies ist jedoch bei Func nicht der Fall. Entwickler müssen die entsprechende Verarbeitungslogik selbst implementieren. Diese Situation ähnelt in gewisser Weise dem Prozess von C++, der GC berücksichtigen muss Aber andere neue Entwicklungssprachen automatisieren diesen Teil der Logik normalerweise. Werfen wir einen Blick auf den Code. Zuerst stellen wir einige erforderliche Bibliotheken vor und dann sehen wir, dass die erste Funktion load_data zum Lesen der dauerhaft gespeicherten Daten verwendet wird. Ihre Logik besteht darin, zunächst die persistenten Daten über zurückzugeben get_data Vertragsspeicher cell Beachten Sie, dass dies durch die Standardbibliothek stdlib.fc implementiert wird. Unter normalen Umständen können einige der Funktionen als Systemfunktionen verwendet werden.

Der Rückgabewerttyp dieser Funktion ist cell, was der cell-Typ in TVM ist. In der vorherigen Einführung wissen wir bereits, dass alle persistenten Daten in der TON -Blockchain im cell-Baum gespeichert sind. Jede Zelle hat höchstens 1023 Bits beliebiger Daten und bis zu vier Verweise auf andere Zellen. cell wird als Speicher im stapelbasierten TVM verwendet.cell speichert streng codierte Daten. Um die spezifischen Klartextdaten zu erhalten, müssen Sie cell in einen Typ namens slice konvertieren. cell kann mit der Funktion begin_parse in den Typ slice konvertiert werden, der dann durch Laden von Datenbits und Verweisen auf andere cell aus slice abgerufen werden kann Daten ein . Beachten Sie, dass diese Aufrufmethode in der Codezeile 15 syntaktischer Zucker in einer func ist, die die zweite Funktion direkt mit dem Rückgabewert der ersten Funktion aufrufen kann. Laden Sie schließlich die entsprechenden Daten in der Reihenfolge der Datenpersistenzreihenfolge.Beachten Sie, dass sich dieser Prozess von solidity unterscheidet und nicht auf Basis von hashmap aufgerufen wird, sodass die Reihenfolge der Aufrufe nicht durcheinander gebracht werden kann.

In der Funktion save_data ist die Logik ähnlich, mit der Ausnahme, dass es sich um einen umgekehrten Prozess handelt, der den nächsten Wissenspunkt einführt, einen neuen Typ Builder, das ist Der Zelltyp Baumeister. Datenbits und Verweise auf andere Zellen können in Buildern gespeichert werden, die dann in neue Zellen finalisiert werden können. Erstellen Sie zunächst einen Builder über die Standardfunktion begin_cell und speichern Sie verwandte Funktionen der Reihe nach über die store-bezogenen Funktionen. Beachten Sie, dass die oben genannte Aufrufreihenfolge mit der Speicherreihenfolge hier übereinstimmen muss.Schließlich wird die neue Zelle durch end_cell erstellt. Zu diesem Zeitpunkt wird die Zelle im Speicher verwaltet Der persistente Speicher von cell.

Als nächstes werfen wir einen Blick auf geschäftsbezogene Funktionen. Zunächst müssen wir den nächsten Wissenspunkt vorstellen, wie man einen neuen Vertrag durch einen Vertrag erstellt, der in der gerade eingeführten Master-Slave-Architektur häufig verwendet wird. Wir wissen, dass in TON Anrufe zwischen Smart Contracts durch das Senden interner Nachrichten implementiert werden. Dies wird durch eine Datei namens send_raw_message erreicht. Beachten Sie, dass der erste Parameter die messagecodierte cell ist und der zweite Parameter das Identifikationsbit ist, das zur Angabe der Transaktion verwendet wird Ausführungsmethoden, verschiedene Ausführungsmethoden des internen Nachrichtenversands sind in TON festgelegt, verfügt derzeit über 3 Arten von NachrichtenModi und 3Arten von NachrichtenFlags. Ein einzelner Modus kann mit mehreren (vielleicht keinen) Flags kombiniert werden, um den gewünschten Modus zu erhalten.Kombination bedeutet einfach die Summe ihrer Werte einzugeben. Die Beschreibungstabelle der Modi und Flags finden Sie unten:

Schauen wir uns also die erste Hauptfunktion an,

deploy_nft_item. Wie der Name schon sagt, handelt es sich hierbei um eine Funktion für Die Funktion, die eine neue NFT-Instanz erstellt oder umwandelt. Nach einigen Vorgängen zum Codieren einer msg wird der interne Vertrag über send_raw_message und das Senden von flag 1 gesendet ist das Identifikationsbit, nur die in der Codierung angegebene Gebühr wird als Gasgebühr für diese Ausführung verwendet. Nach der obigen Einführung können wir leicht erkennen, dass diese Codierungsregel der Art und Weise entsprechen sollte, einen neuen Smart Contract zu erstellen. Dann schauen wir mal, wie es umgesetzt wird.

Schauen wir uns direkt die Zeile 51 an. Die beiden oben genannten Funktionen sind Hilfsfunktionen, die zum Generieren der für Nachricht erforderlichen Informationen verwendet werden. Dies ist eine interne Nachricht Erstellen Sie einen intelligenten Vertrag. Im Codierungsprozess sind einige Zahlen in der Mitte tatsächlich einige Identifikationsbits, die zur Erläuterung der Anforderungen der internen Nachricht verwendet werden. Der nächste Wissenspunkt wird hier eingeführt. TON wählte einen Typ namens TL -B Binäre Sprache wird verwendet, um zu beschreiben, wie Nachrichten ausgeführt werden, und interne Nachrichten, die bestimmte spezifische Funktionen basierend auf dem Setzen verschiedener Flag-Bits implementieren. Die beiden am einfachsten vorstellbaren Verwendungsszenarien sind die Erstellung neuer Verträge und bereitgestellte Vertragsfunktionsaufrufe. Die Methode der Zeile 51 entspricht der ersteren und erstellt einen neuen nft-Artikel-Vertrag, der hauptsächlich über 55, 56, 57 erfolgt. Drei Zeilen sind angegeben.Erstens ist die große Zahlenreihe in der Zeile 55 eine Reihe von Identifikationsbits. Beachten Sie, dass der erste Eingabeparameter von store_uint ein numerischer Wert und der zweite eine Bitlänge ist. die bestimmt, ob die interne Nachricht durch den Vertrag erstellt wird, sind die letzten drei Markierungsbits, und die entsprechenden Binärwertbits sind 111 (das Dezimaläquivalent ist 4+2+1), wobei das erste Zwei geben an, dass die Nachricht von StateInit-Daten begleitet wird. Diese Daten sind der Quellcode des neuen Vertrags und die für die Initialisierung erforderlichen Daten. Das letztgenannte Flag-Bit zeigt den internen Nachrichtenanhang an, d. h. es wird erwartet, dass die relevante Logik und die erforderlichen Parameter ausgeführt werden. Daher werden Sie sehen, dass die dreistelligen Daten nicht in der Zeile 66 festgelegt sind, was auf einen Funktionsaufruf für den bereitgestellten Vertrag hinweist. Detaillierte Kodierungsregeln finden Sie hier.

Dann entsprechen die Kodierungsregeln von StateInit 49 Codezeilen, berechnet durch calculate_nft_item_state_init. Beachten Sie, dass auch die Kodierung von stateinitdata folgt ein etablierter TL- BCodierungsregeln umfassen mit Ausnahme einiger Flag-Bits hauptsächlich zwei Teile des neuen Vertrags Code und die Initialisierung Daten. Die Kodierungsreihenfolge von Daten muss mit der Speicherreihenfolge der persistenten Zelle übereinstimmen, die im neuen Vertrag festgelegt ist.Wie Sie in Zeile 36 sehen können, umfassen die Initialisierungsdaten item_index, das tokenId in ERC721 ähnelt, und die Standardfunktion mein _ Adresse Die aktuell zurückgegebene Vertragsadresse ist collection_address. Die Reihenfolge dieser Daten stimmt mit der Angabe in nft-item überein.

Der nächste Wissenspunkt ist, dass in TON alle nicht generierten Smart Contracts ihre generierten Adressen vorab berechnen können. Dies ähnelt der Funktion create2 in Solidity Die Adresse in TON besteht aus zwei Teilen, dem Workchain-Identifikationsbit und dem Hash-Wert von stateinit. Wir wissen bereits, dass ersteres für das entsprechende TON ist Der für die Infinite-Sharding-Architektur angegebene Wert ist derzeit ein einheitlicher Wert. Erhalten aus der Standardfunktion workchain. Letzteres wird durch die Standardfunktion cell_hash erhalten. Zurück zu diesem Beispiel: calculate_nft_item_address ist eine Funktion, die die neue Vertragsadresse vorab berechnet. Und kodieren Sie den generierten Wert in Zeile 53 in message als Empfangsadresse der internen Nachricht.Und nft_content entspricht dem Initialisierungsaufruf des erstellten Vertrags. Die spezifische Implementierung wird im nächsten Artikel vorgestellt.

Was send_royalty_params betrifft, muss es eine Antwort auf die interne Nachricht einer schreibgeschützten Anfrage sein. In der vorherigen Einleitung haben wir ausdrücklich betont, dass die interne Nachricht in TON nicht nur Enthält mögliche Änderungen. Datenoperationen und schreibgeschützte Operationen müssen ebenfalls auf diese Weise implementiert werden. Daher ist dieser Vertrag eine solche Operation. Das erste, was zu beachten ist, ist, dass die Zeile 67 die Markierung der Rückruffunktion des Anforderers angibt Auf die Anfrage antworten. Das sind die zurückgegebenen Daten, nämlich der angeforderte Artikelindex und die entsprechenden Lizenzgebühren.

Lassen Sie uns den nächsten Wissenspunkt vorstellen. In TON gibt es nur zwei einheitliche Eingänge mit den Namen recv_internal und recv_external, wobei ersterer die Vereinheitlichung aller internen Nachrichten ist Anrufeintrag, letzterer ist ein einheitlicher Anrufeintrag für alle externen Nachrichten. Entwickler müssen innerhalb der Funktion eine Methode ähnlich switch verwenden, um auf verschiedene Anfragen basierend auf den verschiedenen Flag-Bits zu reagieren, die durch message angegeben werden. Hier ist das Markierungsbit die Rückruffunktionsmarkierung der obigen Zeile 67. Zurück zu diesem Beispiel: Führen Sie zunächst eine Stellenprüfung für message durch und analysieren Sie dann die Informationen in message. Analysieren Sie zunächst die Zeile 83, um sender_address zu erhalten . Die Parameter werden für nachfolgende Berechtigungsprüfungen verwendet. Beachten Sie, dass die ~-Operatoren hier ein weiterer syntaktischer Zucker sind. Ich werde hier nicht näher darauf eingehen.Als nächstes werden die op-Operationsflagbits analysiert und dann werden die entsprechenden Anforderungen entsprechend den verschiedenen Flagbits verarbeitet. Unter diesen werden die oben genannten Funktionen jeweils nach einer bestimmten Logik aufgerufen. Reagieren Sie beispielsweise auf eine Anfrage für den Parameter royalty oder prägen Sie ein neues nft und erhöhen Sie den globalen index.

Der nächste Wissenspunkt entspricht Zeile 108. Ich glaube, Sie können die Verarbeitungslogik dieser Funktion auch kennen, indem Sie sie benennen. Sie ähnelt der Funktion require in Solidity Func Ausnahmen werden durch die Standardfunktion throw_unless ausgelöst. Der erste Eingabeparameter ist der Fehlercode und der zweite dient zur Überprüfung des Bit-Booleschen Werts wird mit dem Fehlercode ausgegeben. In dieser Zeile wird equal_slices verwendet, um zu bestimmen, ob die oben analysierte sender_address mit dem owner_address der dauerhaften Speicherung des Vertrags übereinstimmt, und um eine Genehmigungsbeurteilung vorzunehmen.

Um die Codestruktur klarer zu machen, wurden schließlich eine Reihe von Hilfsfunktionen entwickelt, die dabei helfen, Persistenzinformationen zu erhalten. Sie können hier nicht auf diese Struktur zurückgreifen, um ihren eigenen Smart zu entwickeln Verträge.

TONökologische DAppEntwicklung ist wirklich eine interessante Sache und unterscheidet sich stark vom Entwicklungsparadigma von EVM, daher werde ich in einer Reihe vorstellen, wie man in TON Chain entwickelt von Artikeln Entwickelt in DApp. Lernen Sie gemeinsam mit allen und nutzen Sie diese Welle an Möglichkeiten. Gerne können Sie auch mit mir auf Twitter interagieren, um auf neue und interessante Dapp-Ideen zu stoßen und diese gemeinsam weiterzuentwickeln.

Das obige ist der detaillierte Inhalt vonTutorial zur TON-Projektentwicklung (1): So erstellen Sie ein NFT auf der TON-Kette aus Quellcode-Perspektive. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!