TON : Telegram Open Network. Partie 2 : Blockchains, sharding

Ce texte est la suite d'une série d'articles dans laquelle j'examine la structure du réseau distribué Telegram Open Network (TON), qui devrait sortir cette année. partie précédente J'y ai décrit le niveau le plus basique : le moyen d'interaction entre les nœuds.

Pour rappel, je n'ai aucune relation avec le développement de ce réseau, et tout le matériel provient d'une source ouverte (bien que non vérifiée) — document (il est également accompagné d'une brochure, qui résume brièvement les principaux points), apparue à la fin de l'année dernière. À mon avis, le volume d'informations dans ce document témoigne de son authenticité, bien qu'il n'y ait aucune confirmation officielle.

Aujourd'hui, nous allons examiner le composant principal de TON — la blockchain.

Concepts de base

Compte (account). Un ensemble de données identifiable par un nombre de 256 bits account_id (il s'agit le plus souvent de la clé publique du propriétaire du compte). Dans le cas de base (voir ci-dessous blockchain zéro), ces données désignent le solde de l'utilisateur. « Emprunter » un montant spécifique account_id peut être fait par n'importe qui, mais sa valeur ne peut être modifiée que selon des règles définies.

Contrat intelligent (smart-contract). En somme, c'est un cas particulier de compte, complété par le code du contrat intelligent et le stockage de ses variables. Dans le cas d'un « portefeuille », on peut déposer et retirer de l'argent selon des règles relativement simples et prédéfinies, alors que pour un contrat intelligent, ces règles sont écrites sous forme de code (dans un langage de programmation Turing-complet).

État de la blockchain (state of blockchain). L'ensemble des états de tous les comptes / contrats intelligents (de manière abstraite — une table de hachage où les clés sont les identifiants des comptes et les valeurs sont les données stockées dans les comptes).

Message (message). J'ai utilisé l'expression « déposer et retirer de l'argent » — c'est un exemple particulier de message (« transférer N grammes du compte account_1 au compte account_2»). Évidemment, seul un nœud possédant la clé secrète du compte peut envoyer un tel message. account_1 — et capable de le confirmer par une signature. La livraison de tels messages à un compte ordinaire entraîne l'augmentation de son solde, tandis que le contrat intelligent exécute son code (qui traitera la réception du message). Bien sûr, d'autres messages peuvent exister (transportant non des sommes d'argent, mais des données arbitraires entre des contrats intelligents).

La transaction (transaction). Le fait de livrer un message est appelé transaction. Les transactions modifient l'état de la blockchain. Ce sont les transactions (enregistrements de livraison de messages) qui constituent les blocs dans la blockchain. Dans ce sens, on peut imaginer l'état de la blockchain comme une base de données incrémentielle — tous les blocs sont des « diffs » qui doivent être appliqués successivement pour obtenir l'état actuel de la BDD. Nous parlerons des spécificités de l'emballage de ces « diffs » (et de la restauration de l'état complet à partir d'eux) dans le prochain article.

Blockchain dans TON : qu'est-ce que c'est et à quoi ça sert ?

Comme mentionné dans l'article précédent, la blockchain est une structure de données, dont les éléments (blocs) sont ordonnés en « chaîne », et chaque bloc suivant de la chaîne contient le hachage du précédent. Dans les commentaires, une question a été posée : pourquoi une telle structure de données est-elle nécessaire, alors que nous avons déjà DHT — une table de hachage distribuée ? Il est évident que certaines données peuvent être stockées dans DHT, mais cela ne convient que pour des informations qui ne sont pas trop « sensibles ». Les soldes des cryptomonnaies ne peuvent pas être stockés dans DHT — principalement en raison de l'absence de vérifications sur l'intégrité. En fait, toute la complexité de la structure de la blockchain augmente pour empêcher toute interférence avec les données qu'elle contient.

Cependant, la blockchain dans TON semble encore plus complexe que dans la plupart des autres systèmes distribués — et il y a deux raisons à cela. La première est le désir de minimiser le besoin de forks. Dans les cryptomonnaies traditionnelles, tous les paramètres sont fixés dès le départ et toute tentative de les modifier conduit en fait à l'apparition d'un « univers alternatif de cryptomonnaie ». La seconde raison est le soutien de la fragmentations (sharding, shardization) de la blockchain. La blockchain est une structure qui ne peut pas se réduire au fil du temps ; en général, chaque nœud responsable du bon fonctionnement du réseau est obligé de la stocker dans son intégralité. Dans les systèmes traditionnels (centralisés), pour résoudre de tels problèmes, on utilise le sharding : une partie des enregistrements de la base de données est sur un serveur, une autre partie est sur un autre, etc. Dans le cas des cryptomonnaies, cette fonctionnalité est encore assez rare — en particulier parce qu'il est compliqué d'ajouter le sharding à un système qui ne l'a pas prévu dès le départ.

Comment TON prévoit-il de résoudre les deux problèmes décrits ci-dessus ?

Le contenu de la blockchain. Workchains.

Tout d'abord, parlons de ce qui sera stocké dans la blockchain. Y seront conservés les états des comptes (les « portefeuilles » dans le cas de base) et des contrats intelligents (pour simplifier, considérons que c'est la même chose que des comptes). En réalité, ce sera une table de hachage classique — les identifiants seront les clés account_id, et les valeurs seront des structures de données comprenant des éléments tels que :

• le solde ;
• le code du contrat intelligent (uniquement pour les contrats intelligents) ;
• le stockage de données du contrat intelligent (uniquement pour les contrats intelligents) ;
• les statistiques ;
• (en option) la clé publique pour les transferts depuis le compte, par défaut account_id ;
• la queue des messages sortants (ici, ils sont enregistrés pour être envoyés au destinataire) ;
• la liste des derniers messages livrés à ce compte.

Comme mentionné ci-dessus, les blocs se composent directement de transactions — messages livrés à différents comptes account_id. Cependant, outre account_id, les messages contiennent également un champ de 32 bits workchain_id — l'identifiant de la soi-disant workchain (workchain, working blockchain). Cela permet d'avoir plusieurs blockchains indépendantes avec des configurations différentes. Dans ce cas, workchain_id = 0 est considéré comme un cas particulier, la workchain nulle — les soldes qui s'y trouvent correspondront à la cryptomonnaie TON (Grams). Il est probable qu'au début, il n'y aura pas d'autres workchains.

Sharding des chaînes. Paradigme infini du sharding.

Mais la croissance du nombre de blockchains ne s'arrête pas là. Examinons le sharding. Imaginons que chaque compte (account_id) dispose de sa propre blockchain — toutes les messages qui lui sont destinés y sont stockés — et les états de toutes ces blockchains sont conservés sur des nœuds séparés.

Bien sûr, c'est assez coûteux : il est probable que dans chacun de ces shardchains (shardchain, blockchain shard) les transactions arriveront très rarement et de nombreux nœuds puissants seront nécessaires (pour anticiper, je précise que ce ne sont pas juste des clients sur des téléphones mobiles — mais de véritables serveurs).

C'est pourquoi les shardchains regroupent les comptes par préfixes binaires de leurs identifiants : si un shardchain a pour préfixe 0110, toutes les transactions des account_id qui commencent par ces chiffres y seront incluses. Ce shard_prefix peut avoir une longueur de 0 à 60 bits — et ce qui est important, c'est qu'il peut changer dynamiquement.

Dès qu'un des shardchains reçoit un nombre excessif de transactions, les nœuds qui y travaillent, selon des règles prédéfinies, le « fendent » en deux enfants — leurs préfixes seront plus longs d'un bit (et pour l'un d'eux, ce bit sera égal à 0, et pour l'autre, à 1). Par exemple, shard_prefix = 0110b se fendra en 01100b et 01101b. Inversement, si deux shardchains « voisins » commencent à se sentir suffisamment à l'aise (pendant un certain temps), ils se rejoindront à nouveau.

Ainsi, le sharding s'effectue « de bas en haut » — nous supposons que chaque compte possède son shard, mais ils sont — pour un temps — « collés » par préfixes. C'est ce que sous-entend Infinite Sharding Paradigm (la paradigm du sharding infini.).

Il convient de souligner que les workchains existent uniquement de manière virtuelle — en réalité, workchain_id il s'agit d'une partie de l'identifiant d'un shardchain spécifique. Pour le dire de manière formelle, chaque shardchain est défini par une paire de nombres (workchain_id, shard_prefix).

Correction des erreurs. Blockchains verticales.

On considère traditionnellement que toute transaction dans une blockchain est « gravée dans la pierre ». Cependant, dans le cas de TON, la possibilité de « réécrire l'histoire » est prévue — dans le cas où quelqu'un (le fameux nœud « pêcheur ») prouvera qu'un des blocs a été signé incorrectement. Dans ce cas, un bloc correctif spécial est ajouté au shardchain correspondant, contenant le hachage du bloc corrigé (et non du dernier bloc du shardchain). En représentant le shardchain comme une chaîne de blocs disposée horizontalement, on peut dire que le bloc correctif s'attache au bloc défectueux non pas à droite, mais au-dessus — c'est pourquoi on considère qu'il fait partie d'une petite « chaîne de blocs verticale ». Ainsi, on peut dire que les shardchains sont des blockchains bidimensionnelles.

Dans le cas où des blocs ultérieurs référencent les modifications apportées par le bloc erroné (c'est-à-dire, des transactions valides basées sur des informations invalides), des blocs correctifs sont également ajoutés « au-dessus » de ces blocs. Si les blocs n'ont pas touché à l'information « affectée », ces « ondes correctrices » ne se propagent pas à eux. Par exemple, dans l'illustration ci-dessus, la transaction du premier bloc, qui augmente le solde du compte C, a été reconnue comme incorrecte — donc la transaction qui diminue le solde de ce compte dans le troisième bloc doit aussi être annulée, et un bloc correctif est engagé au-dessus du bloc lui-même.

Il convient de noter — bien que les blocs correctifs soient représentés comme situés « au-dessus » des originaux, en réalité, ils seront ajoutés à la fin de la blockchain correspondante (là où ils devraient se trouver chronologiquement). La disposition bidimensionnelle ne montre que le point dans la blockchain auquel ils seront « attachés » (grâce au hachage du bloc original qui s'y trouve).

On peut réfléchir séparément sur la question de savoir dans quelle mesure il est bon de « changer le passé ». Il semblerait que si nous admettons la possibilité de l'apparition d'un bloc incorrect dans le shardchain, nous devons également permettre l'éventualité d'un bloc correctif erroné. Ici, autant que je puisse juger, la différence réside dans le nombre de nœuds qui doivent atteindre un consensus sur les nouveaux blocs — une relativement petite «équipe de travail» de nœuds (changée assez fréquemment) travaillera sur chaque shardchain, tandis que l'ajout de blocs correctifs nécessitera l'accord de tous les nœuds validateurs. Je parlerai plus en détail des validateurs, des équipes de travail et d'autres rôles des nœuds dans le prochain article.

Une blockchain pour les gouverner tous

Ci-dessus, de nombreuses informations sur les différents types de blockchains, qui doivent également être stockées quelque part. En particulier, il s'agit des informations suivantes :

• sur le nombre et les configurations des workchains ;
• sur le nombre de shardchains et leurs préfixes ;
• sur les nœuds actuellement responsables de quels shardchains ;
• les hachages des derniers blocs ajoutés à tous les shardchains.

Comme vous l'avez déjà deviné, toutes ces choses sont enregistrées dans une autre blockchain de stockage — masterchain (masterchain, blockchain maître). Grâce à la présence de hachages dans ses blocs provenant de tous les shardchains, il rend le système fortement interlié. Cela signifie également que la génération d'un nouveau bloc dans le masterchain se produira immédiatement après la génération de blocs dans les shardchains - on s'attend à ce que des blocs dans les shardchains apparaissent presque simultanément environ toutes les 5 secondes, et qu'un nouveau bloc dans le masterchain apparaisse une seconde après cela.

Mais qui sera responsable de la mise en œuvre de tout ce travail titanesque - du transfert de messages, de l'exécution des contrats intelligents, de la formation des blocs dans les shardchains et le masterchain, tout en vérifiant les blocs pour des erreurs ? Est-ce que tout cela sera fait en cachette par les téléphones de millions d'utilisateurs ayant installé le client Telegram ? Ou bien, peut-être, l'équipe Durov abandonnera-t-elle les idées de décentralisation et ce seront leurs serveurs qui le feront à l'ancienne ?

En réalité, ni l'un ni l'autre de ces réponses n'est correct. Mais l'espace de cet article touche rapidement à sa fin, donc la discussion sur les différents rôles des nœuds (vous avez peut-être déjà remarqué certaines mentions à leur sujet), ainsi que sur les mécanismes de leur fonctionnement se poursuivra dans la prochaine partie.

Source : habr.com