Telegram TON, qu’y a-t-il sous le capot ?
Quelques généralités (TLDR)
Everything is a bag of cells
Le Réseau s’appelle TON, il est développé en C++ et le jeton est le GRAM. La machine virtuelle est le TVM dont le language de smart contract est le Fift qui est basé sur le FORTH. Il y a une masterchain qui valide des shardchains (qui peuvent avoir leurs propres jetons) via leur hash des blocks finalisés (ShardBlock). Les données sont stockées au sein de cellules (cell) de 1023 octets dispatchées sur les shardchains. La communication entre shardchains se fait via Hypercube Routing (HR). Les portefeuilles sont des Accounts qui ne sont rien d’autres que des simples smartcontracts. Le consensus des blockchains est PoS avec des validateurs qui sont élus par un process qui est défini au sein d’un smartcontract sur la masterchain. La cryptographie est contruite sur les courbes d’Edward (Ed25519) qui est réputée plus rapide que celle de bitcoin (Secp256k1) et plus sûre (le choix des paramètres n’est pas entaché d’une réputation de backdoor par la NSA)
En générale les papiers décrivant TON sont très verbeux et pas très clair. Régulièrement la description d’un même concept avec un mélange de mathématique pour des choses parfois simples (mention spéciale au concept de ∃-elimination ou constructive elimination of existence quantifiers) est dispatché en plusieurs endroits des documents ce qui rend parfois laborieuse la compréhension. On a parfois même l’impression que l’auteur Nikolai Durov change de vision technique en cours de document ou alors que plusieurs auteurs y ont contribué.
Une masterchain et des shardchains
La cryptomonnaie de Telegram s’organise autour d’une masterchain qui fait foi sur l’état général de la blockchain et des shardchains pour permettre de faire passer de nombreuses transactions sans impacter tout le système. Ce n’est pas sans rappeler la structuration de ETH 2.0 avec sa chaîne beacon et ses multiples shards sur des sidechains ou encore la srtucturation polkadot.
Techniquement la masterchain enregistre les hashs des derniers blocks des shardchains autorisées.
Là où se différencie TON est l’organisation des données autour de cellules qui seront stockées sur les différentes shardchains. Ces cellules via un système de liens permettra de reconstruire les wallets (Account).
C’est aussi la masterchain qui décide des paramètres des shardchain au sein d’un ‘master’ smartconract:
- la quantité de GRAM ou d’autres jetons en circulation
- Enregistrement de nouvelle shardchain
- Consensus appliqué (nombres de validateurs, détails du processus d’élection)
- Prix du gas
- Version de la TVM utilisée
- Un arbre de merkle des hash des blocks finalisés sur les shardchains.
Cependant aucune information supplémentaire n’a encore filtré sur les mécaniques d’élections autre qu’il s’agit d’un dérivé de preuve d’enjeu (PoS). Pas de minage donc.
Les Wallets et transactions
Un Wallet est un simple smart contract avec un solde et les règles de validation multisignatures m/n (pour un simple wallet m = n = 1)
Les transactions sont donc toutes des appels de smart-contrats qui est porté par la machine virtuelle TVM
La cellule, et méthode de reconstruction de l’état des smartcontracts
Les données sont stockée dans des cellules de 1023 octets et contient jusqu’à 4 références à d’autres cellules (çà sent bon le DAG, Directed Acyclic Graph cher au projet IOTA). Ces données correspondent aux stockages de blocks des transactions et des états de smartscontracts (et donc de wallets). Et les noeuds conservent le DAG des hash de ces cellules. Ainsi un block ou une transaction peut référencer une cellule dans cette base de donnée décrite par le DAG pour pouvoir être validée. Les données sous-jacentes pourront être effectivement stockée sur différentes shardchains, mais le DAG, avec un système de routage adapté (Hypercube Routing) permettra de retrouver ses petits. Le challenge du consensus (bien que pas du tout expliqué en détail) sera de faire en sorte que tous les noeuds de la masterchain et des shardchains)partagent le même DAG.
Ainsi un smartcontract peut avoir ses données dispatchée sur plusieurs shardchain. Aussi une méthode est prévue pour valider et reconstruire l’état complet du smartcontract.
Prenons l’exemple du wallet qui est comme on l’a dit un smart contract simple. Ses données sont organisée autour:
- un identifiant (adresse) composé d’un préfixe (32 bits, qui défini au niveau de la shardchain) et du hash du smartcontract (256 bits, qui contient notamment la clef publique)
- le bytecode du smartcontrat. Si inexistant sur la blockchain il est dans un état non initialisé, mais l’utilisateur peut toujours recevoir des fonds. Il n’y a pas besoin de publier le smart contract pour l’utiliser (similaire à bitcoin).
- l’état du smartcontract qui est modifié à chaque appel du smartcontract par une transaction.
Note : Je livre ci-dessous ma compréhension, je n’ai trouvé nulle part une explication permettant la validation de bout en bout d’une transaction.
Imaginons que le noeud N doive valider une nouvelle transaction T qui appelle ce smartcontract SC.
- le noeud demande l’emplacement du stockage du smartcontract destinataire au système de routage Hypercube Routing HR.
- Si la donnée est sur la même shardchain, le contrat executé et la transaction finalisée, inclus dans le prochain block
- Sinon HR va envoyer créer un message composé de la transaction et de donnée de routage (une enveloppe) pour récupérer la donnée de proche en proche (plus de détails sur le chapitre HR)
- Il faut noter dans ce cas que le message est diffusé dans des pools spécifiques des les shardchains successives. Cela peut mettre longtemps avant de finaliser une transaction
- Pour éviter les abus du système de messages (message sans vrai destinataire par exemple), le slashing est utilisé.
- On apprend au détour d’une page qu’il y a des fees pour le HR, mais aucune idée de comment c’est appliqué.
Hypercube Routing
Ce système de routage est somme toute simple, je vous fait économiser un paquet de math dans le document :
- chaque shard est identifié par une adresse unique de 32 bits
- prenons sur 4 bits comme exemple. Allons de l’adresse 1010 à l’adresse 0110
- le premier bit diffère donc envoyons le message à l’adresse 0010
- le deuxième bit diffère allons à l’adresse 0110
- Nous voilà arrivé
Les shards voisins sont connectés directement (c’est à dire que leur pool de messages sont directement connectés). Ainsi la shardchain 0010 est voisin de la shardchain 0110.
J’imagine que par construction les adresses de shardchain sont créés de proche en proche (c’est à dire itérativement 0000, 0001, 0010, 0011, etc…) pour éviter les trous dans le routage. Dans notre exemple, si le shard 0010 n’existe pas, le message est bloqué. Mais cela n’est pas spécifié.
Une machine virtuelle TVM avec un language de programmation FIFT dérivé du FORTH
A priori c’est basé sur une pile LIFO (ou notation booléenne inverse) comme pour bitcoin d’ailleurs pour l’execution du code.
Donnons tout de suite un exemple pour calculer (1+2)*5. Nous allons l’encoder de la façon suivante : 1 2 + 5 * et exécuter pas à pas en partant de la gauche en ajoutant chaque élément sur la pile :
- 1
- 1 2
- 3 (le + est exécuté sur les deux éléments et donc les replace par le résultat)
- 3 5
- 15 (le * est exécuté et donc les remplace par le résultat)
Pour le système TVM c’est exactement la même chose mais avec des fonctions et des données plus avancées (clefs publiques, signatures, verifier la signature, hasher une donnée, des exécutions conditionnelles comme IF THEN ELSE ou CALL etc…)
La machine virtuelle est dite Turing-Complet et donc hérite des problèmes d’Ethereum sur la preuve de l’absence de bugs dans les smartcontracts.
Rien de extrêmement nouveau surtout que déjà les développeurs ont réussi à porter le compilateur Solidity de la machine virtuelle Ethereum EVM sur TVM. Cela dit pour la compatibilité avancée cela risque d’être plus complexe puisque les logiques de stockage et de message semble être fondamentalement différent. La citation du CEO d’ailleurs me laisse rêveur et me fait plutôt penser un un PR stunt pour récupérer les devs Ethereum
That was probably the most difficult thing we built. Alexander Filatov
En revanche la vrai difficulté va être de pouvoir adapter le concept de cellules à la gestion de l’états du smartcontract. Et ce n’est pas une mince affaire: 256 représentations de cellules avec jusqu’à 4 différents niveaux, des arbres de Merkle et un Direct Acyclic Graph, Ouf !
Concrètement où en est on ?
L’état en ce moment du développement est difficile à dire:
- le code disponible est seulement le client léger, c’est à dire qu’il seulement implémente la cryptographie et la machine virtuelle pour l’exécution des smartcontrats mais rien sur le consensus ou la gestion du réseau p2p n’est encore disponible
- Des GRAM (plutôt des promesses) se revendent sous le manteau depuis Août 2019, en infraction avec les termes signés par les investisseurs.
- Aucune information n’a filtré. La seule chose qui se rapproche du concret est le bot telegram où on peut créer un wallet et manipuler des (testnet donc faux) GRAM. Mais impossible de mettre la main sur un serveur ou un explorateur du testnet
Si quelqu’un a plus d’information je serai ravi de mettre à jour cet article
