Detaillierte Beschreibung der technischen Funktionen von TON und des Paradigmas zur Entwicklung intelligenter Verträge

Originalautor: @Web3 Mario

Einführung: 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 wurde, hat TON in kurzer Zeit große Aufmerksamkeit erlangt. Nach einem Gespräch mit einem Freund erfuhr ich, dass die technische Schwelle von TON relativ hoch ist und sich das DApp-Entwicklungsparadigma stark vom gängigen öffentlichen Kettenprotokoll unterscheidet. Daher habe ich einige Zeit damit verbracht, die relevanten Themen eingehend zu studieren, und ich habe einige Erfahrungen, die ich mit Ihnen teilen kann. Kurz gesagt, das Kerndesignkonzept von TON besteht darin, das traditionelle Blockchain-Protokoll von unten nach oben zu rekonstruieren und das ultimative Streben nach hoher Parallelität und hoher Skalierbarkeit auf Kosten der Aufgabe der Interoperabilität zu erreichen.

Das Kerndesignkonzept von TON – hohe Parallelität und hohe Skalierbarkeit

Man kann sagen, dass der Zweck der gesamten komplexen Technologieauswahl bei TON aus dem Streben nach hoher Parallelität und hoher Skalierbarkeit besteht. Natürlich ist es für uns nicht schwer, dies vor dem Hintergrund seiner Entstehung zu verstehen. TON oder The Open Network ist ein dezentrales Computernetzwerk, das aus einer L1-Blockchain und mehreren Komponenten besteht. TON wurde ursprünglich von Telegrams Gründer Nikolai Durov und seinem Team entwickelt und wird jetzt von einer Community unabhängiger Mitwirkender auf der ganzen Welt unterstützt und gepflegt. Seine Geburt geht auf das Jahr 2017 zurück, als das Telegram-Team begann, Blockchain-Lösungen für sich selbst zu erkunden. Da es zu diesem Zeitpunkt keine bestehende L1-Blockchain gab, die Telegrams neunstellige Benutzerbasis unterstützen konnte, beschlossen sie, ihre eigene Blockchain zu entwickeln, die damals Telegram Open Network hieß. 2018 war es soweit. Um die für die Realisierung von TON erforderlichen Ressourcen zu erhalten, startete Telegram im ersten Quartal 2018 den Verkauf von Gram-Token (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 TON-Codebasis, benannte das Projekt in The Open Network um und entwickelt die Blockchain bis heute aktiv weiter, wobei sie den im ursprünglichen TON-Whitepaper beschriebenen Grundsätzen folgt.

Da das Designziel darin besteht, eine dezentrale Ausführungsumgebung für Telegram zu schaffen, gibt es natürlich zwei Probleme: hohe Anzahl gleichzeitiger Anfragen und riesige Datenmengen. Wie wir wissen, hat Solana, das behauptet, die höchste TPS zu haben, mit der Entwicklung der Technologie nur eine gemessene maximale TPS von 65.000 erreicht, was offensichtlich nicht ausreicht, um das Telegram-Ökosystem zu unterstützen, das Millionen von TPS benötigt. Gleichzeitig hat die von Telegram generierte Datenmenge mit der groß angelegten Anwendung bereits astronomische Ausmaße angenommen, und als extrem redundantes verteiltes System erfordert Blockchain, dass jeder Knoten im Netzwerk eine vollständige Kopie der Daten speichert, was ebenfalls unrealistisch ist.

Um die beiden oben genannten Probleme zu lösen, hat TON daher zwei Optimierungen am Mainstream-Blockchain-Protokoll vorgenommen:

• Durch die Übernahme des Infinite-Sharding-Paradigmas bei der Systemgestaltung wird das Problem der Datenredundanz gelöst, sodass große Datenmengen übertragen und gleichzeitig Leistungsengpässe vermieden werden können.

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

Werden Sie zu einer Blockchain-Kette – durch unbegrenzte Sharding-Funktionen verfügt jedes Konto über eine eigene Kontokette

Wir wissen, dass Sharding für die meisten Blockchain-Protokolle zur Mainstream-Lösung geworden ist, um die Leistung zu verbessern und die Kosten zu senken. TON hat dies auf die Spitze getrieben und ein Paradigma des unendlichen Shardings vorgeschlagen, was bedeutet, dass die Blockchain die Anzahl der Shards je nach Netzwerklast dynamisch erhöhen oder verringern kann. Dieses Paradigma ermöglicht es TON, groß angelegte Transaktionen und Smart-Contract-Operationen abzuwickeln und gleichzeitig eine hohe Leistung aufrechtzuerhalten. Theoretisch kann TON für jedes Konto eine exklusive Kontokette einrichten und durch bestimmte Regeln die Konsistenz zwischen diesen Ketten sicherstellen.

Um es abstrakt auszudrücken, gibt es in TON vier Schichten einer Kettenstruktur:

• Kontokette: Diese Kettenebene stellt eine Kette von Transaktionen dar, die mit einem bestimmten Konto in Zusammenhang stehen. Der Grund, warum Transaktionen eine Kettenstruktur bilden können, ist, dass bei einer Zustandsmaschine, solange die Ausführungsregeln konsistent sind, die Zustandsmaschine nach Erhalt der gleichen Reihenfolge von Anweisungen das gleiche Ergebnis erhält. Daher müssen alle verteilten Blockchain-Systeme Transaktionen in einer Kette sortieren, und TON ist 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 Chain: In den meisten Kontexten ist die Shard Chain die eigentliche Komponenteneinheit von TON. Die sogenannte Shard Chain ist eine Sammlung von Account Chains.

• WorkChain: Man kann es auch als eine Reihe von Shard-Chains mit benutzerdefinierten Regeln bezeichnen, wie z. B. das Erstellen einer EVM-basierten Workchain und das Ausführen von Solidity-Smart-Contracts darauf. Theoretisch kann jeder in der Community seine eigene Workchain erstellen. In Wirklichkeit ist der Aufbau eine ziemlich komplexe Aufgabe, und vorher müssen Sie die (teure) Gebühr für die Erstellung bezahlen und 2/3 der Stimmen der Validierer einholen, um die Erstellung Ihrer Workchain 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-Wert eines Shard Chain-Blocks in den Master Chain-Block integriert ist, gelten der Shard Chain-Block und alle seine übergeordneten Blöcke als endgültig, was bedeutet, dass sie als fester und unveränderlicher Inhalt betrachtet und von nachfolgenden Blöcken aller Shard Chains referenziert werden können.

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

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

• Hochgradig skalierbar: Durch das Paradigma des Infinite-Sharding ist TON in der Lage, eine nahezu unbegrenzte Anzahl von Shards zu unterstützen, theoretisch bis zu 2 hoch 60 Arbeitsketten.

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

Dann muss sich ein solches Multi-Chain-System zunächst dem Problem der Cross-Chain-Kommunikation stellen, insbesondere aufgrund der Möglichkeit des unbegrenzten Shardings. Wenn die Anzahl der Shards im Netzwerk ein bestimmtes Niveau erreicht, wird die Informationsweiterleitung zwischen den Ketten zu einer schwierigen Aufgabe. Stellen Sie sich vor, es gibt 4 Knoten im Netzwerk, jeder Knoten ist für die Aufrechterhaltung einer unabhängigen Arbeitskette verantwortlich, wobei die Link-Beziehung bedeutet, dass der Knoten neben der Verantwortung für die Transaktionssortierungsarbeit in seiner eigenen Arbeitskette auch die Statusänderungen in der Zielkette überwachen und verarbeiten muss. In TON wird dies erreicht, indem die Nachrichten in der Ausgabewarteschlange überwacht werden.

Angenommen, Konto A in Arbeitskette 1 möchte eine Nachricht an Konto C in Arbeitskette 3 senden. Dann muss das Nachrichtenroutingproblem entworfen werden. 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 Routing-Erkennung für die kettenübergreifende Nachrichtenkommunikation zu erreichen. Die sogenannte Hypercube-Struktur bezieht sich auf eine spezielle Netzwerktopologie. Ein n-dimensionaler Hypercube besteht aus 2^n Eckpunkten, von denen jeder eindeutig durch eine n-Bit-Binärzahl identifiziert werden kann. In dieser Struktur sind zwei beliebige Eckpunkte benachbart, wenn sie sich in der Binärdarstellung nur um ein Bit unterscheiden. Beispielsweise sind in einem 3-dimensionalen Hypercube die Eckpunkte 000 und 001 benachbart, da sie sich nur im letzten Bit unterscheiden. Das obige Beispiel ist ein 2-dimensionaler Hypercube.

Beim Hypercube-Routing-Protokoll wird das Weiterleiten von Nachrichten von der Quellkette zur Zielkette durch Vergleichen der binären Darstellung der Quell- und Zielkettenadressen durchgeführt. Der Routing-Algorithmus findet den Mindestabstand zwischen den beiden Adressen (d. h. die Anzahl der unterschiedlichen Bits in der binären Darstellung) und leitet die Informationen Schritt für Schritt durch benachbarte Ketten weiter, bis sie die Zielkette erreichen. Diese Methode stellt sicher, dass Datenpakete auf dem kürzesten Weg übertragen werden, wodurch die Kommunikationseffizienz des Netzwerks verbessert wird.

Um diesen Prozess zu vereinfachen, hat TON natürlich auch eine optimistische technische Lösung vorgeschlagen. Wenn ein Benutzer einen gültigen Nachweis für einen Routing-Pfad erbringen kann, bei dem es sich normalerweise um eine Merkle-Trie-Wurzel handelt, kann der Knoten die Glaubwürdigkeit der vom Benutzer übermittelten Nachricht direkt bestätigen. Dies wird auch als sofortiges Hypercube-Routing bezeichnet.

Daher können wir sehen, dass sich die Adressen in TON erheblich von denen in anderen Blockchain-Protokollen unterscheiden. Die meisten anderen gängigen Blockchain-Protokolle verwenden den Hash, der dem öffentlichen Schlüssel im öffentlich-privaten Schlüssel entspricht, der vom elliptischen Verschlüsselungsalgorithmus als Adresse generiert wird, da die Adresse nur zur Eindeutigkeit verwendet wird und nicht die Funktion der Routing-Adressierung erfüllen muss. Die Adresse in TON besteht aus zwei Teilen (workchain_id, account_id), wobei workchain_id gemäß der Adresse des Hypercube-Routing-Algorithmus codiert ist, die hier nicht näher erläutert wird.

Es gibt noch einen weiteren Punkt, der leicht in Zweifel gezogen werden kann. Sie haben vielleicht bemerkt, dass die Hauptkette und jede Arbeitskette miteinander verbunden sind. Dann können alle kettenübergreifenden Informationen über die Hauptkette weitergeleitet werden, genau wie bei Cosmos. Im Designkonzept von TON wird die Hauptkette nur verwendet, um die kritischsten Aufgaben zu bewältigen, d. h. um die Endgültigkeit vieler Arbeitsketten aufrechtzuerhalten. Es ist nicht unmöglich, Nachrichten über die Hauptkette zu leiten, aber die daraus resultierenden Bearbeitungsgebühren werden sehr hoch sein.

Abschließend möchte ich kurz auf den Konsensalgorithmus eingehen. TON verwendet die BFT+PoS-Methode, d. h. jeder Staker hat die Möglichkeit, an der Blockpaketierung teilzunehmen. Der Wahlverwaltungsvertrag von TON wählt in regelmäßigen Abständen nach dem Zufallsprinzip einen Paketvalidatorcluster aus allen Stakern aus. Die ausgewählten Knoten, die sogenannten Validatoren, packen Blöcke mithilfe des BFT-Algorithmus. Wenn sie falsche Informationen packen oder Böses tun, werden ihre eingesetzten Token konfisziert, andernfalls erhalten sie Blockbelohnungen. Dies ist im Grunde eine gängige Wahl, daher werde ich sie hier nicht vorstellen.

Akteurbasierte Smart Contracts und vollständig parallele Ausführungsumgebung

Ein weiterer Unterschied zwischen TON und gängigen Blockchain-Protokollen ist die Smart-Contract-Ausführungsumgebung. Um die TPS-Einschränkungen der gängigen Blockchain-Protokolle zu durchbrechen, hat TON einen Bottom-up-Designansatz gewählt und Smart Contracts und ihre Ausführungsmethoden mithilfe des Actor-Modells neu konstruiert, sodass sie über vollständige parallele Ausführungsfunktionen verfügen.

Wir wissen, dass die meisten gängigen Blockchain-Protokolle eine einfädige serielle Ausführungsumgebung verwenden. Am Beispiel von Ethereum ist seine Ausführungsumgebung EVM eine Zustandsmaschine, die Transaktionen als Eingabe verwendet. Wenn der Blockproduktionsknoten die Sortierung der Transaktionen durch das Verpacken von Blöcken abgeschlossen hat, führt er die Transaktionen in dieser Reihenfolge über EVM aus. Der gesamte Prozess ist vollständig seriell und einfädig, d. h. es kann jeweils nur eine Transaktion ausgeführt werden. Dies hat den Vorteil, dass das Ausführungsergebnis in einem weit verteilten Cluster konsistent ist, solange die Transaktionsreihenfolge bestätigt ist. Da gleichzeitig nur eine Transaktion seriell ausgeführt wird, ist es während des Ausführungsprozesses für andere Transaktionen unmöglich, die zugegriffenen Zustandsdaten zu ändern, wodurch Interoperabilität zwischen intelligenten Verträgen erreicht wird. Beispielsweise verwenden wir USDT, um ETH über Uniswap zu kaufen. Wenn die Transaktion ausgeführt wird, ist die Verteilung der LPs im Transaktionspaar ein bestimmter Wert, sodass die entsprechenden Ergebnisse durch bestimmte mathematische Modelle erzielt werden können. Ist dies jedoch nicht der Fall und fügen bei der Berechnung der Bonding-Kurve andere LPs neue Liquidität hinzu, so ist das Berechnungsergebnis veraltet und offensichtlich nicht akzeptabel.

Diese Architektur weist jedoch auch offensichtliche Einschränkungen auf, nämlich den TPS-Engpass, und dieser Engpass scheint unter den aktuellen Mehrkernprozessoren sehr veraltet zu sein. Es ist, als würde man auf dem neuesten PC einige alte Computerspiele wie Red Alert spielen. Wenn die Anzahl der Kampfeinheiten einen bestimmten Wert erreicht, werden Sie immer noch feststellen, dass es hängen bleibt. Dies ist ein Problem mit der Softwarearchitektur.

Sie haben vielleicht gehört, dass einige Protokolle dieses Problem bereits berücksichtigt und ihre eigenen parallelen Lösungen vorgeschlagen haben. Solana beispielsweise, das derzeit bekanntermaßen die höchste TPS hat, verfügt auch über die Fähigkeit zur parallelen Ausführung. Das Designkonzept unterscheidet sich jedoch von TON. In Solana besteht die Kernidee darin, alle Transaktionen entsprechend der 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 dass Konflikte zu befürchten sind. Für Transaktionen in derselben Gruppe wird zur Ausführung weiterhin die traditionelle serielle Methode verwendet.

In TON wird die serielle Ausführungsarchitektur jedoch vollständig aufgegeben und ein 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, mit dem Ziel, die Komplexität des gemeinsamen Zustands in herkömmlichen parallelen Programmen durch Nachrichtenübermittlung zu lösen. Jeder Actor hat seinen eigenen privaten Zustand und sein eigenes Verhalten und teilt keine Zustandsinformationen mit anderen Actors. Das Actor-Modell ist ein Computermodell für paralleles Rechnen, das paralleles Rechnen durch Nachrichtenübermittlung implementiert. In diesem Modell ist der Actor die grundlegende Arbeitseinheit, die empfangene Nachrichten verarbeiten, neue Actors erstellen, weitere Nachrichten senden und entscheiden kann, wie auf die nächste Nachricht reagiert wird. Das Actor-Modell muss die folgenden Eigenschaften aufweisen:

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

• Nachrichtenübermittlung: Akteure interagieren 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 Dynamik ermöglicht es dem Akteurmodell, das System nach Bedarf zu erweitern.

TON verwendet diese Architektur, um das Smart-Contract-Modell zu entwerfen. Das bedeutet, dass in TON jeder Smart Contract ein Actor-Modell mit völlig unabhängigem Speicherplatz ist. Weil es nicht auf externe Daten angewiesen ist. Darüber hinaus werden Aufrufe desselben Smart Contracts weiterhin entsprechend der Reihenfolge der Nachrichten in der Empfangswarteschlange ausgeführt, sodass Transaktionen in TON effizient parallel ausgeführt werden können, ohne dass Konflikte zu befürchten sind.

Allerdings bringt dieser Entwurf auch einige neue Auswirkungen mit sich. Für DApp-Entwickler wird ihr gewohntes Entwicklungsparadigma wie folgt aufgebrochen:

1. Asynchrone Aufrufe zwischen Smart Contracts: Es ist nicht möglich, externe Verträge aufzurufen oder innerhalb der Smart Contracts von TON atomar auf externe Vertragsdaten zuzugreifen. Wir wissen, dass in Solidity der gesamte Prozess atomar ist und in einer Transaktion ausgeführt wird, wenn Funktion 2 von Vertrag B von Funktion 1 von Vertrag A aus aufgerufen wird oder über die schreibgeschützte Funktion 3 von Vertrag C auf bestimmte Statusdaten zugegriffen wird. Dies ist sehr einfach. In TON ist dies jedoch nicht möglich. Jede Interaktion mit externen Smart Contracts wird asynchron ausgeführt, indem neue Transaktionen verpackt werden. Solche von Smart Contracts initiierten Transaktionen werden auch als interne Nachrichten bezeichnet. Und der Ausführungsprozess kann nicht blockiert werden, um das Ausführungsergebnis zu erhalten.

Wenn wir beispielsweise einen DEX entwickeln und das gemeinsame Paradigma in EVM übernehmen, gibt es normalerweise einen einheitlichen Router-Vertrag zur Verwaltung der Transaktionsweiterleitung, und jeder Pool verwaltet die LP-Daten, die sich auf ein bestimmtes Handelspaar beziehen, separat. Angenommen, es gibt derzeit zwei Pools, USDT-DAI und DAI-ETH. Wenn ein Benutzer ETH direkt über USDT kaufen möchte, kann er diese beiden Pools nacheinander in einer Transaktion über den Router-Vertrag anfordern, um die atomare Transaktion abzuschließen. Dies ist in TON jedoch nicht so einfach zu erreichen, und wir müssen über ein neues Entwicklungsparadigma nachdenken. Wenn wir dieses Paradigma weiterhin verwenden, kann der Informationsfluss folgendermaßen aussehen: Diese Anforderung wird von einer vom Benutzer initiierten externen Nachricht und drei internen Nachrichten begleitet (beachten Sie, dass dies zur Veranschaulichung des Unterschieds verwendet wird. In der realen Entwicklung muss sogar das ERC 20-Paradigma neu gestaltet werden).

2. Es ist notwendig, den Verarbeitungsablauf von Ausführungsfehlern bei vertragsübergreifenden Aufrufen sorgfältig zu berücksichtigen und für jeden vertragsübergreifenden Aufruf entsprechende Bounce-Funktionen zu entwerfen. Wir wissen, dass im Mainstream-EVM, wenn während der Ausführung einer Transaktion ein Problem auftritt, die gesamte Transaktion zurückgesetzt wird, d. h. auf den Zustand zu Beginn der Ausführung zurückgesetzt wird. Dies ist im seriellen Single-Thread-Modell leicht zu verstehen. Da in TON jedoch die Inter-Contract-Aufrufe asynchron ausgeführt werden, kann dies, selbst wenn in einem nachfolgenden Link ein Fehler auftritt, zu Problemen führen, da die zuvor erfolgreich ausgeführten Transaktionen ausgeführt und bestätigt wurden. Daher wird in TON ein spezieller Nachrichtentyp festgelegt, 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 Zurücksetzen bestimmter Zustände im Vertrag auslösen, indem er die vom Vertrag reservierte Bounce-Funktion auslöst.

3. In einigen komplexen Fällen wird die zuerst empfangene Transaktion möglicherweise nicht zuerst ausgeführt, sodass diese zeitliche Beziehung nicht voreingestellt werden kann. In einem solchen System asynchroner und paralleler Smart-Contract-Aufrufe kann es schwierig sein, die Reihenfolge der Verarbeitungsvorgänge festzulegen. Aus diesem Grund hat jede Nachricht in TON ihre logische Zeit, die Lamport-Zeit (im Folgenden als lt bezeichnet). Sie 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, die besagt, dass, wenn msg 1 _lt

In komplexeren Fällen wird diese Regel jedoch gebrochen. Im offiziellen Dokument gibt es ein solches Beispiel. Angenommen, wir haben drei Verträge A, B und C. Bei einer Transaktion sendet A zwei interne Nachrichten msg 1 und msg 2: eine an B und die andere an C. Obwohl sie in der genauen Reihenfolge erstellt werden (zuerst msg 1, dann msg 2), können wir nicht sicher sein, dass msg 1 vor msg 2 verarbeitet wird. Dies liegt daran, dass die Routen von A nach B und von A nach C sich in Länge und Validator-Set unterscheiden können. Wenn sich diese Verträge in unterschiedlichen Shard-Ketten befinden, kann eine der Nachrichten mehrere Blöcke benötigen, um den Zielvertrag zu erreichen. Das heißt, wir haben zwei mögliche Transaktionspfade, wie in der Abbildung dargestellt.

4. In TON verwendet die persistente Speicherung seiner Smart Contracts einen gerichteten azyklischen Graphen mit Cell als Einheit als Datenstruktur . Die Daten werden gemäß den Kodierungsregeln kompakt in eine Zelle komprimiert und in der Art eines gerichteten azyklischen Graphen nach unten erweitert. Dies unterscheidet sich von der strukturellen Organisation von Statusdaten basierend auf Hashmap in EVM. Aufgrund unterschiedlicher Datenanforderungsalgorithmen legt TON unterschiedliche Gaspreise für die Datenverarbeitung in unterschiedlichen Tiefen fest. Je tiefer die Zelldatenverarbeitung, desto mehr Gas wird benötigt. Daher gibt es in TON ein Paradigma eines DOS-Angriffs, d. h. einige böswillige Benutzer besetzen alle flachen Zellen in einem Smart Contract, indem sie eine große Anzahl von Spam-Nachrichten senden, was bedeutet, dass die Speicherkosten für ehrliche Benutzer immer höher werden. In EVM gibt es dasselbe Gas, da die Abfragekomplexität von Hashmap o(1) ist und es kein ähnliches Problem gibt. Daher sollten TON-Dapp-Entwickler versuchen, unbegrenzte Datentypen in Smart Contracts zu vermeiden. Wenn unbegrenzte Datentypen auftreten, sollten sie durch Sharding fragmentiert werden.

5. Einige Funktionen sind nicht so besonders, wie z. B. die Notwendigkeit, für Smart Contracts Miete für die Speicherung zu zahlen, die Tatsache, dass Smart Contracts in TON natürlich aktualisierbar sind, und die native abstrakte Kontofunktion, d. h. alle Wallet-Adressen in TON sind Smart Contracts, aber sie werden nicht initialisiert usw., was die besondere Aufmerksamkeit der Entwickler erfordert.

Das Obige sind einige meiner Erfahrungen beim Erlernen von TON-bezogenen Technologien während dieser Zeit. Ich möchte sie gerne mit Ihnen teilen. Wenn es Fehler gibt, hoffe ich, dass Sie mich korrigieren können. Gleichzeitig glaube ich, dass das TON-Ökosystem mit den enormen Verkehrsressourcen von Telegram definitiv einige neue Anwendungen für Web3 bringen wird. Freunde, die an der Entwicklung von TON DApp interessiert sind, können mich auch kontaktieren und mit uns diskutieren.

X-Links: https://x.com/web3_mario

Telegramm-Handle: @MarioChin Web3

Dieser Artikel stammt aus dem Internet: Detaillierte Beschreibung der technischen Funktionen von TON und des Paradigmas der Smart Contract-Entwicklung

Verwandt: Interpreting Based Memes und Based Institute: Wo liegt die Zukunft des Base-Ökosystems?

Originalquelle: Jesse Pollak Zusammengestellt von: Odaily Planet Daily Wenser Anmerkung der Redaktion: Als eines der heißesten L2-Ökosysteme im Jahr 2024 kann man sagen, dass der Aufstieg von Base das Ergebnis der richtigen Zeit, des richtigen Ortes und der richtigen Leute ist – es hat nicht nur die himmlische Gelegenheit, die der Memecoin-Wahn mit sich gebracht hat, sondern auch das L2-Low-Gas-Netzwerk, das auf dem OP-Ökosystem basiert und von Coinbase unterstützt wird, und die harte Arbeit des Protokollleiters Jesse Pollak und einer Gruppe von Ökosystem-Erbauern. Was das Base-Ökosystem betrifft, dessen TVL 5,5 Milliarden US-Dollar erreicht hat, gab Jesse kürzlich beim New York Meme Hackathon einen kurzen Überblick und eine Zusammenfassung und stellte den Inhalt kürzlich in Form von NFT auf Zora und hat mehr als 4.000 geprägt…