Rédigé par :@Web3Mario
Introduction : Avec le lancement de Notcoin, le plus grand jeu dans l'écosystème TON, sur Binance et l'effet massif de création de richesse généré par son modèle économique entièrement en circulation, TON a rapidement attiré une grande attention. Après avoir discuté avec des amis, j'ai appris que les barrières techniques de TON sont élevées, et que ses paradigmes de développement DApp diffèrent considérablement des protocoles blockchain dominants. J'ai donc consacré un certain temps à étudier en profondeur ces sujets, et je souhaite partager ici mes réflexions. En résumé, la philosophie centrale de conception de TON consiste à reconstruire les protocoles blockchain traditionnels selon une approche « ascendante », sacrifiant délibérément l'interopérabilité afin de poursuivre de manière extrême la haute concurrence et la haute évolutivité.
La philosophie fondamentale de TON — Haute concurrence et haute évolutivité
On peut dire que tous les choix techniques complexes de TON visent exclusivement la haute concurrence et l’évolutivité. Ce point devient compréhensible dès lors qu’on examine son origine. TON, ou The Open Network, est un réseau informatique décentralisé comprenant une blockchain de niveau 1 (L1) et plusieurs composants. Initialement développé conjointement par Nikolai Durov, fondateur de Telegram, et son équipe, le projet est aujourd’hui soutenu et maintenu par une communauté mondiale de contributeurs indépendants. Son histoire remonte à 2017, lorsque l’équipe Telegram a commencé à explorer des solutions blockchain pour elle-même. Comme aucune blockchain L1 existante à l’époque ne pouvait supporter la base d’utilisateurs à neuf chiffres de Telegram, ils ont décidé de concevoir leur propre blockchain, alors appelée Telegram Open Network. En 2018, afin de collecter les ressources nécessaires au développement de TON, Telegram a lancé la vente du jeton Gram (plus tard renommé Toncoin) au premier trimestre. 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 de concours Telegram a repris le dépôt de code de TON, rebaptisant le projet The Open Network, et continue activement à développer la blockchain tout en respectant les principes énoncés dans le livre blanc initial de TON.
Étant donné que l’objectif initial était de servir d’environnement d’exécution décentralisé pour Telegram, deux défis majeurs se posent naturellement : la gestion de requêtes hautement concurrentes et celle de volumes massifs de données. Nous savons qu’à ce jour, même Solana, revendiquant le TPS le plus élevé, atteint au maximum environ 65 000 TPS en pratique — ce qui reste insuffisant pour répondre aux exigences de centaines de milliers, voire de millions, de TPS attendus par l’écosystème Telegram. Par ailleurs, avec l’utilisation massive de Telegram, la quantité de données générée est déjà colossale. Or, une blockchain étant un système distribué extrêmement redondant, exiger que chaque nœud conserve une copie complète des données devient irréaliste.
Pour résoudre ces deux problèmes, TON a apporté deux types d’optimisations aux protocoles blockchain dominants :
-
Adoption du paradigme du « sharding infini » (Infinite Sharding Paradigm), permettant de résoudre le problème de redondance des données, de supporter de grandes quantités de données, et d’atténuer les goulets d’étranglement de performance ;
-
Mise en œuvre d’un environnement d’exécution complètement parallèle basé sur le modèle Actor, augmentant considérablement le TPS du réseau ;
Construire des chaînes dans la blockchain — Une chaîne dédiée par compte grâce au sharding infini
Actuellement, le sharding est devenu une solution standard adoptée par la plupart des protocoles blockchain pour améliorer les performances et réduire les coûts. TON pousse ce concept à son extrême en introduisant le « paradigme du sharding infini », qui permet à la blockchain d’ajuster dynamiquement le nombre de shards en fonction de la charge du réseau. Ce paradigme permet à TON de traiter efficacement des volumes massifs de transactions et d’opérations intelligentes tout en maintenant de hautes performances. Théoriquement, TON peut créer une chaîne dédiée pour chaque compte, tout en garantissant la cohérence entre ces chaînes via certaines règles.
De façon abstraite, on distingue quatre niveaux structurels dans TON :
-
Chaîne de compte (AccountChain) : ce niveau représente une chaîne constituée d’une série de transactions liées à un compte spécifique. La raison pour laquelle les transactions forment une structure en chaîne tient au fait que, pour une machine à états donnée, tant que les règles d’exécution sont identiques, recevoir des instructions dans le même ordre produit toujours le même résultat. C’est pourquoi tous les systèmes blockchain distribués doivent ordonner les transactions séquentiellement — TON ne fait pas exception. La AccountChain est l’unité de base du réseau TON, bien qu’elle soit généralement un concept virtuel et qu’il soit peu probable qu’une chaîne indépendante existe physiquement.
-
ShardChain (chaîne de shard) : dans la plupart des cas, c’est cette couche qui constitue réellement l’unité opérationnelle de TON. Une ShardChain correspond à un ensemble de AccountChains.
-
WorkChain (chaîne de travail) : aussi appelée un groupe de ShardChains doté de règles personnalisées. Par exemple, il est possible de créer une WorkChain compatible EVM pour y exécuter des contrats intelligents en Solidity. En théorie, chaque membre de la communauté peut créer sa propre WorkChain. En pratique, cela représente une tâche assez complexe, nécessitant non seulement de payer des frais élevés pour la création, mais aussi d’obtenir l’approbation de 2/3 des validateurs.
-
MasterChain (chaîne principale) : enfin, TON dispose d’une chaîne spéciale appelée MasterChain. Elle assure la finalité de toutes les ShardChains. Une fois que le hachage d’un bloc ShardChain est intégré dans un bloc de la MasterChain, ce bloc ShardChain ainsi que tous ses blocs parents sont considérés comme définitifs — c’est-à-dire fixes et immuables — et peuvent être référencés par les blocs suivants de toutes les ShardChains.
Ce paradigme confère au réseau TON trois caractéristiques principales :
-
Sharding dynamique : TON peut automatiquement diviser ou fusionner les ShardChains en fonction des variations de charge. Cela signifie que de nouveaux blocs sont toujours générés rapidement, sans entraîner de longs délais d’attente pour les transactions.
-
Évolutivité élevée : grâce au paradigme du sharding infini, TON peut supporter un nombre quasi illimité de shards, théoriquement jusqu’à 2^60 WorkChains.
-
Adaptabilité : lorsque la charge augmente localement, cette partie du réseau peut être divisée en davantage de shards pour absorber le volume accru de transactions. Inversement, lorsque la charge diminue, les shards peuvent être fusionnés pour améliorer l’efficacité.
Cependant, un tel système multi-chaînes doit d’abord faire face au problème de communication inter-chaînes, notamment en raison de sa capacité de sharding infini. Lorsque le nombre de shards atteint un certain seuil, le routage des informations entre chaînes devient difficile. Imaginons un réseau composé de 4 nœuds, chacun gérant une WorkChain indépendante. Les liens représentent le fait qu’un nœud, outre le tri des transactions dans sa propre WorkChain, doit également surveiller et traiter les changements d’état de la chaîne cible, concrètement via l’écoute des messages dans une file de sortie.
Supposons que le compte A sur la WorkChain 1 souhaite envoyer un message au compte C sur la WorkChain 3. Un problème de routage de message se pose alors. Dans cet exemple, deux chemins sont possibles : WorkChain 1 → WorkChain 2 → WorkChain 3, ou WorkChain 1 → WorkChain 4 → WorkChain 3.
Dans des situations plus complexes, un algorithme de routage efficace et peu coûteux est nécessaire pour assurer rapidement la communication. TON choisit l’algorithme de routage dit « hypercube » pour découvrir les routes inter-chaînes. Une structure hypercube désigne une topologie réseau particulière : un hypercube à n dimensions comporte 2^n sommets, chaque sommet étant identifié de façon unique par un nombre binaire à n bits. Deux sommets sont adjacents si leurs représentations binaires ne différent que par un seul bit. Par exemple, dans un hypercube à 3 dimensions, les sommets 000 et 001 sont adjacents car ils ne diffèrent que par le dernier bit. L’exemple ci-dessus illustre un hypercube à 2 dimensions.
Dans le protocole de routage hypercube, le trajet d’un message de la WorkChain source à la WorkChain cible est déterminé en comparant les représentations binaires des adresses des deux chaînes. L’algorithme calcule la distance minimale entre ces deux adresses (c’est-à-dire le nombre de bits différents), puis transfère progressivement le message via des WorkChains adjacentes jusqu’à atteindre la destination. Cette méthode garantit que les paquets suivent le chemin le plus court, améliorant ainsi l’efficacité de la communication.
Bien entendu, pour simplifier ce processus, TON propose également une solution optimiste : si un utilisateur fournit une preuve valide d’un chemin de routage — généralement une racine de Merkle trie — les nœuds peuvent directement accepter la crédibilité du message envoyé. On parle alors de routage hypercube instantané.
Ainsi, on observe que les adresses dans TON diffèrent nettement de celles des autres protocoles blockchain. Ces derniers utilisent majoritairement le hachage de la clé publique issue d’un algorithme de cryptographie elliptique comme adresse, car celle-ci sert uniquement à l’identification unique, sans besoin de fonctionnalité de routage. En revanche, une adresse TON se compose de deux parties : (workchain_id, account_id), où workchain_id est encodé selon l’algorithme de routage hypercube — détail que nous n’approfondirons pas ici.
Un autre point pouvant prêter à confusion : vous avez peut-être remarqué que la MasterChain est reliée à chaque WorkChain. Ne pourrait-on pas simplement utiliser la MasterChain comme relais pour toutes les communications inter-chaînes, comme dans Cosmos ? Selon la philosophie de conception de TON, la MasterChain est réservée aux tâches les plus critiques, notamment la finalité des nombreuses WorkChains. Utiliser la MasterChain pour router des messages est techniquement possible, mais entraînerait des frais prohibitifs.
Enfin, mentionnons brièvement l’algorithme de consensus. TON adopte une combinaison BFT+PoS : tout staker peut potentiellement participer à la création de blocs. Un contrat de gouvernance électorale sélectionne périodiquement, de façon aléatoire parmi tous les Stakers, un groupe de validateurs chargé de produire les blocs. Les nœuds ainsi élus utilisent l’algorithme BFT pour valider les blocs. En cas d’erreur ou de comportement malveillant, leurs jetons misés sont confisqués ; sinon, ils reçoivent une récompense. Ce schéma étant désormais courant, nous n’y reviendrons pas davantage.
Contrats intelligents basés sur le modèle Actor et environnement d'exécution totalement parallèle
Un autre aspect distinctif de TON par rapport aux protocoles blockchain dominants réside dans son environnement d’exécution des contrats intelligents. Pour dépasser la limite de TPS imposée par les architectures conventionnelles, TON adopte une approche radicale « ascendante », reconcevant les contrats intelligents et leur mode d’exécution selon le modèle Actor, permettant ainsi une exécution pleinement parallèle.
Nous savons que la plupart des blockchains dominantes utilisent un environnement d’exécution monofil séquentiel. Prenons Ethereum comme exemple : son environnement EVM est une machine à états dont les entrées sont des transactions. Une fois que les nœuds validateurs ont trié les transactions dans un bloc, celles-ci sont exécutées dans cet ordre précis par l’EVM. Le processus est strictement séquentiel et monofil : à un instant donné, une seule transaction est exécutée. Ce modèle garantit que, tant que l’ordre des transactions est fixé, le résultat sera cohérent à travers tout le vaste cluster distribué. De plus, comme une seule transaction est exécutée à la fois, aucun autre processus ne peut modifier un état accédé par une transaction en cours, assurant ainsi l’interopérabilité entre contrats intelligents. Par exemple, lorsqu’on achète du ETH avec du USDT via Uniswap, la distribution de liquidités dans le pool au moment de l’exécution est une valeur déterminée, permettant d’appliquer un modèle mathématique fiable. Mais imaginons que pendant le calcul d’une courbe de bonding, un nouveau fournisseur de liquidités intervienne : le résultat serait alors obsolète — ce qui est inacceptable.
Toutefois, cette architecture présente une limitation évidente : le goulet d’étranglement du TPS. Ce verrou semble particulièrement archaïque à l’ère des processeurs multicœurs — un peu comme jouer à un vieux jeu PC comme Command & Conquer sur une machine récente, et constater qu’il rame dès que trop d’unités sont présentes, simplement à cause de l’architecture logicielle.
Vous avez peut-être entendu parler de certains protocoles ayant abordé ce problème et proposant leurs propres solutions parallèles. Prenons Solana, actuellement le protocole affichant le TPS le plus élevé, qui possède une capacité d’exécution parallèle. Toutefois, son approche diffère de celle de TON. Solana regroupe les transactions selon leurs dépendances d’exécution : les groupes distincts ne partagent aucun état. Ainsi, les transactions de groupes différents peuvent s’exécuter en parallèle sans conflit. En revanche, au sein d’un même groupe, l’exécution reste séquentielle.
TON, quant à lui, abandonne complètement l’architecture séquentielle au profit d’un paradigme de développement conçu dès l’origine pour le parallélisme : le modèle Actor. Proposé initialement par Carl Hewitt en 1973, ce modèle vise à résoudre la complexité des états partagés dans les programmes concurrents via le passage de messages. Chaque Actor possède un état privé et un comportement propres, sans partager aucun état avec d’autres Actors. Le modèle Actor est un modèle de calcul concurrent qui utilise le passage de messages pour réaliser le calcul parallèle. Dans ce modèle, l’« Actor » est l’unité de base, capable de traiter les messages reçus, de créer de nouveaux Actors, d’envoyer d’autres messages, et de décider comment répondre aux messages futurs. Il repose sur trois caractéristiques essentielles :
-
Encapsulation et indépendance : chaque Actor traite les messages de manière entièrement autonome, permettant un traitement parallèle sans interférence.
-
Passage de messages : les Actors interagissent exclusivement par envoi et réception de messages, de façon asynchrone.
-
Structure dynamique : les Actors peuvent créer d’autres Actors durant l’exécution, offrant une extensibilité adaptative au système.
TON adopte cette architecture pour modéliser les contrats intelligents. Cela signifie que chaque contrat intelligent dans TON est un Actor, disposant d’un espace de stockage totalement indépendant, sans dépendance à aucune donnée externe. De plus, les appels à un même contrat intelligent sont exécutés selon l’ordre des messages dans sa file d’entrée. Ainsi, les transactions dans TON peuvent être exécutées en parallèle de manière très efficace, sans risque de conflits.
Cependant, cette conception entraîne de nouvelles implications. Pour les développeurs DApp, le paradigme habituel est bouleversé. Voici les principaux impacts :
1. Appels asynchrones entre contrats intelligents : dans TON, il est impossible d’appeler atomiquement un contrat externe ou d’accéder à ses données depuis un contrat intelligent. En Solidity, il est courant qu’une fonction d’un contrat A appelle une fonction d’un contrat B, ou lise un état via une fonction de lecture d’un contrat C, le tout de manière atomique dans une seule transaction. C’est simple et intuitif. Mais dans TON, cela est impossible. Toute interaction externe se fait par envoi d’une nouvelle transaction, dite « message interne », exécutée de façon asynchrone. Le processus ne peut pas bloquer l’exécution en attendant un résultat.
Par exemple, développons un DEX. Dans un paradigme EVM classique, on utilise souvent un contrat routeur centralisé pour gérer les itinéraires d’échange, tandis que chaque pool gère indépendamment les données LP d’une paire de trading. Supposons deux pools : USDT-DAI et DAI-ETH. Si un utilisateur veut acheter du ETH directement avec du USDT, le contrat routeur peut orchestrer les deux pools dans une seule transaction, réalisant ainsi un échange atomique. Mais dans TON, cela devient beaucoup plus complexe. Il faut repenser entièrement le paradigme. Même en réutilisant l’ancien modèle, le flux d’information pourrait impliquer un message externe initié par l’utilisateur et trois messages internes (notez que ceci sert uniquement à illustrer les différences ; en pratique, même le paradigme ERC20 devrait être repensé).
2. Gestion rigoureuse des erreurs lors des appels inter-contrats, avec mise en place de fonctions de rebond (bounce) pour chaque appel. Sur les EVM classiques, si une erreur survient pendant l’exécution d’une transaction, toute la transaction est annulée (rollback), ramenant l’état initial. C’est compréhensible dans un modèle monofil séquentiel. Mais dans TON, comme les appels entre contrats sont asynchrones, même si une étape ultérieure échoue, les transactions précédemment exécutées restent validées, ce qui peut poser problème. Pour cela, TON prévoit un type spécial de message : le message de rebond. Quand une erreur survient dans une chaîne d’exécution déclenchée par un message interne, le contrat déclenché peut invoquer la fonction de rebond du contrat initiateur pour réinitialiser certains de ses états.
3. Dans certains cas complexes, une transaction reçue en premier n’est pas forcément exécutée en premier — il ne faut donc pas présumer d’un ordre temporel. Dans un système d’appels asynchrones et parallèles, définir l’ordre d’exécution peut être délicat. C’est pourquoi chaque message dans TON possède un « temps logique » appelé Lamport time (noté lt). Il permet de comprendre quel événement en a déclenché un autre, et de déterminer ce que les validateurs doivent traiter en priorité. Dans un modèle simple, une transaction reçue en premier est exécutée en premier.
Dans ce modèle, si A et B représentent deux contrats intelligents, alors si msg1_lt < msg2_lt, on a tx1_lt < tx2_lt.
Mais dans des cas plus complexes, cette règle peut être violée. La documentation officielle donne l’exemple suivant : supposons trois contrats A, B et C. Dans une transaction, A envoie deux messages internes, msg1 à B et msg2 à C. Bien que créés dans un ordre précis (msg1 puis msg2), on ne peut pas garantir que msg1 sera traité avant msg2. Car les routes de A vers B et de A vers C peuvent différer en longueur ou en composition de validateurs. Si ces contrats sont sur des ShardChains différentes, un message peut mettre plusieurs blocs à atteindre sa destination. Deux chemins de transaction sont donc possibles, comme illustré ci-dessous.
4. Dans TON, le stockage persistant des contrats intelligents utilise une structure de graphe orienté acyclique (DAG) dont l’unité est la Cell. Les données sont compactées selon des règles d’encodage en une Cell, puis s’étendent sous forme de DAG. Cela contraste avec la structure basée sur des hashmaps utilisée dans l’EVM. En raison des algorithmes de requête différents, TON applique des tarifs Gas variables selon la profondeur des données : plus une Cell est profonde dans le DAG, plus son traitement coûte cher. Cela ouvre la porte à une forme d’attaque DOS : un utilisateur malveillant peut saturer les Cell peu profondes d’un contrat avec des messages inutiles, augmentant ainsi le coût de stockage pour les utilisateurs honnêtes. Dans l’EVM, comme la complexité de recherche d’une hashmap est O(1), le coût Gas est uniforme, évitant ce problème. Les développeurs DApp sur TON doivent donc éviter les types de données illimités. S’ils sont inévitables, ils doivent être fragmentés (shardés).
5. Certains autres aspects sont moins spécifiques : les contrats intelligents doivent payer un loyer pour le stockage, dans TON, les contrats sont nativement upgradables, et bénéficient d’une fonctionnalité d’abstraction de comptes : toutes les adresses de portefeuilles sont des contrats intelligents, simplement non initialisés, points auxquels les développeurs doivent prêter attention.
Voici quelques réflexions issues de mon apprentissage récent de la technologie TON, que je partage avec vous. Si des erreurs figurent dans ce texte, merci de me les signaler. Par ailleurs, je pense que grâce au trafic massif de Telegram, l’écosystème TON apportera inévitablement de nouvelles applications innovantes au Web3. Les développeurs intéressés par les DApps TON peuvent me contacter pour en discuter ensemble.
@web3_mario
