8 milliards d'utilisateurs actifs mensuels : l'écosystème TON soutenu par Telegram comme terrain d'expérimentation pour les DApps non financiers(Ⅱ)

II. Caractéristiques de TON

  1. Caractéristiques techniques de TON

TON résout les problèmes d’évolutivité et d’interopérabilité des blockchains grâce à son architecture multi-chaînes. Plus précisément, les caractéristiques techniques de TON peuvent être divisées comme suit :

a. Architecture multi-chaînes : La blockchain TON est un ensemble de blockchains, composé de trois niveaux : la chaîne principale (Masterchain), les chaînes de travail (Workchain) et les chaînes de fragments (Shardchain) (le nombre maximal de chaînes de travail peut atteindre 2^32, d’autres sources mentionnent 2^92, mais la dernière version du livre blanc indique 32 comme puissance, si ce n’est pas exact, veuillez nous contacter pour correction). La chaîne principale est la chaîne centrale, contenant toutes les informations sur le protocole et les paramètres actuels. Les chaînes de travail traitent les transactions de contrats intelligents, et les chaînes de travail se fragmentent ensuite pour devenir des chaînes de fragments. Grâce aux chaînes de travail et à la fragmentation dynamique, TON peut valider et traiter des millions de transactions par seconde, offrant une évolutivité et une interopérabilité à grande échelle rapidement, quelle que soit la taille du réseau, et permettant un échange instantané de messages entre n’importe quelles deux blockchains.

Les chaînes principales et les chaînes de travail de TON sont hétérogènes, ce qui signifie que différentes chaînes de travail peuvent avoir des “règles” différentes, telles que des formats d’adresse de compte différents, des formats de transaction différents, des machines virtuelles de contrats intelligents (VM) différentes, des crypto-monnaies de base différentes, etc. Cependant, elles respectent certaines normes minimales d’interopérabilité pour rendre les interactions entre différentes chaînes de travail possibles et relativement simples. En ce sens, l’hétérogénéité de TON est similaire aux projets EOS et Polkadot.

Les chaînes de travail et les chaînes de fragments de TON sont homogènes. Chaque chaîne de travail peut être divisée en jusqu’à 2^60 chaînes de fragments, ou chaînes de fragments (d’autres sources mentionnent 2^64, mais la dernière version du livre blanc indique 60 comme puissance, si ce n’est pas exact, veuillez nous contacter pour correction). Les chaînes de fragments partagent les mêmes règles et formats de blocs que les chaînes de travail auxquelles elles appartiennent, mais elles ne gèrent qu’un sous-ensemble de comptes, en fonction des premiers caractères de l’adresse du compte. Étant donné que toutes ces chaînes de fragments partagent le même format de bloc et les mêmes règles, elles sont homogènes, semblables à ce qui est discuté dans les propositions d’extension d’Ethereum.

b. Preuve de participation + Tolérance aux fautes byzantines : Le mécanisme de consensus utilisé par TON est similaire à celui de Cosmos et Polkadot. Selon le livre blanc, il est possible de devenir nœud sans autorisation, nécessitant seulement une certaine quantité de jetons et des compétences en gestion informatique ordinaires. Le réseau TON comprend quatre rôles : Validateur (Validator), Nominator, Pêcheur (Fisherman) et Collateur (Collator). Si un validateur signe une proposition de bloc invalide, il peut être automatiquement pénalisé, perdre une partie ou la totalité de son engagement, ou être temporairement suspendu du groupe des validateurs. En outre, le mécanisme BFT garantit que le consensus ne diverge pas et est mieux adapté à une architecture multi-chaînes “étroitement couplée”.

c. Protection de la confidentialité des comptes : TON Proxy (couche de réseau/ anonymat), similaire à I2P (Invisible Internet Project), est utilisé pour cacher l’identité et créer un réseau privé virtuel décentralisé (��) pour protéger la confidentialité en ligne. Par exemple, les nœuds de compte ayant un grand nombre de jetons, ou ceux qui souhaitent cacher leur adresse IP exacte et leur emplacement géographique pour se protéger contre les attaques DDoS, valorisent cette fonctionnalité.

d. FunC/Fift/TACT : FunC est un langage de programmation pour la machine virtuelle TON (TVM). Ce langage statiquement typé et spécifique au domaine est utilisé pour écrire des contrats intelligents sur la blockchain TON. En général, FunC n’est pas directement compilé en bytecode, mais plutôt via un autre langage de bas niveau appelé Fift. Tout comme FunC, Fift est un autre langage conçu spécialement pour la blockchain TON. Fift est un langage bas niveau très proche des codes d’opération TVM, spécialement utilisé pour développer et gérer les contrats intelligents sur la blockchain TON et interagir avec la machine virtuelle TON. Pour la plupart des développeurs, FunC et Fift sont assez complexes, donc une langue plus accessible, TACT, a été introduite par les développeurs pour simplifier l’utilisation.

  1. Différences entre TON, ETH et Solana

L’équipe TON a rédigé un document pour clarifier les différences entre TON, Solana et Ethereum :

a. Temps de bloc et de finalisation : Les utilisateurs sont généralement intéressés par la vitesse des transactions et des blocs. Plus vite les blocs sont construits, moins les utilisateurs attendent pour les transferts et l’exécution des contrats intelligents.

TON - TON génère un nouveau bloc environ toutes les 5 secondes sur chaque chaîne de fragments et la chaîne principale, avec les nouveaux blocs sur les chaînes secondaires générés presque simultanément, tandis que le nouveau bloc sur la chaîne principale est généré environ une seconde plus tard, car il doit inclure les valeurs de hachage des derniers blocs de toutes les chaînes de fragments.

ETH - Ethereum comprend des créneaux horaires (slots) et des époques (epochs). Un créneau horaire est un intervalle de 12 secondes pendant lequel les validateurs peuvent proposer de nouvelles chaînes de balises et de fragments. 32 créneaux horaires composent une époque (6,4 minutes). Il existe des règles spécifiques selon lesquelles la confirmation finale d’un bloc nécessite au moins 2 époques, ce qui signifie qu’il faut au moins 12,8 minutes pour confirmer un bloc.

Solana - Solana affirme pouvoir générer un bloc par seconde ou plus rapidement, mais elle a un temps de détermination de bloc prolongé. Un bloc est généralement finalisé après 16 tours de vote, chaque tour durant environ 400 millisecondes, ce qui signifie un délai de 6,4 secondes.

b. Performance : La performance de la blockchain représente sa capacité à traiter des contrats intelligents à grande échelle, ce qui est crucial pour des produits complexes tels que DeFi, GameFi et DAO.

TON - TON est une blockchain complète (Turing-complete) et performante, capable de gérer des transactions complexes sur la chaîne principale et toutes ses chaînes de travail.

ETH - Ethereum a la complétude de Turing uniquement sur la chaîne de balises et la performance du réseau est limitée à environ 15 transactions par seconde. L’absence d’interaction entre les fragments signifie que d’autres transactions ne peuvent pas être exécutées dans un environnement véritablement décentralisé.

Solana - Solana est Turing-complete, mais elle ne fonctionne bien que pour quelques types de transactions pré-définis très simples (celles qui modifient seulement les soldes des comptes sans changer d’état), et elle fonctionne de manière optimale seulement lorsque toutes les données des comptes peuvent tenir dans la RAM (sinon, des problèmes peuvent survenir).

c. Évolutivité: L’évolutivité est directement liée au nombre d’utilisateurs et à leurs interactions (transactions, exécution de contrats intelligents, demandes d’infrastructure).

TON - TON prend en charge les chaînes de travail et la fragmentation dynamique, pouvant contenir jusqu’à 2^32 chaînes de travail, chaque chaîne de travail pouvant être subdivisée en jusqu’à 2^60 chaînes de fragments, avec une communication presque instantanée entre fragments et chaînes, permettant des millions de transactions par seconde.

ETH - Ethereum prendra en charge jusqu’à 64 chaînes de fragments et une chaîne de balises. À ce stade, il n’est pas clair quelle sera la performance exacte des nouvelles 64 chaînes de fragments et comment elles interagiront entre elles. De plus, il faudra attendre 10 à 15 minutes jusqu’à ce que les blocs des chaînes de fragments soient confirmés avant de traiter le message sur une autre chaîne de fragments. Les fragments supplémentaires ne sont pas actuellement prévus pour exécuter les contrats intelligents EVM ; ils sont plutôt attendus pour servir de stockage de données supplémentaires dans le grand livre distribué.