Comprendre la logique technique de TON : axée sur des applications à haut débit
TechFlow SélectionTechFlow Sélection
Comprendre la logique technique de TON : axée sur des applications à haut débit
La feuille de route technique de TON continuera de renforcer les avantages de vitesse et d'évolutivité de TON.
Dédié à des analyses Web3 approfondiesRédaction : Association Blockchain de l'Université de Pékin Kiwi
TON repose sur une logique technologique centrée sur des applications à haute vitesse : né au sein de Telegram, les transactions sur TON s’inscrivent directement sur la blockchain sous forme de « messages », avec prise en charge du peer-to-peer ;
-
Transmission asynchrone de messages : en utilisant FunC comme langage de développement, les nœuds de TON communiquent via l’échange de « messages ». Étant donné que TON est une blockchain asynchrone, le concept de temps logique (lt) a été introduit afin d’assurer la synchronisation correcte des messages entre chaînes, garantissant ainsi que les messages sont exécutés selon un ordre strict de lt pour assurer l’intégrité des opérations ;
-
Mécanisme de routage de messages basé sur l’hypercube : TON adopte un système combinant un routage standard et un routage rapide. Le routage standard utilise une structure cubique où les messages inter-shards transitent par des nœuds adjacents, tandis que le routage rapide accélère la transmission grâce à des preuves Merkle relayées le long des arêtes de l’hypercube ;
-
Consensus PoS + BFT favorable au développement de l’écosystème : le PoS évite les calculs intensifs liés à la création de blocs, offrant ainsi une meilleure efficacité, des coûts réduits et de meilleures performances réseau, propices au déploiement d’applications DApp. Bien que le DPoS soit plus rapide, son niveau de confiance et sa vitesse de traitement sont inférieurs à ceux d’un système BFT. C’est pourquoi TON opte pour le BFT.
L’architecture dynamique à multi-sharding de TON facilite la scalabilité des applications : TON améliore sa vitesse via le traitement parallèle, augmente la précision des requêtes via le sharding dynamique, et renforce son extensibilité grâce à la structure « bag of cells » ;
-
Architecture dynamique à multi-sharding : TON comporte trois niveaux — une chaîne maître unique (masterchain), plusieurs chaînes de travail (workchain) et des chaînes de shard (shardchain) pouvant être créées, divisées ou fusionnées dynamiquement. Chaque shardchain regroupe diverses « account-chains », et les DApps peuvent activer indépendamment une shardchain spécifique ;
-
État global rapidement mis à jour : l’état global est actualisé via une structure similaire à un DAG appelée « bag of cells ». La mise à jour s’effectue en liant les anciennes et nouvelles cellules, puis en supprimant l’ancienne racine. De plus, des blocs verticaux permettent de corriger rapidement les blocs défectueux.
À l’avenir, TON poursuivra l’optimisation de son cadre technique : grâce à l’extension parallèle, au lancement d’outils de sharding de chaînes et au renforcement des vérifications entre nœuds, TON continuera d’améliorer ses avantages en termes de vitesse et de scalabilité.
Le défi de l’extensibilité des blockchains
L’extensibilité des blockchains constitue un défi technique majeur, essentiel au développement de la technologie blockchain : avec la croissance continue des applications blockchain et l’augmentation du nombre d’utilisateurs, les réseaux existants font souvent face à des problèmes de débit insuffisant et de délais de confirmation élevés. La conception traditionnelle des blockchains limite leur capacité à traiter de grandes quantités de transactions, entraînant congestion du réseau, frais élevés et faible efficacité ;
Les difficultés d’extensibilité proviennent principalement de l’architecture distribuée et des mécanismes de consensus : tout d’abord, le caractère distribué et le mécanisme de consensus exigent que chaque nœud valide et enregistre toutes les transactions, ce qui limite le débit du réseau. Ensuite, les exigences de sécurité et de décentralisation imposent à tous les nœuds de conserver une copie complète de la blockchain, augmentant ainsi la charge de stockage et de transmission ;
Pour résoudre ces limitations, diverses solutions ont été proposées : comme le sharding, les sidechains, ou encore les solutions de couche 2 (Layer 2). Ces approches visent à diviser le réseau en segments plus petits, créer des blockchains indépendantes ou ajouter des structures supplémentaires à la chaîne principale afin d’améliorer le débit et les performances. Toutefois, elles soulèvent également de nouveaux défis techniques et questions de sécurité, notamment la communication entre shards, le transfert d’actifs inter-chaînes et la conception des mécanismes de consensus.
-
Sharding : l’idée fondamentale consiste à diviser le réseau blockchain en plusieurs fragments (shards), chacun pouvant traiter indépendamment une partie des transactions et données. En répartissant les charges, cette méthode améliore le débit global. Toutefois, elle pose des problèmes de sécurité et de cohérence dans la communication entre shards, et nécessite une conception robuste du consensus pour assurer l’uniformité et la sécurité du réseau ;
-
Sidechains : cette technologie permet de créer des blockchains indépendantes connectées à la chaîne principale (mainchain), autorisant des transferts bidirectionnels d’actifs tout en ayant leurs propres règles fonctionnelles. En déplaçant certaines transactions vers des sidechains, on allège la charge de la mainchain et on gagne en flexibilité. Toutefois, cela nécessite des protocoles sécurisés pour garantir la sécurité et la cohérence des actifs, ainsi qu’une compatibilité et une interopérabilité soigneusement pensées ;
-
Rollup : le principe consiste à stocker massivement les données transactionnelles hors chaîne (sur une sidechain), puis à soumettre uniquement un résumé (« digest ») à la chaîne principale pour validation. Cette approche améliore considérablement l’extensibilité et les performances, en réduisant la charge de calcul et de stockage sur la chaîne principale. Néanmoins, elle suscite des préoccupations en matière de centralisation et de sécurité ;
-
Nouveaux mécanismes de consensus : par exemple, Solana utilise le Proof of History (POH), qui associe un horodatage à chaque transaction afin de fournir une séquence temporelle vérifiable. Cela réduit les coûts de communication et les retards dans le processus de consensus. Bien que Solana annonce un TPS pouvant atteindre 65 000, une grande partie correspond en réalité aux communications entre nœuds, la limite effective des données utiles étant plutôt de 6 à 8 k (environ 4 à 5 k en conditions normales).
La blockchain TON découle de Telegram, dont la vision initiale était de servir une base massive d’utilisateurs : Telegram est l’une des plateformes sociales les plus populaires au monde, avec plus de 800 millions d’utilisateurs mensuels actifs, échangeant quotidiennement des dizaines de milliards de messages. En tant que transformation web3 de Telegram, TON a été conçu dès le départ pour desservir des milliards d’utilisateurs, bien au-delà d’un usage limité à une petite communauté.
L’architecture technique de TON
Conception multi-chaînes à sharding infini et adaptatif
Le sharding de TON est construit de manière ascendante (bottom-up) : les solutions classiques de sharding adoptent généralement une approche descendante (top-down), consistant à diviser une blockchain unique en plusieurs chaînes interconnectées pour améliorer les performances. En revanche, TON adopte une approche ascendante : les chaînes de comptes (account-chains) sont organisées en shardchains, de sorte que les workchains n’existent dans les shardchains que sous forme virtuelle ou logique. TON permet ainsi à plusieurs chaînes de traiter les transactions en parallèle, formant ce qu’on appelle une « blockchain of blockchains », augmentant efficacement les performances du système ;
TON possède une architecture de sharding dynamique : composée de masterchain, workchain et shardchain. La masterchain assure la coordination, tandis que les workchains et shardchains traitent effectivement les transactions. Par ailleurs, le sharding est dynamique : chaque compte peut constituer une shardchain, et celles-ci peuvent s’adapter automatiquement en se combinant pour répondre à des besoins d’extension variables.
-
Masterchain : il n’en existe qu’une seule. Elle contient les paramètres du protocole, l’ensemble des validateurs et leurs parts, ainsi que la liste des workchains actives et de leurs shardchains associées. Les chaînes inférieures y soumettent le hachage de leur dernier bloc afin de garantir un état à jour lors des lectures inter-chaînes.
-
Si les shards atteignent leur limite, chaque shardchain ne contiendra plus qu’un seul compte ou contrat intelligent. Cela conduira à un grand nombre de « account-chains », chacune représentant l’état et les transitions d’un compte unique. Ces account-chains communiqueront entre elles, formant ainsi les workchains via les shardchains.
-
Workchain : concept virtuel désignant un ensemble de shardchains. Le système supporte jusqu’à 2^32 workchains. Chaque workchain peut personnaliser librement ses règles (types de transactions, jetons, contrats intelligents, formats d’adresses, etc.), à condition de respecter les standards d’interopérabilité. Toutefois, toutes les workchains doivent partager un format de file de messages identique pour permettre l’échange, ce qui implique aussi des garanties de sécurité similaires ;
-
Shardchain : pour améliorer l’efficacité, les shardchains peuvent se diviser automatiquement en cas de forte charge, ou se fusionner lorsque la charge diminue. Chaque workchain peut être découpée en jusqu’à 2^60 shardchains. Le travail est réparti entre toutes les shardchains, chacune ne servant qu’un sous-ensemble de comptes.
Mécanisme de transmission des messages
Message : puisque TON utilise le langage FunC et en particulier la fonction send_raw_message, les communications entre nœuds sont appelées « messages ». Sur TON, une transaction est constituée du message entrant initial qui la déclenche, ainsi qu’un ensemble de messages sortants envoyés à d’autres contrats ;
Hypercube Routing : mécanisme de transmission basé sur une structure tridimensionnelle, permettant à un message créé dans un bloc d’une shardchain d’être rapidement transmis et traité dans le bloc suivant de la shardchain cible.
Transmission asynchrone des messages
Les appels asynchrones posent un problème de synchronisation : dans une blockchain synchrone, une transaction peut contenir plusieurs appels de contrats intelligents. Dans un système asynchrone, l’utilisateur ne peut pas obtenir immédiatement la réponse du contrat cible au sein de la même transaction, car le traitement peut prendre plusieurs blocs. La distance de routage entre le bloc source et le bloc cible influence ce délai ;
Pour permettre un sharding infini, il faut garantir une parallélisation totale des messages, d’où l’introduction du temps logique : sur TON, chaque transaction s’exécute sur un seul contrat intelligent, et la communication entre contrats se fait via des messages. C’est pourquoi le concept de temps logique (ou temps de Lamport, noté lt) est utilisé dans les chaînes asynchrones pour synchroniser les messages inter-chaînes. Ce temps trace les relations entre événements et détermine l’ordre de traitement requis par les validateurs ;
Les messages sont traités selon un ordre strict de lt pour assurer la logique opérationnelle : les messages envoyés depuis un compte et les transactions sur un compte sont rigoureusement ordonnés. Le lt d’une transaction est supérieur à celui du message qui l’a déclenchée. Le lt d’un message envoyé dans une transaction est strictement supérieur à celui de ladite transaction. En cas de plusieurs messages, celui ayant le lt le plus bas est traité en priorité.
Mécanisme de routage hypercube des messages
TON combine routage rapide et lent, fonctionnant en parallèle :
Routage lent : méthode traditionnelle et plus stable pour le traitement des messages inter-chaînes. Le message est inclus dans un bloc sur la chaîne source, puis relayé d’une shardchain à une autre via des relais, éventuellement à travers plusieurs shards intermédiaires. L’ensemble des shardchains forme un graphe en « hypercube », et les messages se propagent le long des arêtes de cet hypercube. Après validation par les validateurs, ils sont inclus dans un nouveau bloc ;
Avantage du routage lent : meilleure sécurité et décentralisation, car tous les messages passent par un processus complet de confirmation de bloc. Pour un réseau d’hypercube de taille N, le nombre de sauts requis est hop = log16(N). Ainsi, seulement 4 nœuds de routage suffisent pour supporter un million de shardchains.
Routage rapide : alors que le routage lent suit les arêtes de l’hypercube, le routage rapide permet aux validateurs de la shardchain cible de traiter prématurément le message, en fournissant une preuve Merkle et un accusé de réception pour annuler le message en cours de transmission ;
Le routage rapide est plus rapide (les nœuds trouvent un chemin optimal) et empêche les doublons, mais ne peut remplacer complètement le routage lent, car les validateurs ne sont pas pénalisés en cas de perte du reçu, ce qui représente un risque de sécurité.
État global des shardchains
« Bag of cells » : ensemble de cellules mis à jour selon une structure similaire à un DAG. Le nouvel état est représenté par un nouveau « bag of cells » doté de sa propre racine. On lie ensuite les anciennes et nouvelles cellules, puis on supprime l’ancienne racine ;
Réparation par bloc vertical : chaque bloc dans une shardchain de TON n’est pas isolé, mais fait partie d’une chaîne. En cas d’erreur, un nouveau bloc est ajouté à une « blockchain verticale » pour remplacer le bloc défectueux.
Mécanisme de consensus
Dans le réseau PoS, on distingue trois rôles :
-
Nœuds validateurs : après avoir satisfait aux exigences matérielles, un nœud peut participer à la sécurisation du réseau en mettant en jeu 300 000 TON ;
-
Tous les blocs sont créés par 100 à 1000 nœuds sélectionnés, élus mensuellement. À l’élection, les nœuds doivent verrouiller leurs TON en gage. Pendant leur mandat, ils sont divisés en groupes de travail pour produire de nouveaux blocs. Un bloc est validé s’il obtient les signatures de plus des deux tiers des nœuds du groupe. En cas de comportement malveillant, ils subissent un slash et perdent leur droit de participation ;
-
Fishermen (pêcheurs) : rôle de surveillance, ils détectent les validateurs inactifs ou malhonnêtes en soumettant des preuves d’invalidité ;
-
Correcteurs (ou « collators ») : ils proposent aux validateurs de nouveaux blocs candidats pour les shardchains. S’ils sont validés, ils sont récompensés. Ils vérifient l’état de la shardchain et les données des shardchains voisines, puis les transmettent aux validateurs.
BFT : après analyse, TON a conclu que bien que le DPoS soit plus rapide, son niveau de confiance et sa vitesse sont inférieurs à ceux d’un système BFT. C’est pourquoi TON a choisi le BFT (tolérance aux fautes byzantines).
Le nouveau cadre de TON peut supporter la transmission ultra-rapide d’informations de TG
TON réalise une haute vitesse de transaction et une finalité rapide grâce à son architecture dynamique à multi-sharding : TON peut créer une chaîne dédiée pour chaque portefeuille utilisateur. Le calcul parallèle des shards, la communication instantanée entre shards et le TVM supportant le calcul asynchrone constituent la base théorique d’un TPS élevé ;
TON gagne en extensibilité grâce à son mécanisme de transmission : sur TON, les appels entre contrats intelligents sont asynchrones, non atomiques. Cela signifie qu’un appel n’est pas exécuté immédiatement, mais traité dans un bloc futur après la fin de la transaction. Cette conception favorise une meilleure scalabilité, car elle n’exige pas que tous les traitements aient lieu dans un seul bloc.
TON poursuivra l’optimisation de son cadre technique…
La feuille de route technique de TON continuera d’améliorer ses avantages en vitesse et scalabilité
-
Séparation entre les séquenceurs et les validateurs ;
-
Amélioration de l’extensibilité et de la vitesse : permettre à TON de s’étendre en parallèle même sous forte charge transactionnelle ;
-
Guide et outils de sharding de chaînes : documentation et exemples de code pour configurer efficacement des workchains TON dans les bourses, systèmes de paiement et services TON ;
-
Renforcement de la coordination entre nœuds validateurs : amélioration de la détection et des sanctions contre les validateurs sous-performants.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
