Introduction : Après que Binance ait lancé Notcoin, le plus grand jeu de l’écosystème TON, et que son économie de jetons entièrement en circulation ait créé un énorme effet de richesse, TON a rapidement attiré beaucoup d’attention. En discutant avec des amis, j’ai découvert que TON a une barrière technique élevée et que son modèle de développement DApp est très différent des protocoles blockchain traditionnels. J’ai donc passé du temps à faire des recherches approfondies sur ce sujet et j’ai quelques idées à partager avec vous. Dans Short, la philosophie de conception de base de TON consiste à reconstruire les protocoles blockchain traditionnels à partir de zéro, en se concentrant sur l’obtention d’une concurrence et d’une évolutivité élevées, même si cela signifie sacrifier l’interopérabilité.

TON - Concurrence et évolutivité élevées

On peut dire que l’objectif de toutes les sélections technologiques complexes dans TON provient de la poursuite d’une concurrence et d’une évolutivité élevées. Bien sûr, il ne nous est pas difficile de comprendre cela à partir de l’arrière-plan de sa naissance. TON, ou The Open Network, est un réseau informatique décentralisé qui comprend une blockchain L1 et plusieurs composants. TON a été développé à l’origine par le fondateur de Telegram, Nikolai Durov, et son équipe, et est maintenant soutenu et maintenu par une communauté mondiale de contributeurs indépendants. Sa naissance remonte à 2017, lorsque l’équipe de Telegram a commencé à explorer les solutions blockchain pour elle-même. Étant donné qu’aucune blockchain L1 existante à l’époque ne pouvait support la base d’utilisateurs à neuf chiffres de Telegram, ils ont décidé de concevoir leur propre blockchain, alors appelée Telegram Open Network. Le moment est venu en 2018. Dans le ordre d’obtenir les ressources nécessaires à la mise en œuvre de TON, Telegram a lancé une vente de jetons Gram (rebaptisés plus tard Toncoin) au premier trimestre 2018. En 2020, l’équipe Telegram s’est retirée du projet TON en raison de problèmes réglementaires. Par la suite, un petit groupe de développeurs open source et de gagnants du concours Telegram ont repris la base de code de TON, ont renommé le projet The Open Network et continuent à développer activement la blockchain à ce jour, en adhérant aux principes décrits dans le livre blanc original de TON.

Comme TON a été conçu pour être l’environnement d’exécution décentralisé de Telegram, il a dû relever deux défis principaux : un nombre élevé de demandes simultanées et des données massives. Même le TPS (transactions par seconde) le plus élevé de Solana, qui prétend être le plus rapide, n’est que de 65 000, bien short du million de TPS nécessaires pour Telegram. De plus, l’énorme quantité de données générées par Telegram ne peut pas être gérée par une blockchain où chaque nœud stocke une copie complète des données.

Pour relever ces défis, TON a optimisé les protocoles blockchain grand public de deux manières :

l Il utilise un « paradigme de Sharding infini » pour réduire la redondance des données, ce qui lui permet de gérer de grandes quantités de données et d’atténuer les goulots d’étranglement des performances.

l En introduisant un environnement d’exécution entièrement parallèle basé sur le modèle Actor, le TPS réseau est grandement amélioré ;

Construire un Blockchain de chaînes - fournir à chaque compte sa propre chaîne dédiée via Infinite Sharding

Nous savons maintenant que le sharding est devenu la solution courante pour la plupart des protocoles blockchain afin d’améliorer les performances et de réduire les coûts, et TON a poussé cela à l’extrême et a proposé le paradigme du sharding infini, le paradigme du sharding infini. Permet à la blockchain d’augmenter ou de diminuer dynamiquement le nombre de partitions en fonction de la charge du réseau. Ce paradigme permet à TON de gérer des transactions à grande échelle et des opérations de contrats intelligents tout en maintenant des performances élevées. En théorie, TON pouvez établir une chaîne de compte exclusive pour chaque compte et assurer l’interopérabilité entre ces chaînes grâce à certaines règles. consistance

Essentiellement, la structure de la chaîne de TON se compose de quatre couches

AccountChain : cette couche représente une série de transactions liées à un compte spécifique. Les transactions forment une chaîne car, dans une machine d’état, des règles d’exécution cohérentes garantissent que la machine d’état produit les mêmes résultats lors du traitement d’instructions dans le même ordre. Par conséquent, tous les systèmes blockchain exigent que les transactions soient liées dans une chaîne, et TON n’est pas différent. La AccountChain est l’unité la plus fondamentale du réseau TON. En règle générale, l’AccountChain est un concept virtuel, et il est peu probable qu’une AccountChain indépendante existe.

ShardChain : Dans la plupart des contextes, ShardChain est l’unité réelle au sein de TON. Une ShardChain est essentiellement une collection d’AccountChains.

WorkChain : également connu sous le nom d’ensemble de chaînes de partitions avec des règles personnalisées, telles que la création d’une WorkChain basée sur le EVM pour exécuter Solidity smart contracts. En théorie, n’importe quel membre de la communauté peut créer sa propre chaîne de travail. Cependant, en construire un est assez complexe et nécessite de payer les frais de création (élevés) et d’obtenir l’approbation des 2/3 des validateurs.

MasterChain : Dans TON, il existe une chaîne unique appelée MasterChain, qui fournit une finalité à toutes les chaînes de fragments. Lorsque la valeur hash d’un bloc shard chain est incluse dans un bloc MasterChain, ce bloc shard chain et tous ses blocs parents sont considérés comme définitifs, ce qui signifie qu’ils sont fixes et immuables, référencés par tous les blocs shard chain suivants.

Ce paradigme confère au réseau TON trois caractéristiques clés :

Sharding dynamique : TON peut diviser et fusionner automatiquement les chaînes de partitions pour s’adapter à l’évolution des charges, ce qui garantit que de nouveaux blocs sont rapidement générés et que les transactions ne subissent pas de longs retards.

Haute évolutivité : Avec son paradigme de partitionnement infini, TON peut support un nombre presque illimité de partitions, théoriquement jusqu’à 2^60 WorkChains.

Adaptabilité : lorsqu’une partie du réseau subit une charge accrue, elle peut se subdiviser en plusieurs partitions pour gérer les volumes de transactions plus élevés. À l’inverse, lorsque la charge diminue, les partitions peuvent fusionner pour améliorer l’efficacité.

Dans un système multi-chaînes comme celui-ci, le principal défi est la communication cross-chain. Grâce à la capacité de partitionnement infini, lorsque le nombre de partitions dans le réseau augmente de manière significative, le routage des informations entre les chaînes devient complexe. Par exemple, imaginez un réseau avec quatre nœuds, chacun maintenant une chaîne de travail indépendante. Chaque nœud, en plus de gérer son propre tri des transactions, doit également surveiller et traiter les changements d’état dans d’autres chaînes. Dans TON, cela se fait en surveillant les messages dans la file d’attente de sortie.

Supposons que le compte A dans WorkChain 1 veuille envoyer un message au compte C dans WorkChain 3. Cela nécessite de concevoir une solution de routage des messages. Dans cet exemple, il existe deux chemins de routage : WorkChain 1 -> WorkChain 2 -> WorkChain 3 et WorkChain 1 -> WorkChain 4 -> WorkChain 3.

Dans les scénarios plus complexes, un algorithme de routage efficace et peu coûteux est nécessaire pour une communication rapide des messages. TON utilise l’algorithme de routage hypercube pour la découverte du routage des messages cross-chain. Une structure d’hypercube est une topologie de réseau spéciale où un hypercube à n dimensions a 2^n sommets, chacun identifié de manière unique par un nombre binaire de n bits. Dans cette structure, deux sommets quelconques sont adjacents si leurs représentations binaires ne diffèrent que d’un bit. Par exemple, dans un hypercube à 3 dimensions, le sommet 000 et le sommet 001 sont adjacents car ils ne diffèrent que par le dernier bit. L’exemple ci-dessus est un hypercube à 2 dimensions.

Dans le protocole de routage hypercube, le routage d’un message de la WorkChain source vers la WorkChain cible se fait en comparant leurs adresses binaires. L’algorithme trouve la distance minimale entre ces adresses (c’est-à-dire le nombre de bits différents) et transfère le message via des WorkChains adjacentes jusqu’à ce qu’il atteigne sa destination. Cela permet de s’assurer que le paquet de données suit le chemin le plus court, ce qui améliore l’efficacité de la communication réseau. Pour simplifier ce processus, TON propose également une solution optimiste. Si un utilisateur peut fournir une preuve valide d’un chemin de routage, généralement une racine trie de Merkle, le nœud peut immédiatement vérifier l’authenticité du message. C’est ce qu’on appelle le routage hypercube instantané. En conséquence, les adresses TON diffèrent considérablement de celles des autres protocoles blockchain. La plupart des protocoles blockchain utilisent le hash d’une clé publique générée par des algorithmes de chiffrement elliptique comme adresse, en se concentrant sur l’unicité sans avoir besoin de fonctions de routage. Dans TON, les adresses sont constituées de deux parties : (workchain_id, compte_id), avec workchain_id codées selon l’algorithme de routage de l’hypercube. On pourrait se demander pourquoi ne pas relayer toutes les informations cross-chain à travers la MasterChain, similaire à Cosmos. Dans la conception de TON, la MasterChain ne gère que la tâche la plus critique de maintenir la finalité des WorkChains. Bien qu’il soit possible d’acheminer des messages via la MasterChain, les frais associés seraient prohibitifs.

Enfin, discutons brièvement de son algorithme de consensus. TON utilise une combinaison de BFT (tolérance Faute byzantine) et de PoS (Preuve d'enjeu). Cela signifie que n’importe quel staker peut participer à la création de blocs. Le contrat de gouvernance électorale TON sélectionne périodiquement un groupe de validateurs au hasard parmi tous les stakers. Ces validateurs sélectionnés utilisent ensuite l’algorithme BFT pour créer des blocs. Si un validateur crée des blocs invalides ou agit de manière malveillante, ses tokens stakés sont confisqués. À l’inverse, ils reçoivent des récompenses pour avoir réussi à créer des blocs valides. Cette méthode est assez courante, nous n’entrerons donc pas dans les détails ici.

Contrats intelligents utilisant le modèle Actor dans un environnement d’exécution entièrement parallèle

Une autre différence clé dans TON par rapport aux protocoles blockchain traditionnels est son environnement d’exécution de contrats intelligents. Pour surmonter les TPS limitations auxquelles sont confrontés les protocoles blockchain traditionnels, TON utilise une approche de conception ascendante et utilise le modèle Actor pour reconstruire les smart contracts et leur exécution, permettant ainsi des capacités d’exécution entièrement parallèles.

La plupart des protocoles blockchain grand public utilisent un environnement d’exécution en série à thread unique. Par exemple, l’environnement d’exécution d’Ethereum, l’EVM, fonctionne comme une machine d’état qui traite les transactions de manière séquentielle. Une fois qu’un bloc est formé et que les transactions sont ordonnées, elles sont exécutées une par une via l’EVM. Ce processus entièrement série et monothread signifie qu’une seule transaction est traitée à un moment donné. L’avantage est qu’une fois l’ordre de transaction établi, les résultats d’exécution restent cohérents sur un réseau distribué. De plus, étant donné qu’une seule transaction est exécutée à la fois, aucune autre transaction ne peut modifier les données d’état auxquelles vous accédez, ce qui garantit l’interopérabilité entre les smart contracts. Par exemple, lorsque vous utilisez Uniswap pour acheter de l’ETH avec des USDT, la distribution du pool de liquidité est une valeur fixe lors de l’exécution. Cela permet aux modèles mathématiques de déterminer le résultat exact. Inversement, si d’autres fournisseurs de liquidités ajoutaient des liquidités lors du calcul de la bonding curve, les résultats seraient obsolètes, ce qui est clairement inacceptable.

Cependant, cette architecture présente également des limites claires, en particulier le goulot d’étranglement TPS, qui semble obsolète avec les processeurs multicœurs modernes. C’est comme jouer à de vieux jeux informatiques comme Red Alert sur un tout nouveau PC ; Lorsque le nombre d’unités de combat atteint un certain niveau, vous rencontrez toujours un décalage important. Cela est dû à des problèmes d’architecture logicielle.

Certains protocoles s’attaquent à ce problème et ont proposé leurs propres solutions parallèles. Par exemple, Solana, qui prétend avoir le TPS le plus élevé, prend également en charge l’exécution parallèle. Cependant, le design de Solana diffère de celui de TON. L’idée de base de Solana est de regrouper toutes les transactions en fonction de leurs dépendances d’exécution, en veillant à ce que différents groupes ne partagent aucune donnée d’état. Cela signifie qu’il n’y a pas de dépendances partagées, ce qui permet aux transactions de différents groupes de s’exécuter en parallèle sans conflit. Les transactions au sein d’un même groupe sont toujours exécutées en série.

En revanche, TON abandonne complètement l’architecture d’exécution en série et adopte un paradigme de développement spécifiquement conçu pour le parallélisme, en utilisant le modèle Actor pour reconstruire son environnement d’exécution. Le modèle de l’acteur, proposé pour la première fois par Carl Hewitt en 1973, vise à résoudre la complexité des états partagés dans les programmes concurrents traditionnels grâce à la transmission de messages. Chaque acteur a son propre état privé et son propre comportement et ne partage pas d’informations d’état avec d’autres acteurs. Le modèle Actor est un modèle de calcul de concurrence qui réalise un traitement parallèle via la transmission de messages. Dans ce modèle, un « acteur » est une unité de base qui peut gérer les messages reçus, créer de nouveaux acteurs, envoyer des messages supplémentaires et décider comment répondre aux messages suivants. Le modèle Actor doit présenter les caractéristiques suivantes :

Encapsulation et indépendance : chaque acteur opère de manière totalement indépendante lors du traitement des messages, ce qui permet un traitement parallèle des messages sans interférence.

Transmission de messages : les acteurs interagissent uniquement par l’envoi et la réception de messages, la transmission de messages étant asynchrone.

Structure dynamique : les acteurs peuvent créer des acteurs supplémentaires au moment de l’exécution, ce qui permet au modèle d’acteur d’étendre dynamiquement le système en fonction des besoins.

TON adopte cette architecture pour son modèle de contrat intelligent, ce qui signifie que chaque contrat intelligent dans TON est basé sur le modèle Actor et dispose d’un stockage complètement indépendant car il ne dépend d’aucune donnée externe. De plus, les appels vers le même contrat intelligent sont exécutés dans l’ordre des messages dans la file d’attente de réception. Cela permet aux transactions en TON d’être exécutées en parallèle efficacement, sans se soucier des conflits. Cependant, cette conception introduit également de nouveaux défis. Pour les développeurs DApp, leur paradigme de développement familier sera perturbé de la manière suivante :

1. Appels Smart Contract asynchrones : dans TON, il est impossible d’appeler atomiquement des contrats externes ou d’accéder à des données de contrat externes dans smart contracts. Dans Solidity, par exemple, il est simple pour la fonction du contrat A1 d’appeler la fonction du contrat B2 ou d’accéder à certaines données d’état via la fonction en lecture seule3 du contrat C, le tout en une seule transaction. Cependant, à TON, cela ne peut pas être réalisé. Toute interaction avec des smart contracts externes sera exécutée de manière asynchrone en créant de nouvelles transactions, appelées messages internes initiés par des smart contracts. Le processus d’exécution ne peut pas être bloqué dans l’attente du résultat.

Par exemple, si nous développons un DEX et suivons le paradigme EVM commun, nous avons généralement un contrat de routeur unifié pour gérer le routage des transactions, tandis que chaque pool gère indépendamment les données LP pour des paires de trading spécifiques. Disons que nous avons deux pools : USDT-DAI et DAI-ETH. Lorsqu’un utilisateur souhaite acheter de l’ETH directement avec des USDT, il peut utiliser le contrat de routeur pour interagir séquentiellement avec ces deux pools en une seule transaction atomique. Cependant, dans TON, ce processus n’est pas aussi simple et nécessite une approche de développement différente. Si nous essayons de réutiliser ce paradigme EVM, le flux d’informations impliquerait un message externe initié par l’utilisateur et trois messages internes pour terminer la transaction (notez que cet exemple est destiné à mettre en évidence les différences ; dans le développement réel, même le paradigme ERC20 devrait être repensé).

1. Une attention particulière doit être portée à la gestion des erreurs dans les appels inter-contrats, en concevant des fonctions de rebond appropriées pour chaque interaction inter-contrats. Dans les systèmes EVM courants, si une erreur se produit lors de l’exécution de la transaction, l’ensemble de la transaction est restauré à son état initial. C’est simple dans un modèle monothread en série. Cependant, dans TON, étant donné que les appels inter-contrats sont exécutés de manière asynchrone, si une erreur se produit à un stade ultérieur, les transactions précédemment exécutées avec succès ont déjà été confirmées, ce qui peut entraîner des problèmes. Par conséquent, TON a introduit un type de message spécial appelé message de rebond. Si une erreur se produit lors de l’exécution ultérieure d’un message interne, le contrat déclenché peut utiliser la fonction bounce réservée dans le contrat déclencheur pour réinitialiser certains états du contrat déclencheur.

2. Dans les scénarios complexes, les transactions reçues en premier peuvent ne pas être terminées en premier, vous ne pouvez donc pas supposer un ordre d’exécution spécifique. Dans un système de contrat intelligent asynchrone et parallèle, la définition de l’ordre de traitement peut être difficile. C’est pourquoi chaque message dans TON a son heure logique, connue sous le nom de Lamport time (lt). Il permet de déterminer quel événement en a déclenché un autre et ce que les validateurs doivent traiter en premier. Dans un modèle simple, les transactions reçues en premier sont exécutées en premier.

Dans ce modèle, A et B représentent deux smart contracts. Si msg1_lt < msg2_lt, alors tx1_lt < tx2_lt en termes de séquence.

Cependant, dans des situations plus complexes, cette règle peut être enfreinte. La documentation officielle fournit un exemple : supposons que nous ayons trois contrats, A, B et C. Dans une transaction, A envoie deux messages internes, msg1 et msg2, l’un à B et l’autre à C. Bien qu’ils soient créés dans un ordre spécifique (msg1 d’abord, puis msg2), nous ne pouvons pas être certains que msg1 sera traité avant msg2. Cette incertitude est due au fait que les routes de A à B et de A à C peuvent différer en termes de longueur et d’ensembles de validateurs. Si ces contrats se trouvent dans des chaînes de partitions différentes, un message peut prendre plusieurs blocs pour atteindre le contrat cible. Par conséquent, il existe deux chemins de transaction possibles, comme illustré.

1. Dans TON, le stockage persistant des smart contracts utilise une structure directed acyclic graph (DAG) avec des cellules comme unités. Les données sont compressées de manière compacte dans une cellule selon des règles de codage spécifiques et s’étendent vers le bas à la manière d’un DAG. Cela contraste avec la structure basée sur la carte de hachage utilisée dans EVM pour les données d’état. En raison de différents algorithmes d’accès aux données, TON attribue des prix de gaz variables pour le traitement des données à différentes profondeurs ; Un traitement plus approfondi des données cellulaires nécessite plus de gas. Par conséquent, TON est confronté à un type d’attaque DOS, où des utilisateurs malveillants inondent un contrat intelligent d’un grand nombre de messages indésirables, remplissant toutes les cellules peu profondes. Cela augmente les coûts de stockage pour les utilisateurs honnêtes. En revanche, la carte de hachage d’EVM a une complexité de requête de O(1), ce qui garantit des coûts de gas cohérents et évite des problèmes similaires. Par conséquent, les développeurs TON Dapp doivent éviter d’utiliser des types de données illimités dans smart contracts. Lorsque des types de données illimités sont nécessaires, ils doivent être partitionnés à l’aide du partitionnement.

1. Certaines fonctionnalités sont moins uniques, comme l’obligation pour les smart contracts de payer un loyer pour le stockage. En TON, smart contracts sont intrinsèquement évolutifs et sont livrés avec des fonctions de compte abstraites natives, ce qui signifie que toutes les adresses de portefeuille dans TON sont smart contracts, mais non initialisées. Les développeurs doivent porter une attention particulière à ces aspects.

Theblockbeats]. Tous les droits d’auteur appartiennent à l’auteur original [Web3Mario]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.