Description détaillée des fonctionnalités techniques de TON et du paradigme de développement des contrats intelligents

Auteur original : @Web3 Mario

Introduction : Avec le lancement de Notcoin, le plus grand jeu de l'écosystème TON, sur Binance et l'énorme effet de richesse provoqué par le modèle économique des jetons entièrement en circulation, TON a suscité une grande attention en peu de temps. Après avoir discuté avec un ami, j'ai appris que le seuil technique de TON est relativement élevé et que le paradigme de développement DApp est très différent du protocole de chaîne publique traditionnel. Par conséquent, j'ai passé un certain temps à étudier en profondeur les sujets pertinents et j'ai une certaine expérience à partager avec vous. En bref, le concept de conception de base de TON est de reconstruire le protocole de blockchain traditionnel de manière ascendante et d'atteindre la poursuite ultime d'une concurrence élevée et d'une évolutivité élevée au prix de l'abandon de l'interopérabilité.

Le concept de base de TON – haute concurrence et haute évolutivité

On peut dire que le but de toute la sélection technologique complexe dans TON vient de la recherche d'une concurrence élevée et d'une grande évolutivité. Bien sûr, il n'est pas difficile pour nous de comprendre cela à partir du contexte de sa naissance. TON, ou The Open Network, est un réseau informatique décentralisé composé d'une blockchain L1 et de plusieurs composants. TON a été développé à l'origine par le fondateur de Telegram, Nikolai Durov, et son équipe, et il est désormais soutenu et maintenu par une communauté de contributeurs indépendants du monde entier. Sa naissance remonte à 2017, lorsque l'équipe Telegram a commencé à explorer elle-même des solutions blockchain. Comme il n'existait pas de blockchain L1 capable de prendre en charge la base d'utilisateurs à neuf chiffres de Telegram à l'époque, ils ont décidé de concevoir leur propre blockchain, qui s'appelait alors Telegram Open Network. Le temps est venu d'arriver en 2018. Afin d'obtenir les ressources nécessaires à la réalisation de TON, Telegram a lancé la vente de jetons Gram (rebaptisés plus tard Toncoin) au premier trimestre 2018. En 2020, en raison de problèmes réglementaires, l'équipe Telegram s'est retirée du projet TON. Par la suite, un petit groupe de développeurs open source et de gagnants du concours Telegram ont repris la base de code TON, ont renommé le projet The Open Network et continuent de développer activement la blockchain à ce jour, en suivant les principes décrits dans le livre blanc original de TON.

L'objectif de la conception étant d'être un environnement d'exécution décentralisé pour Telegram, il est naturellement confronté à deux problèmes : des requêtes simultanées élevées et des données massives. Comme nous le savons, avec le développement de la technologie, Solana, qui prétend avoir le TPS le plus élevé, a un TPS maximum mesuré de seulement 65 000, ce qui n'est évidemment pas suffisant pour prendre en charge l'écosystème Telegram qui nécessite des millions de TPS. Dans le même temps, avec l'application à grande échelle de Telegram, la quantité de données qu'il génère a déjà explosé, et en tant que système distribué extrêmement redondant, la blockchain exige que chaque nœud du réseau enregistre une copie complète des données, ce qui est également irréaliste.

Par conséquent, afin de résoudre les deux problèmes ci-dessus, TON a apporté deux optimisations au protocole blockchain principal :

• En adoptant le paradigme du sharding infini pour concevoir le système, le problème de redondance des données est résolu, de sorte qu'il peut transporter de grandes quantités de données tout en atténuant les goulots d'étranglement des performances ;

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

Devenez une chaîne de blockchain – grâce à des capacités de fragmentation illimitées, chaque compte dispose d'une chaîne de compte dédiée

Nous savons que le sharding est devenu la solution courante pour la plupart des protocoles de blockchain pour améliorer les performances et réduire les coûts, et TON a poussé cela à l'extrême et a proposé un paradigme de sharding infini, ce qui signifie que la blockchain est autorisée à augmenter ou diminuer dynamiquement le nombre de shards 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 peut établir une chaîne de comptes exclusive pour chaque compte et assurer la cohérence entre ces chaînes grâce à certaines règles.

Pour le dire de manière abstraite, il existe quatre niveaux de structure de chaîne dans TON :

• Chaîne de comptes : cette couche de chaîne représente une chaîne de transactions liées à un certain compte. La raison pour laquelle les transactions peuvent former une structure de chaîne est que pour une machine à états, tant que les règles d'exécution sont cohérentes, la machine à états obtiendra le même résultat après avoir reçu le même ordre d'instructions. Par conséquent, tous les systèmes distribués de blockchain doivent trier les transactions dans une chaîne, et TON ne fait pas exception. La chaîne de comptes est l'unité de composant la plus basique du réseau TON. Habituellement, la chaîne de comptes est un concept virtuel, et il est peu probable qu'une chaîne de comptes indépendante existe réellement.

• Chaîne de fragments : dans la plupart des contextes, la chaîne de fragments est l'unité composant réellement le TON. La chaîne de fragments est un ensemble de chaînes de comptes.

• WorkChain : On peut également l'appeler un ensemble de chaînes de fragments avec des règles personnalisées, comme la création d'une chaîne de travail basée sur EVM et l'exécution de contrats intelligents Solidity dessus. En théorie, tout le monde dans la communauté peut créer sa propre chaîne de travail. En réalité, sa construction est une tâche assez complexe, et avant cela, vous devez payer les frais (coûteux) de sa création et obtenir 2/3 des votes des validateurs pour approuver la création de votre chaîne de travail.

• MasterChain : Enfin, il existe une chaîne spéciale dans TON appelée la chaîne principale, qui est responsable de la finalisation de toutes les chaînes de fragments. Une fois que la valeur de hachage d'un bloc de chaînes de fragments est fusionnée dans le bloc de chaînes principales, le bloc de chaîne de fragments et tous ses blocs parents sont considérés comme définitifs, ce qui signifie qu'ils peuvent être considérés comme un contenu fixe et immuable et référencés par les blocs suivants de toutes les chaînes de fragments.

En adoptant ce paradigme, le réseau TON présente les trois caractéristiques suivantes :

• Sharding dynamique : TON peut automatiquement diviser et fusionner les chaînes de shards pour s'adapter aux changements de charge. Cela signifie que les nouveaux blocs sont toujours générés rapidement et que les transactions n'entraînent pas de longs délais d'attente.

• Hautement évolutif : grâce au paradigme de partitionnement infini, TON est capable de prendre en charge un nombre presque illimité de fragments, théoriquement jusqu'à 2 à la puissance de 60 chaînes de travail.

• Adaptabilité : lorsque la charge sur une partie du réseau augmente, cette partie peut être subdivisée en plusieurs fragments pour gérer le volume accru de transactions. À l'inverse, lorsque la charge diminue, les fragments peuvent être fusionnés pour améliorer l'efficacité.

Un tel système multi-chaînes doit d'abord faire face au problème de la communication entre les chaînes, notamment en raison de la capacité de fragmentation illimitée. Lorsque le nombre de fragments dans le réseau atteint un certain niveau, le routage des informations entre les chaînes devient une tâche difficile. Imaginez qu'il y ait 4 nœuds dans le réseau, chaque nœud étant responsable du maintien d'une chaîne de travail indépendante, où la relation de liaison signifie qu'en plus d'être responsable du travail de tri des transactions dans sa propre chaîne de travail, le nœud doit également surveiller et traiter les changements d'état dans la chaîne cible. Dans TON, cela est réalisé en surveillant les messages dans la file d'attente de sortie.

Supposons que le compte A de la chaîne de travail 1 souhaite envoyer un message au compte C de la chaîne de travail 3. Le problème de routage des messages doit alors être conçu. Dans cet exemple, il existe deux chemins de routage, chaîne de travail 1 -> chaîne de travail 2 -> chaîne de travail 3 et chaîne de travail 1 -> chaîne de travail 4 -> chaîne de travail 3.

Face à des situations plus complexes, un algorithme de routage efficace et peu coûteux est nécessaire pour achever rapidement la communication des messages. TON a choisi l'algorithme de routage dit hypercube pour réaliser la découverte du routage de la communication des messages entre chaînes. La structure dite hypercube fait référence à une topologie de réseau spéciale. Un hypercube n-dimensionnel est composé de 2^n sommets, chacun pouvant être identifié de manière unique par un nombre binaire à n bits. Dans cette structure, deux sommets quelconques sont adjacents s'ils ne diffèrent que d'un bit dans la représentation binaire. Par exemple, dans un hypercube tridimensionnel, 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 bidimensionnel.

Dans le protocole de routage hypercube, le processus de routage des messages de la chaîne source vers la chaîne cible est effectué en comparant la représentation binaire des adresses des chaînes source et cible. L'algorithme de routage trouve la distance minimale entre les deux adresses (c'est-à-dire le nombre de bits différents dans la représentation binaire) et transmet les informations étape par étape à travers les chaînes adjacentes jusqu'à ce qu'elles atteignent la chaîne cible. Cette méthode garantit que les paquets de données sont transmis par le chemin le plus court, améliorant ainsi l'efficacité de la communication du réseau.

Bien entendu, afin de simplifier ce processus, TON a également proposé une solution technique optimiste. Lorsqu'un utilisateur peut fournir une preuve valide d'un chemin de routage, qui est généralement une racine Merkle Trie, le nœud peut directement reconnaître la crédibilité du message soumis par l'utilisateur. C'est ce qu'on appelle également le routage hypercube instantané.

Par conséquent, nous pouvons voir que les adresses dans TON sont considérablement différentes de celles des autres protocoles de blockchain. La plupart des autres protocoles de blockchain courants utilisent le hachage correspondant à la clé publique dans la clé publique-privée générée par l'algorithme de chiffrement elliptique comme adresse, car l'adresse n'est utilisée que pour l'unicité et n'a pas besoin de porter la fonction d'adressage de routage. L'adresse dans TON se compose de deux parties (workchain_id, account_id), où workchain_id est codé selon l'adresse de l'algorithme de routage hypercube, qui ne sera pas élaborée ici.

Il y a un autre point sur lequel il est facile de douter. Vous avez peut-être remarqué que la chaîne principale et chaque chaîne de travail sont liées. Ensuite, toutes les informations inter-chaînes peuvent être relayées via la chaîne principale, tout comme Cosmos. Dans le concept de conception de TON, la chaîne principale n'est utilisée que pour gérer les tâches les plus critiques, c'est-à-dire pour maintenir la finalité de nombreuses chaînes de travail. Il n'est pas impossible d'acheminer les messages via la chaîne principale, mais les frais de traitement qui en résultent seront très élevés.

Enfin, permettez-moi de mentionner brièvement son algorithme de consensus. TON utilise la méthode BFT+PoS, c'est-à-dire que tout staker a la possibilité de participer au packaging des blocs. Le contrat de gouvernance électorale de TON sélectionnera au hasard un groupe de validateurs de packaging parmi tous les stakers à intervalles réguliers. Les nœuds sélectionnés, appelés validateurs, emballeront les blocs via l'algorithme BFT. S'ils emballent des informations erronées ou font le mal, leurs jetons mis en jeu seront confisqués, sinon ils recevront des récompenses de bloc. Il s'agit essentiellement d'un choix courant, je ne le présenterai donc pas ici.

Contrats intelligents basés sur les acteurs et environnement d'exécution entièrement parallèle

Une autre différence entre TON et les protocoles blockchain traditionnels est son environnement d'exécution de contrats intelligents. Afin de dépasser les limitations TPS des protocoles blockchain traditionnels, TON a adopté une approche de conception ascendante et a reconstruit les contrats intelligents et leurs méthodes d'exécution à l'aide du modèle Actor, leur permettant d'avoir des capacités d'exécution parallèle complètes.

Nous savons que la plupart des protocoles blockchain traditionnels utilisent un environnement d'exécution en série à thread unique. Prenons l'exemple d'Ethereum, son environnement d'exécution EVM est une machine à états qui prend les transactions en entrée. Lorsque le nœud producteur de blocs termine le tri des transactions en empaquetant les blocs, il exécute les transactions via EVM dans cet ordre. L'ensemble du processus est entièrement en série et à thread unique, c'est-à-dire qu'une seule transaction peut être exécutée à la fois. L'avantage de cela est que tant que l'ordre de transaction est confirmé, le résultat de l'exécution est cohérent dans un large cluster distribué. Dans le même temps, comme une seule transaction est exécutée en série en même temps, cela signifie que pendant le processus d'exécution, il est impossible pour d'autres transactions de modifier une donnée d'état à laquelle il faut accéder, ce qui permet d'obtenir l'interopérabilité entre les contrats intelligents. Par exemple, nous utilisons USDT pour acheter de l'ETH via Uniswap. Lorsque la transaction est exécutée, la distribution des LP dans la paire de transactions est une certaine valeur, de sorte que les résultats correspondants peuvent être obtenus via certains modèles mathématiques. Cependant, si ce n’est pas le cas, lors de l’exécution d’un calcul de courbe de liaison, d’autres LP ajoutent de nouvelles liquidités, alors le résultat du calcul sera un résultat obsolète, ce qui est évidemment inacceptable.

Cependant, cette architecture présente également des limites évidentes, à savoir le goulot d'étranglement TPS, et ce goulot d'étranglement semble très obsolète sous les processeurs multicœurs actuels. C'est comme utiliser le dernier PC pour jouer à de vieux jeux informatiques, comme Red Alert. Lorsque le nombre d'unités de combat atteint un certain niveau, vous constaterez toujours qu'il est bloqué. Il s'agit d'un problème d'architecture logicielle.

Vous avez peut-être entendu dire que certains protocoles ont déjà prêté attention à ce problème et ont proposé leurs propres solutions parallèles. Par exemple, Solana, qui est actuellement connu pour avoir le TPS le plus élevé, a également la capacité de s'exécuter en parallèle. Cependant, son concept de conception est différent de TON. Dans Solana, l'idée principale est de diviser toutes les transactions en plusieurs groupes en fonction des dépendances d'exécution, et aucune donnée d'état n'est partagée entre les différents groupes. C'est-à-dire qu'il n'y a pas de dépendance identique, de sorte que les transactions dans différents groupes peuvent être exécutées en parallèle sans se soucier des conflits. Pour les transactions dans le même groupe, la méthode série traditionnelle est toujours utilisée pour l'exécution.

Dans TON, cependant, l'architecture d'exécution en série est complètement abandonnée et un paradigme de développement conçu pour le parallélisme, le modèle Actor, est adopté pour reconstruire l'environnement d'exécution. Le modèle Actor a été proposé pour la première fois par Carl Hewitt en 1973, dans le but de résoudre la complexité de l'état partagé dans les programmes concurrents traditionnels grâce au passage de messages. Chaque acteur a son propre état et son propre comportement privés, et ne partage aucune information d'état avec les autres acteurs. Le modèle Actor est un modèle de calcul pour le calcul concurrent qui implémente le calcul parallèle via le passage de messages. Dans ce modèle, Actor est l'unité de travail de base, qui peut traiter les messages reçus, créer de nouveaux acteurs, envoyer plus de messages et décider comment répondre au message suivant. Le modèle Actor doit avoir les caractéristiques suivantes :

• Encapsulation et indépendance : chaque acteur est totalement indépendant dans le traitement des messages et peut traiter les messages en parallèle sans interférer les uns avec les autres.

• Transmission de messages : les acteurs interagissent uniquement en envoyant et en recevant des messages, et la transmission de messages est asynchrone.

• Structure dynamique : les acteurs peuvent créer d'autres acteurs lors de l'exécution. Ce dynamisme permet au modèle d'acteur d'étendre le système selon les besoins.

TON utilise cette architecture pour concevoir le modèle de contrat intelligent, ce qui signifie que dans TON, chaque contrat intelligent est un modèle d'acteur avec un espace de stockage complètement indépendant. Car il ne s'appuie sur aucune donnée externe. De plus, les appels au même contrat intelligent sont toujours exécutés selon l'ordre des messages dans la file d'attente de réception, de sorte que les transactions dans TON peuvent être exécutées efficacement en parallèle sans se soucier des conflits.

Cependant, cette conception entraîne également de nouveaux impacts. Pour les développeurs de DApp, leur paradigme de développement habituel sera rompu, comme suit :

1. Appels asynchrones entre contrats intelligents : Il est impossible d'appeler des contrats externes ou d'accéder aux données de contrats externes de manière atomique dans les contrats intelligents de TON. Nous savons que dans Solidity, l'appel de la fonction 2 du contrat B à partir de la fonction 1 du contrat A, ou l'accès à certaines données d'état via la fonction 3 en lecture seule du contrat C, l'ensemble du processus est atomique et exécuté en une seule transaction, ce qui est une chose très simple. Cependant, dans TON, cela ne sera pas possible. Toute interaction avec des contrats intelligents externes sera exécutée de manière asynchrone en empaquetant de nouvelles transactions. De telles transactions initiées par des contrats intelligents sont également appelées messages internes. Et le processus d'exécution ne peut pas être bloqué pour obtenir le résultat de l'exécution.

Par exemple, si nous développons un DEX et adoptons le paradigme commun dans EVM, il y aura généralement un contrat de routeur unifié pour gérer le routage des transactions, et chaque pool gérera séparément les données LP liées à une certaine paire de trading. Supposons qu'il existe actuellement deux pools, USDT-DAI et DAI-ETH. Lorsqu'un utilisateur souhaite acheter de l'ETH directement via USDT, il peut demander à ces deux pools séquentiellement dans une transaction via le contrat de routeur pour terminer la transaction atomique. Cependant, ce n'est pas si facile à réaliser dans TON, et nous devons réfléchir à un nouveau paradigme de développement. Si nous réutilisons toujours ce paradigme, le flux d'informations pourrait être le suivant : cette demande sera accompagnée d'un message externe initié par l'utilisateur et de trois messages internes (notez que cela est utilisé pour illustrer la différence. Dans le développement réel, même le paradigme ERC 20 doit être repensé).

2. Il est nécessaire d'examiner attentivement le flux de traitement des erreurs d'exécution lors des appels entre contrats et de concevoir des fonctions de rebond correspondantes pour chaque appel inter-contrat. Nous savons que dans l'EVM classique, lorsqu'un problème survient lors de l'exécution d'une transaction, l'ensemble de la transaction est annulé, c'est-à-dire réinitialisé à l'état au début de l'exécution. Cela est facile à comprendre dans le modèle série à thread unique. Cependant, dans TON, comme les appels inter-contrats sont exécutés de manière asynchrone, même si une erreur se produit dans un lien ultérieur, puisque les transactions précédemment exécutées avec succès ont été exécutées et confirmées, cela peut poser des problèmes. Par conséquent, un type de message spécial est défini dans TON, appelé message de rebond, c'est-à-dire que lorsqu'une erreur se produit dans le processus d'exécution ultérieur déclenché par un message interne, le contrat déclenché peut déclencher une réinitialisation de certains états du contrat en déclenchant la fonction de rebond réservée par le contrat.

3. Dans certains cas complexes, la transaction reçue en premier peut ne pas être exécutée en premier, de sorte que cette relation temporelle ne peut pas être prédéfinie. Dans un tel système d'appels de smart contracts asynchrones et parallèles, il peut être difficile de définir l'ordre des opérations de traitement. C'est pourquoi chaque message dans TON possède son temps logique Lamport (ci-après dénommé lt). Il permet de comprendre quel événement en a déclenché un autre et ce que le validateur doit traiter en premier. Pour un modèle simple, la transaction reçue en premier doit être exécutée en premier.

Dans ce modèle, A et B représentent respectivement deux contrats intelligents, et il existe une relation temporelle telle que si msg 1 _lt

Cependant, dans des cas plus complexes, cette règle sera enfreinte. Il existe un tel exemple dans le document officiel. Supposons que nous ayons trois contrats A, B et C. Dans une transaction, A envoie deux messages internes msg 1 et msg 2 : l'un à B et l'autre à C. Bien qu'ils soient créés dans l'ordre exact (msg 1 en premier, puis msg 2), nous ne pouvons pas être sûrs que le msg 1 sera traité avant le msg 2. Cela est dû au fait que les itinéraires de A à B et de A à C peuvent différer en longueur et en ensemble de validateurs. Si ces contrats se trouvent dans des chaînes de fragments différentes, l'un des messages peut prendre plusieurs blocs pour atteindre le contrat cible. Autrement dit, nous avons deux chemins de transaction possibles, comme le montre la figure.

4. Dans TON, le stockage persistant de ses contrats intelligents utilise un graphe acyclique dirigé avec Cell comme unité comme structure de données Les données seront compressées de manière compacte dans une cellule selon les règles de codage et étendues vers le bas à la manière d'un graphe acyclique dirigé. Ceci est différent de l'organisation structurelle des données d'état basée sur le hashmap dans EVM. En raison de différents algorithmes de demande de données, TON définit différents prix du gaz pour le traitement des données à différentes profondeurs. Plus le traitement des données de la cellule est profond, plus le gaz requis est élevé. Par conséquent, il existe un paradigme d'attaque DOS dans TON, c'est-à-dire que certains utilisateurs malveillants occupent toutes les cellules peu profondes d'un contrat intelligent en envoyant un grand nombre de messages de spam, ce qui signifie que le coût de stockage des utilisateurs honnêtes deviendra de plus en plus élevé. Dans EVM, comme la complexité de la requête du hashmap est o(1), il y a le même gaz et il n'y aura pas de problème similaire. Par conséquent, les développeurs de TON Dapp doivent essayer d'éviter les types de données illimités dans les contrats intelligents. Lorsque des types de données illimités apparaissent, ils doivent être fragmentés par sharding.

5. Certaines fonctionnalités ne sont pas si spéciales, comme la nécessité pour les contrats intelligents de payer un loyer pour le stockage, le fait que les contrats intelligents sont naturellement évolutifs dans TON et la fonction de compte abstrait native, c'est-à-dire que toutes les adresses de portefeuille dans TON sont des contrats intelligents, mais ils ne sont pas initialisés, etc., qui nécessitent une attention particulière de la part des développeurs.

Ce qui précède est une partie de mes expériences dans l'apprentissage des technologies liées à TON au cours de cette période. J'aimerais les partager avec vous. S'il y a des erreurs, j'espère que vous pourrez me corriger. En même temps, je pense qu'avec les énormes ressources de trafic de Telegram, l'écosystème TON apportera certainement de nouvelles applications au Web3. Les amis intéressés par le développement de TON DApp peuvent également me contacter et discuter avec nous.

Liens X : https://x.com/web3_mario

Pseudo Telegram : @MarioChin Web3

Cet article provient d'Internet : Description détaillée des fonctionnalités techniques de TON et du paradigme de développement des contrats intelligents

En lien : Interprétation des mèmes basés et du Based Institute : où est l’avenir de l’écosystème Base ?

Français : Source originale : Jesse Pollak Compilé par : Odaily Planet Daily Wenser Note de la rédaction : En tant que l'un des écosystèmes L2 les plus en vogue en 2024, l'essor de Base peut être considéré comme le résultat du bon moment, du bon endroit et des bonnes personnes - il bénéficie non seulement de l'opportunité offerte par l'engouement pour le Memecoin, mais aussi du réseau à faible consommation de gaz L2 basé sur l'écosystème OP et soutenu par Coinbase, et du travail acharné du leader du protocole Jesse Pollak et d'un groupe de créateurs d'écosystèmes. Quant à l'écosystème Base, dont la TVL a atteint 5,5 milliards de dollars américains, Jesse a récemment donné une brève revue et un résumé au New York Meme Hackathon, et a récemment mis le contenu sur Zora sous forme de NFT, et a frappé plus de 4 000…