Autor: @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 Wirtschaftsmodell der Vollumlauf-Token verursacht wird, hat TON in kurzer Zeit große Aufmerksamkeit erlangt. 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 des TON-Designs besteht darin, das traditionelle Blockchain-Protokoll „von unten nach oben“ zu rekonstruieren und eine hohe Parallelität und Skalierbarkeit auf Kosten der Interoperabilität 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 enthält. 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ß. Es ist Zeit für das Jahr 2018. Um die für die Implementierung von TON erforderlichen Ressourcen zu erhalten, startete Telegram im ersten Quartal 2018 den 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 von Telegram konzipiert ist, muss es sich natürlich mit zwei Problemen auseinandersetzen: vielen gleichzeitigen Anfragen und riesigen Datenmengen. Wir wissen, dass Solana, das als das höchste TPS bekannt ist, mit der Entwicklung der Technologie bis heute die höchste gemessene TPS von nur 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:
Indem wir das „Infinite Sharding Paradigma“ zum Entwerfen des Systems verwenden, 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. Daher ist in allen verteilten Blockchain-Systemen eine Kettenreihenfolge erforderlich, und TON ist 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 der Validatoren vorausgehen, um die Erstellung Ihrer Arbeitskette zu genehmigen.
Hauptkette (MasterChain): Schließlich gibt es in TON eine spezielle Kette namens Hauptkette, die dafür verantwortlich ist, allen Shard-Ketten 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, die für die Aufrechterhaltung einer unabhängigen Arbeitskette verantwortlich sind. Die Verbindungsbeziehung zeigt an, dass der Knoten nicht nur für die Transaktionssortierung in seiner eigenen Arbeitskette verantwortlich ist, sondern auch den Status überwachen und verarbeiten muss Änderungen in der Zielkette, die in TON speziell durch Überwachung der Nachrichten in der Ausgabewarteschlange umgesetzt werden.
Angenommen, Konto A in Arbeitskette 1 möchte eine Nachricht an Konto C in Arbeitskette 3 senden. Sie müssen das Nachrichtenroutingproblem entwerfen. In diesem Beispiel gibt es zwei Routingpfade: Arbeitskette 1 -> Arbeitskette 2 -> Arbeitskette 3 und Arbeitskette 1 -> Arbeitskette 4 -> Arbeitskette 3.
In 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 3D-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 erbringen kann, bei dem es sich normalerweise um eine Merkle-Trie-Wurzel handelt, kann der Knoten die Glaubwürdigkeit der Nachricht direkt erkennen Dies wird auch als Instant-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 gepackt und produziert. Wenn sie falsche Informationen verpacken oder Böses tun, verfallen ihre abgesteckten Token und 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 Punkt, der sich bei TON von den gängigen Blockchain-Protokollen unterscheidet, ist die intelligente Vertragsausführungsumgebung. Um die Beschränkungen des Mainstream-Blockchain-Protokolls TPS zu durchbrechen, hat TON eine Bottom-up-Designidee übernommen und das Actor-Modell verwendet, um intelligente Verträge und ihre Ausführungsmethoden zu rekonstruieren und ihnen die Möglichkeit zu geben, vollständig parallelisiert zu werden.
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 weist auch offensichtliche Einschränkungen auf, was den Engpass von TPS darstellt, und dieser Engpass scheint unter aktuellen Multi-Core-Prozessoren sehr alt zu sein, genau wie wenn Sie einen aktuellen PC verwenden, um einige alte Computerspiele zu spielen, wie z. B. 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 gibt keine Zustandsinformationen an andere Aktoren weiter. Das Actor-Modell ist ein Concurrent-Computing-Computing-Modell, das paralleles Computing durch Nachrichtenübermittlung implementiert. In diesem Modell ist ein „Akteur“ die grundlegende Arbeitseinheit, die in der Lage ist, empfangene Nachrichten zu verarbeiten, neue Akteure zu erstellen, weitere Nachrichten zu senden und zu entscheiden, 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 nur miteinander, indem sie Nachrichten senden und empfangen, 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 erweitern.
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 Funktion 3 von Vertrag C greift auf bestimmte Zustandsdaten zu 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 Durch das Verpacken neuer Transaktionen werden solche durch Smart Contracts initiierten Transaktionen 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 wir dieses Paradigma weiterhin verwenden, wird der Informationsfluss möglicherweise von einer externen Nachricht begleitet, die vom Benutzer initiiert wird und drei interne Nachrichten werden vervollständigt (beachten Sie, dass dies zur Veranschaulichung des Unterschieds dient. In der realen Entwicklung muss sogar das ERC20-Paradigma neu gestaltet werden).
2. Bei vertragsübergreifenden Aufrufen muss der Verarbeitungsprozess sorgfältig auf Ausführungsfehler geprüft und für jeden vertragsübergreifenden Aufruf entsprechende Bounce-Funktionen 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 über die Bounce-Funktion eine bestimmte Nachricht im Vertrag auslösen durch den Trigger-Vertrag reserviert. 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, sodass wenn msg1_lt < msg2_lt, dann tx1_lt < tx2_lt.
In komplexeren Situationen wird diese Regel jedoch gebrochen. Ein Beispiel hierfür finden Sie in der offiziellen Dokumentation. Angenommen, wir haben drei Verträge A, B und C. Bei einer Transaktion sendet A zwei interne Nachrichten msg1 und msg2: eine an B und die andere an C. Obwohl sie in der genauen Reihenfolge erstellt werden (msg1 zuerst, 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 Der gerichtete azyklische Graph 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 , desto mehr Gas ist erforderlich, daher gibt es in TON ein Paradigma für DOS-Angriffe, das heißt, einige böswillige Benutzer besetzen alle flachen Zellen in einem bestimmten Smart Contract, indem sie eine große Anzahl von Spam-Nachrichten senden Die Speicherkosten für ehrliche Benutzer werden immer teurer. 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 Telegram der Fall ist Ressourcen, das TON-Ökosystem wird definitiv eine Plattform für Web3 bieten und einige brandneue Anwendungen mitbringen. Freunde, die an der TON-DApp-Entwicklung interessiert sind, können mich auch kontaktieren und mit uns diskutieren.
X-Links: https://x.com/web3_mario