Geschrieben von: @Web3Mario

Einleitung: Mit der Einführung von Notcoin, dem größten Spiel im TON-Ökosystem, auf Binance und dem enormen Vermögenseffekt, der durch das vollständig zirkulierende Token-Wirtschaftsmodell verursacht wird, hat TON in kurzer Zeit große Aufmerksamkeit auf sich gezogen. Nachdem ich mich mit einem Freund unterhalten hatte, erfuhr ich, dass die technische Schwelle von TON relativ hoch ist und dass sich das DApp-Entwicklungsparadigma stark von den gängigen Protokollen der öffentlichen Kette unterscheidet. Daher habe ich einige Zeit damit verbracht, eingehende Recherchen zu verwandten Themen durchzuführen und einige Erkenntnisse mit Ihnen zu teilen. Kurz gesagt, das Kernkonzept von TON besteht darin, das traditionelle Blockchain-Protokoll „von unten nach oben“ zu rekonstruieren und auf Kosten der Interoperabilität eine hohe Parallelität und Skalierbarkeit zu erreichen.

Die Kerndesignidee von TON ist hohe Parallelität und hohe Skalierbarkeit

Man kann sagen, dass der Zweck aller komplexen Technologieauswahlen in TON im Streben nach hoher Parallelität und hoher Skalierbarkeit liegt. Vor dem Hintergrund seiner Entstehung ist es für uns natürlich nicht schwer, dies zu verstehen. TON oder The Open Network ist ein dezentrales Computernetzwerk, das eine L1-Blockchain und mehrere Komponenten umfasst. TON wurde ursprünglich vom Telegram-Gründer Nikolai Durov und seinem Team entwickelt und wird heute von einer globalen Community unabhängiger Mitwirkender unterstützt und gepflegt. Seine Geburtsstunde geht auf das Jahr 2017 zurück, als das Telegram-Team begann, selbst Blockchain-Lösungen zu erforschen. Da zu diesem Zeitpunkt keine bestehende L1-Blockchain die neunstellige Benutzerbasis von Telegram unterstützen konnte, beschlossen sie, eine eigene Blockchain zu entwerfen, die damals Telegram Open Network hieß. Im Jahr 2018 war es soweit. Um die nötigen Ressourcen für die Implementierung von TON zu erhalten, startete Telegram im ersten Quartal 2018 einen Verkauf von Gram-Tokens (später in Toncoin umbenannt). Im Jahr 2020 zog sich das Telegram-Team aufgrund regulatorischer Probleme aus dem TON-Projekt zurück. Anschließend übernahm eine kleine Gruppe von Open-Source-Entwicklern und Gewinnern des Telegram-Wettbewerbs die Codebasis von TON, benannte das Projekt in The Open Network um und entwickelt die Blockchain bis heute aktiv weiter, wobei sie sich an die im ursprünglichen TON-Whitepaper dargelegten Prinzipien hält.

Da es als dezentrale Ausführungsumgebung für Telegram konzipiert ist, muss es sich natürlich mit zwei Problemen auseinandersetzen: einer hohen Anzahl gleichzeitiger Anfragen und einer großen Datenmenge. Wir wissen, dass Solana, das als das höchste TPS bekannt ist, mit der Entwicklung der Technologie bis heute bekannt ist. hat die höchste gemessene TPS 65.000, was offensichtlich nicht ausreicht, um das Telegram-Ökosystem zu unterstützen, das Millionen von TPS benötigt. Gleichzeitig hat die groß angelegte Anwendung von Telegram bereits den Himmel überschritten. Da es sich um ein äußerst redundantes verteiltes System handelt, muss jeder Knoten im Netzwerk eine vollständige Kopie der Daten speichern auch unrealistisch.

Um die beiden oben genannten Probleme zu lösen, hat TON daher zwei Optimierungen an den gängigen Blockchain-Protokollen vorgenommen:

  • Durch die Übernahme des „Infinite Sharding Paradigma“ beim Entwurf des Systems lösen wir das Problem der Datenredundanz, sodass es große Datenmengen transportieren und das Problem des Leistungsengpasses lindern kann.

  • Durch die Einführung einer vollständig parallelen Ausführungsumgebung basierend auf dem Actor-Modell wird das Netzwerk-TPS erheblich verbessert;

Erstellen Sie eine Blockchain-Kette – durch unbegrenzte Sharding-Funktionen verfügt jedes Konto über eine exklusive Kontokette

Wir wissen jetzt, dass Sharding für die meisten Blockchain-Protokolle zur Mainstream-Lösung geworden ist, um die Leistung zu verbessern und die Kosten zu senken, und TON hat dies auf die Spitze getrieben und das Infinite-Sharding-Paradigma vorgeschlagen, das sogenannte Infinite-Sharding-Paradigma Erhöhen oder verringern Sie die Anzahl der Shards dynamisch basierend auf der Netzwerklast. Dieses Paradigma ermöglicht es TON, umfangreiche Transaktionen und intelligente Vertragsvorgänge abzuwickeln und gleichzeitig eine hohe Leistung aufrechtzuerhalten. Theoretisch kann TON für jedes Konto eine exklusive Kontokette einrichten und die Interoperabilität zwischen diesen Ketten durch bestimmte Regeln sicherstellen.

Um es abstrakt zu verstehen, gibt es in TON vier Ebenen der Kettenstruktur:

  • Kontokette: Diese Schichtkette stellt eine Kette dar, die aus einer Reihe von Transaktionen im Zusammenhang mit einem Konto besteht. Der Grund, warum Transaktionen eine Kettenstruktur bilden können, liegt darin, dass die Zustandsmaschine bei einer Zustandsmaschine dies tun wird, solange die Ausführungsregeln konsistent sind Die nach dem Empfang von Anweisungen in derselben Reihenfolge erhaltenen Ergebnisse sind konsistent, sodass in allen verteilten Blockchain-Systemen eine Kettenreihenfolge von Transaktionen erforderlich ist, und TON bildet da keine Ausnahme. Die Kontokette ist die grundlegendste Komponenteneinheit im TON-Netzwerk. Normalerweise ist die Kontokette ein virtuelles Konzept und es ist unwahrscheinlich, dass tatsächlich eine unabhängige Kontokette existiert.

  • Shard-Kette: In den meisten Kontexten ist die Shard-Kette die eigentliche Komponenteneinheit in TON. Die sogenannte Shard-Kette ist eine Sammlung von Kontoketten.

  • WorkChain: Es kann auch als eine Reihe von Sharding-Ketten mit benutzerdefinierten Regeln bezeichnet werden, z. B. das Erstellen einer EVM-basierten Arbeitskette und das Ausführen von Solidity-Smart-Verträgen darauf. Theoretisch kann jeder in der Community seine eigene Arbeitskette erstellen. Tatsächlich ist der Aufbau eine ziemlich komplexe Aufgabe, der die Zahlung der (teuren) Gebühr für die Erstellung und die Einholung von 2/3 der Stimmen von Validatoren vorausgehen, um die Erstellung Ihrer Arbeitskette zu genehmigen.

  • MasterChain: Schließlich gibt es in TON eine spezielle Kette namens Master Chain, die dafür verantwortlich ist, allen Shard Chains Endgültigkeit zu verleihen. Sobald der Hash eines Blocks einer Shard-Kette mit dem Block der Hauptkette zusammengeführt wird, gelten dieser Shard-Kettenblock und alle seine übergeordneten Blöcke als endgültig, was bedeutet, dass sie als fest und unzerbrechlich betrachtet werden können. Der geänderte Inhalt wird von nachfolgenden Blöcken aller Shards referenziert Ketten.

Durch die Übernahme eines solchen Paradigmas weist das TON-Netzwerk die folgenden drei Merkmale auf:

  • Dynamisches Sharding: TON kann Shard-Ketten automatisch teilen und zusammenführen, um sich an Laständerungen anzupassen. Dadurch werden immer schnell neue Blöcke generiert und bei Transaktionen entstehen keine langen Wartezeiten.

  • Hoch skalierbar: Durch das Infinite-Sharding-Paradigma kann TON eine nahezu unbegrenzte Anzahl von Shards unterstützen und theoretisch 2 bis 60 Potenzen an Arbeitsketten erreichen.

  • Anpassungsfähigkeit: Wenn die Belastung eines Teils des Netzwerks zunimmt, kann dieser Teil in weitere Shards unterteilt werden, um das erhöhte Transaktionsvolumen zu bewältigen. Umgekehrt können Shards bei abnehmender Last zusammengeführt werden, um die Effizienz zu steigern.

Dann muss sich ein solches Multi-Chain-System zunächst mit dem Problem der kettenübergreifenden Kommunikation auseinandersetzen, insbesondere aufgrund der Möglichkeit des unbegrenzten Shardings. Wenn die Anzahl der Shards im Netzwerk ein bestimmtes Niveau erreicht, erfolgt die Informationsweiterleitung zwischen den Ketten wird eine schwierige Sache werden. Stellen Sie sich vor, dass es 4 Knoten im Netzwerk gibt und jeder Knoten für die Aufrechterhaltung einer unabhängigen Arbeitskette verantwortlich ist. Die Verbindungsbeziehung zeigt an, dass der Knoten nicht nur für die Sortierung von Transaktionen in seiner eigenen Arbeitskette verantwortlich ist, sondern auch den Status überwachen und verarbeiten muss Änderungen in der Zielkette, was in TON durch die Überwachung der Nachrichten in der Ausgabewarteschlange gezielt umgesetzt wird.

Angenommen, Konto A in Arbeitskette 1 möchte eine Nachricht an Konto C in Arbeitskette 3 senden. Dann müssen Sie das Nachrichtenroutingproblem entwerfen. In diesem Beispiel gibt es zwei Routingpfade, Arbeitskette 1 -> Arbeitskette 2 -> Arbeitskette 3 und Arbeitskette 1 -> Arbeitskette 4 -> Arbeitskette 3.

Bei komplexeren Situationen ist ein effizienter und kostengünstiger Routing-Algorithmus erforderlich, um die Nachrichtenkommunikation schnell abzuschließen. TON hat sich für den sogenannten „Hypercube-Routing-Algorithmus“ entschieden, um die Routenerkennung für die kettenübergreifende Nachrichtenkommunikation zu realisieren. Die sogenannte Hypercube-Struktur bezieht sich auf eine spezielle Netzwerktopologie. Ein n-dimensionaler Hypercube besteht aus 2^n Eckpunkten, und jeder Eckpunkt kann durch eine n-Bit-Binärzahl eindeutig identifiziert werden. In dieser Struktur sind zwei beliebige Eckpunkte benachbart, wenn sie sich in der Binärdarstellung nur um ein Bit unterscheiden. Beispielsweise sind in einem dreidimensionalen Hyperwürfel die Scheitelpunkte 000 und 001 benachbart, da sie sich nur im letzten Bit unterscheiden. Das obige Beispiel ist ein zweidimensionaler Hyperwürfel.

Im Hypercube-Routing-Protokoll wird der Routing-Prozess einer Nachricht von einer Quell-Arbeitskette zu einer Ziel-Arbeitskette durch Vergleich der binären Darstellungen der Quell-Arbeitsketten- und Ziel-Arbeitskettenadressen durchgeführt. Der Routing-Algorithmus ermittelt den Mindestabstand (d. h. die Anzahl unterschiedlicher Bits in der Binärdarstellung) zwischen diesen beiden Adressen und leitet die Informationen schrittweise durch benachbarte Arbeitsketten weiter, bis die Ziel-Arbeitskette erreicht ist. Diese Methode stellt sicher, dass Datenpakete auf dem kürzesten Weg übertragen werden und verbessert so die Kommunikationseffizienz des Netzwerks.

Um diesen Prozess zu vereinfachen, hat TON natürlich auch eine optimistische technische Lösung vorgeschlagen: Wenn ein Benutzer einen gültigen Beweis für einen bestimmten Routing-Pfad liefern kann, bei dem es sich normalerweise um einen Merkle-Trie-Wurzel handelt, kann der Knoten die Glaubwürdigkeit des Pfads direkt erkennen Die vom Benutzer übermittelte Nachricht wird auch als sofortiges Hypercube-Routing bezeichnet.

Daher können wir sehen, dass es offensichtliche Unterschiede zwischen den Adressen in TON und anderen Blockchain-Protokollen gibt. Die meisten anderen Mainstream-Blockchain-Protokolle verwenden den Hash, der dem öffentlichen Schlüssel in den vom elliptischen Verschlüsselungsalgorithmus generierten öffentlichen und privaten Schlüsseln entspricht, weil Die Adresse wird nur als eindeutige Adresse verwendet. Sie muss keine Routing-Adressierungsfunktion tragen, und die Adresse in TON besteht aus zwei Teilen (workchain_id, account_id), wobei workchain_id gemäß der Adresse des Hypercube-Routing-Algorithmus codiert ist wird hier nicht weiter ausgeführt.

Es gibt noch einen weiteren Punkt, der leicht Zweifel aufkommen lässt. Möglicherweise haben Sie bemerkt, dass die Hauptkette eine Verbindungsbeziehung zu jeder Arbeitskette hat. Wäre es also nicht ausreichend, wenn alle kettenübergreifenden Informationen einfach über die Hauptkette weitergeleitet würden? wie Kosmos. Im Designkonzept von TON wird die Hauptkette nur zur Abwicklung der kritischsten Aufgaben verwendet, d .

Abschließend möchten wir noch kurz erwähnen, dass TON die BFT+PoS-Methode anwendet, d Cluster werden die als Validatoren ausgewählten Knoten durch den BFT-Algorithmus Blöcke verpackt und produziert. Wenn sie falsche Informationen verpacken oder Böses tun, verfallen ihre Einsatztoken, andernfalls erhalten sie Blockbelohnungen. Dies ist im Grunde eine häufige Wahl, daher werde ich sie hier nicht vorstellen.

Intelligente Verträge und eine vollständig parallele Ausführungsumgebung basierend auf dem Actor-Modell

Ein weiterer Unterschied zwischen TON und Mainstream-Blockchain-Protokollen ist die intelligente Vertragsausführungsumgebung. Um die Beschränkungen von TPS der Mainstream-Blockchain-Protokolle zu durchbrechen, übernimmt TON eine Bottom-up-Designidee und nutzt das Actor-Modell, um Smart Contracts und ihre Ausführungsmethoden zu rekonstruieren, sodass sie vollständig parallelisiert werden können.

Wir wissen, dass die meisten Mainstream-Blockchain-Protokolle eine Single-Threaded-Seriell-Ausführungsumgebung verwenden. Die Ausführungsumgebung EVM ist eine Zustandsmaschine mit Transaktionen als Eingabe, wenn der blockerzeugende Knoten die Transaktion durch Packen des Blocks abschließt , Transaktionen werden in dieser Reihenfolge über die EVM ausgeführt. Der gesamte Prozess ist vollständig seriell und Single-Threaded, das heißt, es kann nur eine Transaktion zu einem bestimmten Zeitpunkt ausgeführt werden Bestätigt, das Ausführungsergebnis wird in einer Vielzahl verteilter Cluster konsistent sein. Da gleichzeitig nur eine Transaktion seriell ausgeführt wird, bedeutet dies, dass dies während des Ausführungsprozesses für andere Transaktionen unmöglich ist Ändern Sie bestimmte Zustandsdaten, auf die zugegriffen werden soll, sodass die Interoperabilität zwischen intelligenten Verträgen erreicht wird. Beispielsweise verwenden wir USDT, um ETH über Uniswap zu kaufen. Wenn die Transaktion ausgeführt wird, kann die Verteilung von LP im Handelspaar auf diese Weise durch bestimmte mathematische Modelle ermittelt werden Dies ist jedoch nicht der Fall. Wenn bei der Berechnung einer bestimmten Bindungskurve andere LPs neue Liquidität hinzufügen, ist das Berechnungsergebnis veraltet, was offensichtlich inakzeptabel ist.

Aber diese Architektur hat auch offensichtliche Einschränkungen, was den Engpass von TPS darstellt, und dieser Engpass scheint unter aktuellen Multi-Core-Prozessoren sehr alt zu sein, genau wie wenn Sie den neuesten PC verwenden, um einige alte Computerspiele zu spielen, wie zum Beispiel Red Alert Wenn die Anzahl der Kampfeinheiten ein bestimmtes Niveau erreicht, werden Sie immer noch feststellen, dass dies ein Problem mit der Softwarearchitektur ist.

Möglicherweise hören Sie, dass einige Protokolle sich bereits mit diesem Problem befassen und ihre eigenen parallelen Lösungen vorgeschlagen haben. Nehmen wir als Beispiel Solana, das derzeit den höchsten TPS angibt und auch die Fähigkeit zur parallelen Ausführung besitzt. Seine Designidee unterscheidet sich jedoch von TON. In Solana besteht die Kernidee darin, alle Transaktionen entsprechend den Ausführungsabhängigkeiten in mehrere Gruppen aufzuteilen, und es werden keine Statusdaten zwischen verschiedenen Gruppen geteilt. Das heißt, es gibt keine identischen Abhängigkeiten, sodass Transaktionen in verschiedenen Gruppen parallel ausgeführt werden können, ohne sich Gedanken über Konflikte machen zu müssen, während Transaktionen innerhalb derselben Gruppe weiterhin auf herkömmliche Weise seriell ausgeführt werden.

In TON wird die serielle Ausführungsarchitektur vollständig aufgegeben und stattdessen ein speziell auf Parallelität ausgelegtes Entwicklungsparadigma, das Actor-Modell, übernommen, um die Ausführungsumgebung zu rekonstruieren. Das sogenannte Actor-Modell wurde erstmals 1973 von Carl Hewitt vorgeschlagen, um die Komplexität des Shared State in traditionellen gleichzeitigen Programmen durch Message Passing zu lösen. Jeder Akteur hat seinen eigenen privaten Zustand und sein eigenes Verhalten, und es werden keine Zustandsinformationen an andere Aktoren weitergegeben. Das Actor-Modell ist ein Concurrent-Computing-Computing-Modell, das paralleles Computing durch Nachrichtenübermittlung implementiert. In diesem Modell ist „Actor“ die grundlegende Arbeitseinheit, die empfangene Nachrichten verarbeiten, neue Actors erstellen, weitere Nachrichten senden und entscheiden kann, wie auf nachfolgende Nachrichten reagiert werden soll. Das Actor-Modell muss die folgenden Eigenschaften aufweisen:

  • Kapselung und Unabhängigkeit: Jeder Akteur ist bei der Verarbeitung von Nachrichten völlig unabhängig und kann Nachrichten parallel verarbeiten, ohne sich gegenseitig zu stören.

  • Nachrichtenübermittlung: Akteure interagieren untereinander nur durch das Senden und Empfangen von Nachrichten, und die Nachrichtenübermittlung erfolgt asynchron.

  • Dynamische Struktur: Akteure können zur Laufzeit weitere Akteure erstellen. Diese dynamische Natur ermöglicht es dem Akteurmodell, das System nach Bedarf zu skalieren.

TON übernimmt diese Architektur, um Smart-Contract-Modelle zu entwerfen, was bedeutet, dass in TON jeder Smart Contract ein Actor-Modell mit völlig unabhängigem Speicherplatz ist. Weil es nicht auf externen Daten basiert. Darüber hinaus werden Aufrufe desselben Smart-Vertrags weiterhin entsprechend der Reihenfolge der Nachrichten in der Empfangswarteschlange ausgeführt, sodass Transaktionen in TON effizient parallel ausgeführt werden können, ohne sich über Konflikte Gedanken machen zu müssen.

Allerdings bringt ein solches Designschema auch einige neue Auswirkungen mit sich. Für DApp-Entwickler wird ihr gewohntes Entwicklungsparadigma wie folgt durchbrochen:

1. Asynchrone Aufrufe zwischen Smart Contracts: Es ist nicht möglich, externe Verträge atomar aufzurufen oder auf externe Vertragsdaten innerhalb der Smart Contracts von TON zuzugreifen. Wir wissen, dass in Solidity Funktion1 von Vertrag A Funktion2 von Vertrag B aufruft, oder über die schreibgeschützte Funktion3 Der gesamte Prozess ist atomar und wird in einer Transaktion ausgeführt. In TON ist dies jedoch nicht möglich, und jede Interaktion mit externen Informationen wird asynchron ausgeführt Das Verpacken neuer Transaktionen wird auch als interne Nachrichten bezeichnet. Und es kann während der Ausführung nicht blockiert werden, um Ausführungsergebnisse zu erhalten.

Wenn wir beispielsweise einen DEX entwickeln und das gemeinsame Paradigma in EVM übernehmen, gibt es normalerweise einen einheitlichen Router-Vertrag, der zur Verwaltung des Transaktionsroutings verwendet wird, und jeder Pool verwaltet unabhängig die LP-Daten, die sich auf ein bestimmtes Handelspaar beziehen Derzeit gibt es zwei Pools USDT-DAI und DAI-ETH. Wenn ein Benutzer ETH direkt über USDT kaufen möchte, kann er oder sie diese beiden Pools nacheinander in einer Transaktion über den Router-Vertrag anfordern, um eine atomare Transaktion abzuschließen. Es ist jedoch nicht so einfach, über ein neues Entwicklungsparadigma nachzudenken. Wenn dieses Paradigma weiterhin verwendet wird, wird der Informationsfluss möglicherweise von einer externen Nachricht begleitet Benutzer- und drei interne Nachrichten sind abgeschlossen (beachten Sie, dass dies zur Veranschaulichung des Unterschieds dient. In der realen Entwicklung muss sogar das Paradigma von ERC20 neu gestaltet werden).

2. Beim vertragsübergreifenden Aufruf muss der Verarbeitungsprozess für Ausführungsfehler sorgfältig geprüft und für jeden vertragsübergreifenden Aufruf eine entsprechende Bounce-Funktion entworfen werden. Wir wissen, dass im Mainstream-EVM die gesamte Transaktion zurückgesetzt wird, wenn während der Transaktionsausführung ein Problem auftritt, dh auf den ursprünglichen Ausführungsstatus zurückgesetzt wird. Dies ist im seriellen Single-Threaded-Modell leicht zu verstehen. Da in TON jedoch die Aufrufe zwischen Verträgen asynchron ausgeführt werden, kann dies selbst dann zu Problemen führen, wenn in einem nachfolgenden Link ein Fehler auftritt, da die zuvor erfolgreich ausgeführte Transaktion bereits ausgeführt und bestätigt wurde. Daher ist in TON ein spezieller Nachrichtentyp eingerichtet, der als Bounce-Nachricht bezeichnet wird. Das heißt, wenn im nachfolgenden Ausführungsprozess, der durch eine interne Nachricht ausgelöst wird, ein Fehler auftritt, kann der ausgelöste Vertrag ein bestimmtes Ereignis im Vertrag auslösen, indem er den Bounce auslöst Durch den Vertrag reservierte Funktion. Einige Status werden zurückgesetzt.

3. In einigen komplexen Situationen wird die zuerst empfangene Transaktion möglicherweise nicht zuerst ausgeführt, sodass diese Zeitbeziehung nicht voreingestellt werden kann. In einem solchen System asynchroner und paralleler Smart-Contract-Aufrufe kann es schwierig sein, die Reihenfolge festzulegen, in der Vorgänge verarbeitet werden. Deshalb hat jede Nachricht in TON ihre logische Zeit Lamport-Zeit (im Folgenden lt genannt). Es wird verwendet, um zu verstehen, welches Ereignis ein anderes ausgelöst hat und was der Validator zuerst verarbeiten muss. Bei einem einfachen Modell muss die zuerst empfangene Transaktion zuerst ausgeführt werden.

In diesem Modell stellen A und B jeweils zwei Smart Contracts dar, und es besteht eine zeitliche Beziehung: Wenn msg1_lt < msg2_lt, dann tx1_lt < tx2_lt.

In komplexeren Situationen wird diese Regel jedoch gebrochen. In der offiziellen Dokumentation gibt es dafür ein Beispiel, vorausgesetzt wir haben drei Verträge A, B und C. Bei einer Transaktion sendet A zwei interne Nachrichten msg1 und msg2: eine an B und eine an C. Obwohl sie in der genauen Reihenfolge erstellt werden (zuerst msg1, dann msg2), können wir nicht sicher sein, dass msg1 vor msg2 verarbeitet wird. Dies liegt daran, dass die Routen von A nach B und von A nach C sich in Länge und Validatorsatz unterscheiden können. Wenn sich diese Verträge auf verschiedenen Shard-Ketten befinden, kann es mehrere Blöcke dauern, bis eine der Nachrichten den Zielvertrag erreicht. Das heißt, wir haben zwei mögliche Handelspfade, wie in der Abbildung dargestellt.

4. In TON verwendet die dauerhafte Speicherung seiner Smart Contracts einen gerichteten azyklischen Graphen mit Zelle als Einheit als Datenstruktur. Die Daten werden gemäß den Codierungsregeln und gleichzeitig gemäß der kompakten Datenstruktur in eine Zelle komprimiert Die Richtung des gerichteten azyklischen Diagramms unterscheidet sich von der Hashmap-basierten Strukturorganisation der Statusdaten in EVM. Aufgrund unterschiedlicher Datenanforderungsalgorithmen legt TON unterschiedliche Gaspreise für unterschiedliche Tiefen der Datenverarbeitung fest Je mehr Gas für die Datenverarbeitung erforderlich ist, desto höher ist der DOS-Angriff in TON, d bedeutet, dass die Speicherkosten für ehrliche Benutzer immer teurer werden. Da die Abfragekomplexität der Hashmap in EVM o(1) ist, hat sie das gleiche Gas und es treten keine ähnlichen Probleme auf. Daher sollten TON Dapp-Entwickler versuchen, unbegrenzte Datentypen in Smart Contracts zu vermeiden. Wenn unbegrenzte Datentypen auftreten, sollten diese durch Sharding aufgeteilt werden.

5. Es gibt auch einige weniger spezielle Funktionen, wie z. B. Smart Contracts, für die Miete für die Speicherung gezahlt werden muss, Smart Contracts in TON sind natürlich aktualisierbar und native abstrakte Kontofunktionen, d. h. alle Wallet-Adressen in TON sind Smart Contracts. einfach nicht initialisiert usw. Diese erfordern von den Entwicklern sorgfältige Aufmerksamkeit.

Das Obige sind einige meiner Erfahrungen beim Erlernen von TON-bezogenen Technologien in dieser Zeit. Ich hoffe, Sie können mich korrigieren. Gleichzeitig denke ich, dass dies bei den enormen Verkehrsressourcen der Fall ist Das TON-Ökosystem wird definitiv als Plattform für Web3 dienen und einige brandneue Anwendungen mitbringen. Freunde, die an der TON-DApp-Entwicklung interessiert sind, können mich auch kontaktieren und mit uns diskutieren.