Am 31. Oktober 2023 stellte TON (ehemals Telegram Open Network) einen neuen Weltrekord auf und erreichte im ersten öffentlichen Performance-Live-Test einen erstaunlichen Spitzenwert von 104.715 Transaktionen pro Sekunde, wodurch insgesamt 107.652.545 Transaktionen in 25 Minuten abgeschlossen wurden. Diese von Certik verifizierte und bestätigte Leistung macht TON zur schnellsten und skalierbarsten Blockchain der Welt und übertrifft die Verarbeitungsgeschwindigkeit aller L1-Blockchains und bekannter zentralisierter Zahlungsnetzwerke wie PayPal, Visa und Mastercard.
TON ist zweifellos ein auffälliges Projekt. Dieser Artikel bietet eine ausführliche Analyse des TON-Whitepapers und enthüllt seine einzigartigen technischen Merkmale und Innovationen sowie die Gründe, warum TON zur schnellsten Blockchain der Welt werden kann.
Erweiterungsproblem
Skalierbarkeit war schon immer ein großes Problem bei der Entwicklung der Blockchain-Technologie. Der Ausbauplan der Blockchain besteht hauptsächlich darin, den Durchsatz des Systems zu verbessern und die Transaktionskosten zu senken, damit das Blockchain-Netzwerk mehr Transaktionen abwickeln und sich besser an Großanwendungen anpassen kann. Obwohl verschiedene öffentliche Ketten weiterhin neue Konsens- und Architekturdesigns ausprobieren, sind die aktuellen Ergebnisse immer noch unbefriedigend und haben sich zu einem Engpass für die Entwicklung der Blockchain in Richtung groß angelegter Anwendungen entwickelt, was es schwierig macht, unsere TG-Vision von einer Milliarde Benutzern umzusetzen. Die aktuellen Mainstream-Erweiterungslösungen lassen sich in die folgenden Kategorien einteilen:
Sharding: Teilen Sie das Netzwerk in mehrere kleinere Teile auf. Jeder Shard kann Transaktionen und Smart Contracts parallel verarbeiten, wodurch der Durchsatz des Netzwerks erheblich verbessert wird. Allerdings bringt Sharding potenzielle Sicherheitsprobleme mit sich, da jeder Shard möglicherweise weniger sicher ist als das gesamte Netzwerk. Darüber hinaus ist die Shard-übergreifende Kommunikation eine technische Herausforderung. Repräsentative Beispiele: das frühere Protokoll Ethereum 2.0 und NEAR Nightshade.
Sidechains: Eine Sidechain ist eine Blockchain, die unabhängig von der Hauptkette arbeitet. Sie kann über einen eigenen Konsensmechanismus und Blockparameter verfügen. Über Sidechains können Benutzer Vermögenswerte zwischen den beiden Chains übertragen und so die Hauptkette entlasten. Repräsentatives Beispiel: Polygon
Layer-2-Lösungen: Durch den Aufbau einer weiteren Strukturebene über der Hauptkette kann L2 schnellere Transaktionsbestätigungszeiten und niedrigere Transaktionsgebühren bieten. Nehmen Sie als Beispiel das bekanntere L2, Optimism und Arbitrum: Bei beiden handelt es sich um Erweiterungslösungen, die speziell für Ethereum entwickelt wurden. Daher befindet sich ein Teil der Architektur von Optimism und Arbitrum in Layer 1. Mit dem Upgrade von Ethereum erhöht sich das TPS-Limit (Transaktion pro Sekunde) von ursprünglich 2-4.000 auf etwa 2 W.
zkSync 2.0: Im Vergleich zum Hunderter-TPS-Limit von zkSync 1.0 bringt zkSync 2.0 erhebliche Verbesserungen. Das zkSync-Team behauptet, dass seine Version 2.0 die Obergrenze von 100.000 TPS erreichen kann, aber die meisten Institutionen gehen davon aus, dass die tatsächliche Obergrenze bei 1-20.000 liegen könnte. Starknet: Nach Abschluss des Quantum Leap-Upgrades im Juni übersteigt sein TPS derzeit 100TPS.
Solana: Solana verwendet einen innovativen Konsensalgorithmus namens Proof of History (PoH) als Kern seines Expansionsplans. Obwohl Solana behauptet, dass sein TPS 65.000 erreichen kann, werden die meisten TPS tatsächlich für die Kommunikation zwischen Knoten verwendet. Das tatsächliche Transaktionsvolumen darf nur auf 6-8.000 TPS begrenzt werden. Aufgrund seines zentralisierten Konsensmechanismus-Designs kam es bei Solana außerdem zu mehreren Ausfallzeiten, wenn es mit einer großen Anzahl von Anfragen konfrontiert wurde, beispielsweise beim NFT-Minting. Darüber hinaus hat Solana die Rotation zentraler Knoten noch nicht erfolgreich umgesetzt.
Die Designer der TON-Blockchain stammen aus dem Gründer- und Kernteam von Telegram. Als eine der beliebtesten sozialen Plattformen der Welt hat Telegram fast 900 Millionen aktive Benutzer pro Monat und bietet gleichzeitig ein hohes Maß an Sicherheit und Datenschutz. Dutzende Milliarden Nachrichten werden innerhalb des Netzwerks übertragen Software jeden Tag Informationen. Das Konzept von web3 ist relativ bekannt geworden, aber die tatsächlichen Nutzer nativer Kryptowährungen sind immer noch in der Minderheit und die meisten Menschen verlassen sich auf zentralisierte Börsen, um auf Token zuzugreifen. Metamask, die weltweit beliebteste dezentrale Krypto-Wallet, hat derzeit nur 30 Millionen aktive Benutzer pro Monat. Das Designkonzept von TON basierte von Anfang an darauf, Milliarden von Benutzern zu bedienen, nicht nur ein paar Web3-Freaks.
unendliches Sharding-Paradigma
Sharding ist ein Konzept, das aus dem Datenbankdesign stammt. Dabei handelt es sich um die Aufteilung eines großen logischen Datensatzes und dessen anschließende Verteilung auf mehrere Datenbanken, die nicht gemeinsam genutzt werden. Diese Datenbanken können auf mehrere Server verteilt sein. Einfach ausgedrückt bietet Sharding die Möglichkeit einer horizontalen Skalierung, sodass Daten in unabhängige Teile aufgeteilt werden können, die parallel verarbeitet werden können.
TON ist nicht das erste Projekt, das die Sharding-Technologie in die Blockchain einführt. Beispielsweise hat Ethereum 2.0 einmal feste 64 Shards angekündigt und dann aufgegeben, weil es zu schwierig war, während NEARs Night Shadow-Protokoll plant, im nächsten Jahr 100 Sharding zu erreichen sind derzeit 4 Shards.
Im Gegensatz zu herkömmlichen Sharding-Methoden verfolgt TON eine Infinite-Sharding-Strategie.
Allerdings gilt der Ansatz von TON als fortschrittlich, nicht weil er mehr Shards hat, sondern wegen zweier einzigartiger Merkmale:
Die Anzahl der Shards ist nicht festgelegt: TON unterstützt je nach Geschäftsanforderungen eine zunehmende Anzahl von Shards, bis zu einem Maximum von 2^60 Arbeitsketten, was einer nahezu unbegrenzten Anzahl entspricht.
Die Anzahl der Shards ist elastisch: TON kann Shards automatisch teilen, wenn die Systemlast hoch ist, und sie zusammenführen, wenn die Last abnimmt. Dies ist eine sehr effektive Strategie für den Umgang mit dynamischen Skalierungsanforderungen.
Derzeit besteht TON aus zwei Arbeitsketten, der Hauptkette (Masterchain) für Synchronisierung und Governance und der Arbeitskette (Workchain) für Smart Contracts. Unter der Arbeitskette befinden sich die Shard-Kette und die unterste virtuelle Kontokette (Kontokette).
Eine Arbeitskette kann in N Shards (von 1 bis 256 Shards) unterteilt werden. Jeder Shard verfügt über einen eigenen Satz von Validatoren. Das Arbeitskettenteam ist für die Ausführung von Transaktionen in seinem eigenen Shard verantwortlich. Gleichzeitig lädt es kontinuierlich Blöcke von allen anderen Shards seiner Arbeitskette herunter. Im Allgemeinen besteht eine Blockchain aus einer Reihe von Blöcken, die Änderungen ihres Zustands aufzeichnen. Bei POS-Blockchains vereinbaren Validatoren zunächst, wie sie den Blockchain-Status ändern möchten, indem sie einen Block mit einer Liste von Änderungen erstellen. Anschließend wird für den Block gestimmt, und wenn genügend Stimmen gesammelt werden, wenden sie den Block auf den Blockchain-Status an und gehen zum nächsten Block über.
Die Durchsatzkapazität eines Blockthreads ist sehr begrenzt, da Validatoren alle Transaktionen in einem Block prüfen müssen, bevor sie der Annahme zustimmen. Es gibt also viele Threads in TON, man kann sie sich einfach als Mini-Mikro-Blockchains vorstellen. Sie existieren nebeneinander und jeder hat seinen eigenen Satz von Validatoren.
Hauptkette
Die Hauptkette ist der Hauptblock-Thread in TON. Es wird verwendet, um alle verbleibenden Blöcke zu synchronisieren und den Validatorsatz neu zu berechnen. Wenn sich alle Threads auf einen neuen Block einigen, signieren sie ihn und registrieren ihn in der Hauptkette. Die Validatoren der Hauptkette überprüfen jedoch nicht die Gültigkeit des Blocks, sondern nur, ob er vom entsprechenden Validator signiert wurde. So viele Threads können parallel koexistieren. Verträge aus verschiedenen Threads kommunizieren miteinander, indem sie Nachrichten senden.
Arbeitskette
Eine Arbeitskette ist ein unabhängiger Adressraum, der gemäß seinen Regeln ausgeführt werden kann. Sie könnten beispielsweise über unterschiedliche virtuelle Maschinen verfügen oder die Zeit verlängern, die zum Veröffentlichen von Blöcken mit hohen Gaslimits benötigt wird. Am wichtigsten ist, dass die Arbeitsketten das gleiche Nachrichtenwarteschlangenformat haben, damit sie Nachrichten austauschen können. Das bedeutet auch, dass alle Arbeitsketten annähernd die gleichen Sicherheitsgarantien haben müssen. Da sie Nachrichten austauschen können, enthalten diese Nachrichten Netzwerk-Token. Es sind nun zwei Arbeitsketten aktiv: die Hauptkette und die Erstverarbeitungs-Arbeitskette. Die Arbeitskette wird durch das Adresspräfix bestimmt: -1:ax...1s2 – die Kontoadresse in der Hauptkette. -1 ist das Hauptkettenpräfix.
0:zx...123 – Kontoadresse in der ersten Jobkette. 0 – ist das Präfix für die erste Verarbeitungsauftragskette.
Splitterkette
Verarbeitungsthreads oder Shard-Ketten sind unabhängige Blockthreads in der Verarbeitungsarbeitskette. Standardmäßig hat Arbeitskette 0 nur einen Thread und eine Kette. Die Validatoren dieses Threads akzeptieren externe Nachrichten und verarbeiten interne Nachrichten, die von ihnen selbst oder von anderen Worker-Ketten gesendet werden. Kommt es zu einer Situation, in der ein Thread während der letzten N Blöcke überlastet ist, wird der Thread aufgeteilt: Ein Thread wird in zwei Threads aufgeteilt, wobei die Transaktionen parallel laufen.
Konten mit Adressen, die mit 0:00.. - 0:88.. beginnen, befinden sich jetzt in Thread 1 und Konten 0:88.. - 0:FF.. befinden sich in Thread 2. Da alle Smart Contracts asynchron miteinander kommunizieren, gibt es keine Störungen und der Durchsatz wird verdreifacht. Wenn die Last sinkt, werden die Threads nach einer Weile wieder zusammengeführt. Steigt die Belastung weiter, können die beiden Threads immer wieder aufgeteilt werden und so weiter. Die Hauptkette hat nur einen Thread.
Ein Block in TON ist mehr als nur eine Liste von Transaktionen, die abgeschlossen werden müssen, um eine Zustandsänderung umzusetzen. Stattdessen ist ein Block:
Führen Sie die Nachrichtenliste der Transaktion aus und entfernen Sie sie aus der Eingangswarteschlange. Neue Nachrichten gelangen nach der Nachrichtenverarbeitung in die Ausgangswarteschlange, und die Nachrichtenverarbeitung führt dann zu einer Änderung des Smart-Contract-Status. Das heißt, damit der Validator von Shard X den aktuellen Status von Shard Y beibehalten kann, muss er nicht alle Transaktionen im Block von Shard Y ausführen. Es lädt lediglich den Block herunter und fasst die vorgenommenen Änderungen zusammen. Tritt in der Nachrichtenwarteschlange und im Smart-Contract-Status auf.
Eine grundlegende Veränderung der Blockchain-Welt kann nicht ohne Kosten erfolgen. Um von diesem radikalen Ansatz profitieren zu können, müssen TON-Smart-Contract-Entwickler ihre Verträge anders gestalten. Die grundlegende atomare Einheit der TON-Blockchain ist der Smart Contract. Intelligente Verträge verfügen über Adressen, Codes und Dateneinheiten (persistenter Zustand). Solche Einheiten werden atomare Einheiten genannt, da ein Smart Contract immer über einen atomaren synchronisierten Zugriff auf alle seine persistenten Zustände verfügt.
Hypercube-Netzwerkrouting
TON hat einen einzigartigen intelligenten Routing-Mechanismus entwickelt, um sicherzustellen, dass Transaktionen zwischen zwei beliebigen Blockchains immer schnell verarbeitet werden können. Unabhängig von der Größe des Systems erhöht sich die zum Senden von Informationen zwischen TON-Blockchains erforderliche Zeit nur logarithmisch mit der Anzahl der Ketten Die Anzahl der Wege nimmt zu, sodass selbst die Skalierung auf Millionen von Ketten eine Kommunikation mit der schnellstmöglichen Geschwindigkeit ermöglicht.
In der TON-Blockchain sind Instant Hypercube Routing und Slow Routing zwei Routing-Mechanismen, die zur Abwicklung kettenübergreifender Transaktionen verwendet werden.
Instant Hypercube Routing: Die von TON vorgeschlagene Idee, das Nachrichtenrouting zu beschleunigen, sodass kettenübergreifende Transaktionen in sehr kurzer Zeit abgeschlossen werden können. Beim herkömmlichen langsamen Cube-Routing-Prozess wird eine Nachricht von einer Shard-Kette entlang des Hypercube-Netzwerks an die Ziel-Shard-Kette weitergeleitet. Während des Nachrichtenweiterleitungsprozesses kann der Validator (Validator), zu dem die Ziel-Shard-Kette der Nachricht gehört, jedoch entscheiden, die Nachricht im Voraus zu verarbeiten und dem Block hinzuzufügen, und dann einen Merkel-Beweis (Quittung) bereitzustellen und einen zu senden Empfang, um die laufende Nachricht zu vernichten. Dadurch können kettenübergreifende Transaktionen in extrem kurzer Zeit abgeschlossen werden. Express Routing erreicht eine effiziente kettenübergreifende Interaktion durch den Aufbau einer hochdimensionalen Cube-Routing-Struktur (Hypercube). In dieser Struktur wird jede Kette einem Scheitelpunkt des Würfels zugeordnet und der Abstand zwischen den Ketten wird als Anzahl der Sprünge zwischen den Scheitelpunkten ausgedrückt. Durch diese Methode können Transaktionen schnell auf dem kürzesten Weg weitergeleitet werden, was effiziente kettenübergreifende Interaktionen ermöglicht. Schnelles Routing kann kettenübergreifende Transaktionen in Sekundenschnelle abschließen, ohne auf Blockbestätigungen warten zu müssen.
Langsames Routing: Langsames Routing ist eine relativ traditionelle kettenübergreifende Transaktionsverarbeitungsmethode, die durch schrittweises Übertragen von Transaktionen von der Quellkette auf die Zielkette implementiert wird. Bei diesem Ansatz werden Transaktionen zunächst in einen Block auf der Quellkette gepackt und dann über einen Relayer an die Zielkette übertragen. Der Validator der Zielkette überprüft die Gültigkeit der Transaktion und packt sie dann in einen Block auf der Zielkette. Der Vorteil des langsamen Routings gegenüber dem schnellen Routing besteht darin, dass es eine höhere Sicherheit und Dezentralisierung bietet, da kettenübergreifende Transaktionen einen vollständigen Blockbestätigungsprozess durchlaufen müssen. Ähnlich wie beim TCP/IP-Netzwerk kann durch das Senden an das Ziel über die Ziel-IP-Adresse sichergestellt werden, dass die Nachricht der Reihe nach zuverlässig an die Zielkette weitergeleitet wird. Für ein Shard-Chain-Hypercube-Netzwerk der Größe N sind die Zwischen-Shard-Ketten, die durch Hop geleitet werden müssen, = log16(N)-1. Daher sind nur 4 Routing-Knoten (Zwischen-Shard-Ketten) erforderlich, um Millionen von Shard-Ketten zu unterstützen.
Warum ist es so konzipiert?
Für die Verteilung sind Verifizierungsknoten erforderlich. Wenn das System sehr groß ist und Zehntausende Knoten hat, ist die Belastung zu groß und kann nicht erweitert werden. Nach dem Sharding hat jeder Shard einen Satz, Shard0, Shard1 ... und es muss eine Shard-übergreifende Kommunikation erreicht werden. Die Kommunikation kann über Shards hinweg erfolgen. Dies bedeutet, dass zwischen den Shards ein Routing-Mechanismus vorhanden sein muss. Die Verbindungen bilden eine Route, die durch einige Zwischenknoten übersprungen wird. Jedes Mal, wenn Informationen eine Route durchlaufen, entspricht dies einer Verlängerung der Übertragungszeit um eine Blockzeit.
Da die Gesamtzahl der Shard-Ketten wächst, wird dies viel Rechenleistung und Netzwerkbandbreite erfordern und somit die Skalierbarkeit des Systems einschränken. Daher ist es nicht möglich, Nachrichten von einem Shard direkt an alle anderen Shards weiterzuleiten. Stattdessen ist jeder Shard nur mit Shards „verbunden“, die sich durch eine hexadezimale Ziffer ihrer (w,s) Shard-ID unterscheiden. Auf diese Weise bilden alle Shard-Ketten einen „Hypercube“-Graphen, und Nachrichten werden entlang der Ränder dieses Hypercubes weitergeleitet.
Wenn die Nachricht an einen anderen Shard als den aktuellen gesendet wird, wird eine Hexadezimalzahl der aktuellen Shard-Kennung (deterministisch ausgewählt) durch die entsprechende Nummer des Ziel-Shards ersetzt und die resultierende Kennung als ungefähres Ziel verwendet. wird zum Empfänger der weitergeleiteten Nachricht.
Der Hauptvorteil des Hypercube-Routings ist die Blockgültigkeitsbedingung. Validatoren, die Shard-Chain-Blöcke erstellen, müssen Nachrichten in den Ausgabewarteschlangen „benachbarter“ Shard-Ketten sammeln und verarbeiten, sonst verlieren sie ihren Einsatz. Auf diese Weise kann davon ausgegangen werden, dass jede Nachricht früher oder später ihr endgültiges Ziel erreicht; Nachrichten gehen während der Übertragung weder verloren noch werden sie dupliziert.
Hypercube-Routing bringt zusätzliche Latenz und Kosten mit sich, da Nachrichten über mehrere zwischengeschaltete Shard-Ketten weitergeleitet werden müssen. Die Anzahl dieser intermediären Shard-Ketten wächst jedoch sehr langsam, bezogen auf den Logarithmus der Gesamtzahl der Shard-Ketten N, log N.
Kommunikation asynchron
Die Smart Contracts auf TON implementieren asynchrone Kommunikation. Die Smart Contracts auf TON können mit Internet-Microservices verglichen werden. Jeder Microservice hat nur atomaren synchronen Zugriff auf seine lokalen Daten. Bei der Kommunikation zwischen zwei Mikrodiensten werden asynchrone Nachrichten über das Netzwerk gesendet.
In der Systemarchitektur müssen größere Systeme häufig Microservices erstellen. Dieser verteilte Ansatz erfordert einige Kompromisse, kann jedoch Vorteile für die Benutzererfahrung mit sich bringen. Das moderne Systemmanagement verlässt sich auf Sequenzer wie Kubernetes, um eine Reihe von Container-Microservices zu übernehmen und bei Bedarf automatisch neue Instanzen zu starten (Autoscaling) und diese effizient zwischen Maschinen zu verteilen.
Um die Analogie von Kubernetes (einem groß angelegten Cluster-Management-System) zu verwenden: Genau das macht TON. Wenn die Belastung einer bestimmten Shard-Kette zunimmt, wird sie in zwei Teile geteilt. Da Smart Contracts atomar sind, können sie niemals in zwei Hälften geteilt werden. Das bedeutet, dass einige Smart Contracts, die sich einst in derselben Shard-Kette befanden, sich eines Tages möglicherweise in einer anderen Shard-Kette wiederfinden.
Die Virtual Machine (TVM) von TON wendet das Konzept verteilter Mikrodienste auf die Gesamtarchitektur der Ethereum EVM an.
Staatliche Dezentralisierung
Dies ist der komplexeste und anspruchsvollste Sharding-Mechanismus im Bereich Sharding. Die gesamte Datenbank wird getrennt und auf verschiedenen Shards platziert. Jeder Shard speichert alle Daten in seinem eigenen Shard und nicht den Status der gesamten Blockchain.
Beim TON-Blockchain-Sharding werden alle Dienste in Form von Smart Contracts implementiert und die Statusdaten der Smart Contracts werden nur im entsprechenden Sharding-Netzwerk gespeichert, um State Sharding zu erreichen.
Darüber hinaus implementieren Verträge in TON einen in der Branche einzigartigen Implementierungspfad. Jeder Benutzer kann den Token-Status in seinem eigenen Vertrag verwalten und so eine echte Dezentralisierung vom Blockchain-Status erreichen. Ich erkunde die Prinzipien dieses Designs im Detail anhand von Fällen.
Zunächst müssen Sie den Wallet-Vertrag und den Jetton-Wallet-Vertrag verstehen. Der Wallet-Vertrag ist ein benutzerspezifischer Smart-Vertrag, der zur Verwaltung der Benutzer-Tokens auf der TON-Blockchain verwendet wird. Der Jetton-Wallet-Vertrag (russisch: gem) ist ein spezieller Wallet-Vertrag, der speziell zur Verwaltung der Jetton-Pässe der Benutzer verwendet wird. Mit diesen Token können Netzwerkgebühren bezahlt und Smart Contracts ausgeführt werden. Jeder Benutzer hat seinen eigenen Wallet-Vertrag und seinen eigenen Jetton-Wallet-Vertrag. Diese Verträge fungieren als digitale Geldbörsen der Benutzer zum Speichern und Verwalten von Token. Gleichzeitig können diese Verträge auch mit den Verträgen anderer Benutzer interagieren, um eine dezentrale Vermögensübertragung und Transaktionen zu erreichen.
Derzeit wird davon ausgegangen, dass Benutzer A und Benutzer B jeweils über einen eigenen Wallet-Vertrag verfügen. Benutzer A möchte eine bestimmte Anzahl Token an Benutzer B übertragen. In diesem Fall interagiert der Wallet-Vertrag von Benutzer A mit dem Wallet-Vertrag von Benutzer B, um die Übertragung von Token zu realisieren. Der gesamte Prozess muss nicht auf einen zentralen Vertrag angewiesen sein, sondern wird über zwei dezentrale Verträge umgesetzt.
Alle Benutzer der TON-Blockchain haben ihre eigenen Verträge zur Verwaltung des Status ihrer Vermögenswerte, was bedeutet, dass es keinen einzelnen zentralisierten Vertrag gibt, der das Risiko für die Verwaltung aller Vermögenswerte trägt. Dies verbessert die Dezentralisierung des Systems und verringert das Risiko von Single Points of Failure. Der Vermögensstatus aller Benutzer wird durch einen exklusiven Vertrag verwaltet, und Angreifer können nicht das gesamte System durch Angriffe auf einen einzelnen zentralen Vertrag beeinflussen. Asset-Transaktionen zwischen Benutzern können auch automatisch durch intelligente Verträge ausgeführt werden, wodurch das Risiko menschlicher Vorgänge vermieden wird. Sie können auch Ihren eigenen Wallet-Vertrag und Jetton-Wallet-Vertrag an Ihre Bedürfnisse anpassen, um mehr Funktionen und Anwendungsszenarien zu erreichen. Dies bietet Benutzern mehr Flexibilität und Autonomie. Jeder verwaltet den Vermögensstatus in seinen eigenen Verträgen und die Skalierbarkeit des Systems wird verbessert. Mit steigender Nutzerzahl erhöht sich auch die Anzahl der Verträge, was aber nicht zu einer übermäßigen Belastung des Gesamtsystems führt, da jeder Vertrag unabhängig läuft.
Das Obige ist meine Analyse der Skalierbarkeit der TON-Blockchain und des technischen Architekturkonzepts des Whitepapers. Ich möchte Dr. Awesome Doge für die Bearbeitung des ersten Entwurfs danken. Vielen Dank an die russischen und ukrainischen Entwicklungsteams für ihren unermüdlichen Einsatz und schließlich an Herrn Nikolai Durov, den Gründer von Telegram, für seine großartigen Designs vor vielen Jahren, die alle der Ehre des menschlichen Geistes dienen.
