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 de jetons en pleine circulation, TON a attiré 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 des protocoles de chaîne publique traditionnels, j'ai donc passé du temps à faire des recherches approfondies sur des sujets connexes et partagé quelques idées avec vous. En bref, le concept de base de TON est de reconstruire le protocole blockchain traditionnel de manière « ascendante » et d'atteindre une concurrence élevée et une évolutivité élevée au détriment de l'interopérabilité.
L'idée de conception de base de TON : haute concurrence et haute évolutivité
On peut dire que le but de toutes les sélections technologiques complexes dans TON vient de la recherche d'une concurrence élevée et d'une évolutivité élevée. Bien sûr, il n'est pas difficile pour nous de comprendre cela depuis 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é initialement développé par le fondateur de Telegram Nikolai Durov et son équipe, et est désormais soutenu et maintenu par une communauté mondiale de contributeurs indépendants. Sa naissance remonte à 2017, lorsque l’équipe Telegram a commencé à explorer elle-même les solutions blockchain. Comme aucune blockchain L1 existante à l’époque ne pouvait prendre en charge 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. Afin d’obtenir les ressources nécessaires à la mise en œuvre de TON, Telegram a lancé une vente de jetons Gram (renommé 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 de développer activement la blockchain jusqu'à ce jour, en adhérant aux principes énoncés dans le livre blanc original de TON.
Ainsi, comme il est conçu comme un environnement d'exécution décentralisé pour Telegram, il doit naturellement faire face à deux problèmes, des requêtes simultanées élevées et des données massives. Nous savons qu'avec le développement de la technologie jusqu'à présent, Solana, connue comme le TPS le plus élevé, a le TPS mesuré le plus élevé, 65 000, ce qui n'est évidemment pas suffisant pour soutenir 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'elle génère a déjà dépassé le ciel. En tant que système distribué extrêmement redondant, la blockchain nécessite que chaque nœud du réseau enregistre une copie complète des données. également irréaliste.
Par conséquent, afin de résoudre les deux problèmes ci-dessus, TON a apporté deux optimisations aux protocoles blockchain traditionnels :
En utilisant le « Paradigme de partage infini » pour concevoir le système, nous résolvons le problème de redondance des données afin qu'il puisse transporter du Big Data et atténuer le problème de goulot d'étranglement des performances ;
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é ;
Créez une chaîne de blockchain : grâce à des capacités de partage illimitées, chaque compte dispose d'une chaîne de comptes exclusive.
Nous savons maintenant que le partage est devenu la solution principale pour la plupart des protocoles de 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 de partage infini, le soi-disant paradigme de partage infini fait référence à la possibilité de permettre à la blockchain de fonctionner. augmentez ou diminuez dynamiquement le nombre de fragments 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 l'interopérabilité entre ces chaînes grâce à certaines règles de cohérence.
Pour le comprendre de manière abstraite, il existe quatre niveaux de structure de chaîne dans TON :
Chaîne de comptes : cette chaîne de couches représente une chaîne composée d'une série de transactions liées à un 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 le fera. les résultats obtenus après avoir reçu des instructions dans la même séquence sont cohérents, donc l'ordre en chaîne des transactions est requis dans tous les systèmes distribués blockchain, et TON ne fait pas exception. La chaîne de comptes est l'unité la plus élémentaire 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é de composant réelle de 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 partitionnement avec des règles personnalisées, telles que 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, chacun dans la communauté peut créer sa propre chaîne de travail. En fait, sa construction est une tâche assez complexe, précédée du paiement des frais (coûteux) pour la créer et de l'obtention des 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 chaîne principale, qui est chargée d'apporter la finalité à toutes les chaînes de fragments. Une fois que le hachage d'un bloc de chaîne de fragments est fusionné dans le bloc de la chaîne principale, ce bloc de chaîne de fragments et tous ses blocs parents sont considérés comme finaux, ce qui signifie qu'ils peuvent être considérés comme fixes et incassables. Le contenu modifié est référencé par les blocs suivants de tous les fragments. Chaînes.
En adoptant un tel paradigme, le réseau TON présente les trois caractéristiques suivantes :
Partage dynamique : TON peut automatiquement diviser et fusionner des chaînes de fragments 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 peut prendre en charge un nombre presque illimité de fragments et peut théoriquement atteindre 2 à la puissance 60 des chaînes de travail.
Adaptabilité : lorsque la charge augmente sur une partie du réseau, cette partie peut être subdivisée en plusieurs fragments pour gérer l'augmentation du volume de transactions. À l’inverse, lorsque la charge diminue, les fragments peuvent être fusionnés pour accroître l’efficacité.
Ensuite, la première chose à laquelle un tel système multi-chaînes doit faire face est le problème de la communication entre les chaînes, notamment en raison de la capacité de partitionnement illimité. Lorsque le nombre de fragments du réseau atteint un certain niveau, le routage des informations entre les chaînes. deviendra une chose difficile à faire. Imaginez qu'il y ait 4 nœuds dans le réseau et que chaque nœud est responsable du maintien d'une chaîne de travail indépendante. La relation de lien indique qu'en plus d'être responsable du tri des transactions dans sa propre chaîne de travail, le nœud doit également surveiller et traiter l'état. changements dans la chaîne cible, qui est spécifiquement implémenté dans TON 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. Ensuite, vous devez concevoir le problème de routage des messages. 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 terminer rapidement la communication des messages. TON a choisi ce que l'on appelle « l'algorithme de routage hypercube » pour réaliser la découverte d'itinéraires de communication de messages inter-chaînes. La structure dite hypercube fait référence à une topologie de réseau spéciale. Un hypercube à n dimensions est composé de 2 ^ n sommets, et chaque sommet peut être identifié de manière unique par un nombre binaire de 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 d'un message d'une chaîne de travail source vers une chaîne de travail cible est effectué en comparant les représentations binaires des adresses de la chaîne de travail source et de la chaîne de travail cible. L'algorithme de routage trouve la distance minimale (c'est-à-dire le nombre de bits différents dans la représentation binaire) entre ces deux adresses et transmet progressivement les informations à travers les chaînes de travail adjacentes jusqu'à ce que la chaîne de travail cible soit atteinte. 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 certain chemin de routage, qui est généralement une racine Merkle trie, le nœud peut directement reconnaître la crédibilité du chemin. message soumis par les propriétés de l'utilisateur, ceci est également connu sous le nom de routage hypercube instantané.
Par conséquent, nous pouvons voir qu'il existe des différences évidentes entre les adresses dans TON et celles des autres protocoles de blockchain. La plupart des autres protocoles de blockchain traditionnels utilisent le hachage correspondant à la clé publique dans les clés publiques et privées générées par l'algorithme de chiffrement elliptique comme adresse, car. l'adresse est uniquement utilisée comme adresse unique. Elle n'a pas besoin de porter la fonction d'adressage de routage, et 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 développé ici.
Il y a un autre point sur lequel il est facile de soulever des doutes. Vous avez peut-être remarqué que la chaîne principale a une relation de maillon avec chaque chaîne de travail, il ne suffirait donc pas que toutes les informations inter-chaînes soient relayées via la chaîne principale, simplement. 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 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ésulteront seront très élevés. .
Enfin, mentionnons brièvement son algorithme de consensus. TON adopte la méthode BFT+PoS, c'est-à-dire que tout acteur a la possibilité de participer au contrat de gouvernance électorale de TON sélectionnera au hasard un vérificateur d'emballage parmi tous les acteurs à intervalles réguliers. cluster, les nœuds sélectionnés comme validateurs conditionneront et produiront des blocs via l'algorithme BFT s'ils regroupent des informations incorrectes ou font le mal, leurs jetons de mise seront perdus, et sinon ils recevront des récompenses de bloc. Il s’agit d’un choix courant, je ne le présenterai donc pas ici.
Contrats intelligents et environnement d'exécution entièrement parallèle basé sur le modèle Actor
Une autre différence entre TON et les protocoles blockchain traditionnels réside dans son environnement d’exécution de contrats intelligents. Afin de dépasser les limites du TPS des protocoles blockchain traditionnels, TON adopte une idée de conception ascendante et utilise le modèle Actor pour reconstruire les contrats intelligents et leurs méthodes d'exécution, afin qu'ils puissent être entièrement parallélisés.
Nous savons que la plupart des protocoles blockchain traditionnels utilisent un environnement d'exécution série à thread unique. En prenant Ethereum comme exemple, son environnement d'exécution EVM est une machine à états avec des transactions en entrée lorsque le nœud producteur de blocs termine la transaction en empaquetant le bloc après le tri. , les transactions seront exécutées via l'EVM dans cet ordre. L'ensemble du processus est entièrement en série et monothread, c'est-à-dire qu'une seule transaction peut être exécutée à un certain moment. L'avantage est que tant que la séquence de transactions est longue. confirmé, le résultat de l'exécution sera cohérent dans un large éventail de clusters distribués. En même temps, puisqu'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 le faire. modifier certaines données d'état auxquelles accéder, afin que l'interopérabilité entre les contrats intelligents soit atteinte. Par exemple, nous utilisons l'USDT pour acheter des ETH via Uniswap. Lorsque la transaction est exécutée, la distribution du LP dans la paire de négociation est d'une certaine valeur. De cette manière, le résultat correspondant peut être obtenu grâce à certains modèles mathématiques, mais en supposant que cela soit le cas. Ce n'est pas le cas. Lors du calcul d'une certaine courbe de liaison, si d'autres LP ajoutent de nouvelles liquidités, le résultat du calcul sera un résultat obsolète, ce qui est évidemment inacceptable.
Mais cette architecture a aussi des limites évidentes, qui sont le goulot d'étranglement du TPS, et ce goulot d'étranglement semble très ancien sous les processeurs multicœurs actuels, tout comme si vous utilisez le dernier PC pour jouer à certains anciens jeux informatiques, comme Red Alert, When the. Si 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 avec l'architecture logicielle.
Vous entendrez peut-être que certains protocoles prêtent déjà attention à ce problème et ont proposé leurs propres solutions parallèles. En prenant comme exemple Solana, qui prétend actuellement avoir le TPS le plus élevé, il a également la capacité de s'exécuter en parallèle. Cependant, son idée de conception est différente de TON Dans Solana, son 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 différents groupes. Autrement dit, il n'y a pas de dépendances identiques, de sorte que les transactions dans différents groupes peuvent être exécutées en parallèle sans se soucier des conflits, tandis que les transactions au sein d'un même groupe sont toujours exécutées de manière sérielle traditionnelle.
Dans TON, il abandonne complètement l'architecture d'exécution en série et adopte à la place un paradigme de développement spécifiquement conçu pour le parallélisme, le modèle Actor, pour reconstruire l'environnement d'exécution. Le modèle dit de l'acteur a été proposé pour la première fois par Carl Hewitt en 1973 pour résoudre la complexité de l'état partagé dans les programmes concurrents traditionnels grâce à la transmission de messages. Chaque acteur a son propre état et son propre comportement, et aucune information d'état n'est partagée avec d'autres acteurs. Le modèle Actor est un modèle informatique concurrent qui implémente le calcul parallèle via la transmission de messages. Dans ce modèle, un « acteur » est l'unité de travail de base, capable de traiter les messages reçus, de créer de nouveaux acteurs, d'envoyer davantage de messages et de décider comment répondre aux messages suivants. Le modèle Actor doit avoir les caractéristiques suivantes :
Encapsulation et indépendance : Chaque acteur est totalement indépendant lors du traitement des messages et peut traiter les messages en parallèle sans interférer les uns avec les autres.
Passage de messages : les acteurs interagissent les uns avec les autres uniquement en envoyant et en recevant des messages, et le passage des messages est asynchrone.
Structure dynamique : les acteurs peuvent créer davantage d'acteurs au moment de l'exécution. Cette nature dynamique permet au modèle d'acteur de faire évoluer le système selon les besoins.
TON adopte cette architecture pour concevoir des modèles de contrats intelligents, ce qui signifie que dans TON, chaque contrat intelligent est un modèle Actor avec un espace de stockage totalement indépendant. Parce qu'il ne s'appuie sur aucune donnée externe. De plus, les appels vers le 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, un tel schéma de conception apporte également de nouveaux impacts pour les développeurs DApp, leur paradigme de développement habituel sera brisé, comme suit :
1. Appels asynchrones entre contrats intelligents : Il n'est pas possible d'appeler atomiquement des contrats externes ou d'accéder aux données de contrats externes au sein des contrats intelligents de TON. Nous savons que dans Solidity, la fonction 1 du contrat A appelle la fonction 2 du contrat B. Ou accéder à certaines données d'état. via la fonction de lecture seule n3 du contrat C. L'ensemble du processus est atomique et exécuté dans une transaction. Cependant, dans TON, cela ne sera pas possible. Toutes les interactions avec des contrats intelligents externes seront exécutées. de manière asynchrone en empaquetant de nouvelles transactions. Ces transactions initiées par des contrats intelligents sont également appelées messages internes. Et il ne peut pas être bloqué pendant l'exécution pour obtenir les résultats de l'exécution.
Par exemple, si nous développons un DEX, si nous adoptons le paradigme commun dans EVM, il y aura généralement un contrat de routeur unifié utilisé pour gérer le routage des transactions, et chaque pool gère indépendamment les données LP liées à une certaine paire de négociation. il existe actuellement deux pools USDT-DAI et DAI-ETH. Lorsqu'un utilisateur souhaite acheter de l'ETH directement via l'USDT, il peut demander séquentiellement ces deux pools en une seule transaction via le contrat du routeur pour terminer une transaction atomique. Cependant, ce n'est pas si simple à mettre en œuvre dans TON. Il faut réfléchir à un nouveau paradigme de développement. Si ce paradigme est encore réutilisé, le flux d'informations peut être ainsi. Cette demande sera accompagnée d'un message externe initié par le. utilisateur et trois messages internes sont complétés (notez que ceci est utilisé pour illustrer la différence. Dans le développement réel, même le paradigme d'ERC 20 devra être repensé).
2. Il est nécessaire d'examiner attentivement le processus de traitement des erreurs d'exécution lors des appels inter-contrats et de concevoir des fonctions de rebond correspondantes pour chaque appel inter-contrat. Nous savons que dans l'EVM traditionnel, lorsqu'un problème survient lors de l'exécution d'une transaction, l'intégralité de la transaction sera annulée, c'est-à-dire réinitialisée à l'état dans lequel elle avait été initialement exécutée. Ceci est facile à comprendre dans le modèle série à thread unique. Cependant, dans TON, étant donné que les appels entre contrats sont exécutés de manière asynchrone, même si une erreur se produit dans un lien ultérieur, puisque la transaction précédemment exécutée avec succès a déjà été exécutée et confirmée, cela peut poser des problèmes. Par conséquent, un type de message spécial est configuré dans TON, appelé message de rebond. Autrement dit, lorsqu'une erreur se produit dans le processus d'exécution ultérieur déclenchée par un message interne, le contrat déclenché peut déclencher un certain événement dans le contrat en déclenchant le rebond. fonction réservée par le contrat. Certaines réinitialisations de statut.
3. Dans certaines situations complexes, la transaction reçue en premier peut ne pas être exécutée en premier, cette relation temporelle ne peut donc pas être prédéfinie. Dans un tel système d’appels de contrats intelligents asynchrones et parallèles, définir l’ordre dans lequel les opérations sont traitées peut s’avérer difficile. C'est pourquoi chaque message dans TON a son heure logique Lamport (ci-après dénommée lt). Il est utilisé pour comprendre quel événement en a déclenché un autre et ce que le validateur doit gérer 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 de si msg 1 _lt < msg 2 _lt, alors tx 1 _lt < tx 2 _lt.
Cependant, dans des situations plus complexes, cette règle n’est pas respectée. Il y a un exemple de cela dans la documentation officielle, en supposant que nous ayons trois contrats A, B et C. Dans une transaction, A envoie deux messages internes msg 1 et msg 2 : un à B et l'autre à C. Bien qu'ils soient créés dans l'ordre exact (d'abord msg 1 , puis msg 2 ), nous ne pouvons pas être sûrs que msg 1 sera traité avant msg 2 . En effet, 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 sur 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 voies commerciales 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 Cell selon les règles d'encodage, et en même temps selon les. graphique acyclique dirigé.La voie s'étend vers le bas, ce qui est différent de l'organisation structurelle des données d'état basée sur un hashmap dans EVM. En raison de différents algorithmes de demande de données, TON définit différents prix du gaz pour différentes profondeurs de traitement des données. , plus il nécessite de Gas. Plus il est élevé, il existe donc un paradigme d'attaque DOS dans TON, c'est-à-dire que certains utilisateurs malveillants occupent toutes les cellules superficielles d'un certain contrat intelligent en envoyant un grand nombre de messages de spam, ce qui signifie que le le coût de stockage des utilisateurs honnêtes deviendra de plus en plus élevé. Dans EVM, puisque la complexité de la requête de hashmap est o(1), elle a le même Gas et il n'y aura pas de problèmes similaires. Par conséquent, les développeurs de TON Dapp devraient 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 divisés via le partitionnement.
5. Il existe également certaines fonctionnalités moins spéciales, telles que les contrats intelligents qui nécessitent de payer un loyer pour le stockage, les contrats intelligents dans TON sont naturellement évolutifs et les fonctions de compte abstraites natives, c'est-à-dire que toutes les adresses de portefeuille dans TON sont des contrats intelligents. tout simplement pas initialisé, etc. Ceux-ci nécessitent que les développeurs y prêtent une attention particulière.
Voici quelques-unes de mes expériences d'apprentissage des technologies liées à TON au cours de cette période. J'aimerais les partager avec vous. J'espère que vous pourrez me corriger si je fais des erreurs. En même temps, je pense qu'avec les énormes ressources de trafic de Telegram. , l'écosystème TON servira certainement de plate-forme pour Web3. En apportant de toutes nouvelles applications, 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
Identifiant du télégramme : @MarioChin Web3