Ce texte fait suite à une série d'articles dans lesquels j'examine la structure du réseau (vraisemblablement) distribué Telegram Open Network (TON), dont la sortie est en cours de préparation cette année. DANS J'ai décrit son niveau le plus élémentaire : la façon dont les nœuds interagissent les uns avec les autres.
Juste au cas où, permettez-moi de vous rappeler que je n'ai rien à voir avec le développement de ce réseau et que tout le matériel a été glané à partir d'une source ouverte (bien que non vérifiée) - (il y a aussi un accompagnement , en retraçant brièvement les principaux points), paru à la fin de l'année dernière. La quantité d'informations contenues dans ce document, à mon avis, indique son authenticité, bien qu'il n'y ait aucune confirmation officielle à ce sujet.
Aujourd'hui, nous examinerons le composant principal de TON - la blockchain.
Concepts de base
Considération (Compte). Un ensemble de données identifiées par un nombre de 256 bits identifiant de compte (le plus souvent il s'agit de la clé publique du titulaire du compte). Dans le cas de base (voir ci-dessous chaîne de travail zéro), ces données se réfèrent au solde de l'utilisateur. Spécifique « Occuper » identifiant de compte tout le monde peut le faire, mais sa valeur ne peut être modifiée que selon certaines règles.
Contrat intelligent (contrat intelligent). Il s’agit essentiellement d’un cas particulier de compte, complété par le code du contrat intelligent et le stockage de ses variables. Si dans le cas d'un « portefeuille » vous pouvez y déposer et retirer de l'argent selon des règles relativement simples et prédéterminées, alors dans le cas d'un contrat intelligent, ces règles sont écrites sous la forme de son code (dans un certain Turing-complete langage de programmation).
État de la blockchain (état de la blockchain). L'ensemble des états de tous les comptes/contrats intelligents (au sens abstrait, une table de hachage, où les clés sont des identifiants de compte et les valeurs sont les données stockées dans les comptes).
Post (message). Ci-dessus, j'ai utilisé l'expression « argent de crédit et de débit » - c'est un exemple particulier de message (« transfert N grammes du compte compte_1 par compte compte_2"). Évidemment, seul le nœud propriétaire de la clé privée du compte peut envoyer un tel message compte_1 - et capable de le confirmer par une signature. Le résultat de la livraison de tels messages sur un compte régulier est une augmentation de son solde, et le résultat du contrat intelligent est l'exécution de son code (qui traitera la réception du message). Bien entendu, d’autres messages sont également possibles (transfert non pas de montants monétaires, mais de données arbitraires entre contrats intelligents).
Transaction (transaction). Le fait qu’un message soit délivré s’appelle une transaction. Les transactions changent l'état de la blockchain. Ce sont les transactions (enregistrements de livraison de messages) qui constituent les blocs de la blockchain. À cet égard, vous pouvez considérer l'état de la blockchain comme une base de données incrémentielle : tous les blocs sont des « diffs » qui doivent être appliqués séquentiellement pour obtenir l'état actuel de la base de données. Les détails de l'empaquetage de ces « diffs » (et de la restauration de l'état complet à partir d'eux) seront abordés dans le prochain article.
Blockchain dans TON : qu’est-ce que c’est et pourquoi ?
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 un hachage du précédent. Les commentaires posaient la question : pourquoi avons-nous besoin d'une telle structure de données alors que nous avons déjà une DHT - une table de hachage distribuée ? Bien évidemment, certaines données peuvent être stockées en DHT, mais cela ne convient que pour des informations pas trop « sensibles ». Les soldes de crypto-monnaie ne peuvent pas être stockés dans DHT - principalement en raison du manque de contrôles sur intégrité. En fait, toute la complexité de la structure de la blockchain augmente afin d'éviter toute interférence avec les données qui y sont stockées.
Cependant, la blockchain dans TON semble encore plus complexe que dans la plupart des autres systèmes distribués – et pour deux raisons. Le premier est le désir de minimiser le besoin de fourchettes. Dans les crypto-monnaies traditionnelles, tous les paramètres sont définis au stade initial et toute tentative de les modifier conduit en fait à l’émergence d’un « univers alternatif de crypto-monnaie ». La deuxième raison est la prise en charge de l'écrasement (fragmentation, fragmentation) blockchain. La blockchain est une structure qui ne peut pas diminuer avec le temps ; et généralement chaque nœud responsable du fonctionnement du réseau est obligé de le stocker complètement. Dans les systèmes traditionnels (centralisés), le partitionnement est utilisé pour résoudre de tels problèmes : certains enregistrements de la base de données sont situés sur un serveur, d'autres sur un autre, etc. Dans le cas des crypto-monnaies, une telle fonctionnalité est encore assez rare, notamment en raison du fait qu'il est difficile d'ajouter du sharding à un système là où cela n'était pas initialement prévu.
Comment TON envisage-t-il de résoudre les deux problèmes ci-dessus ?
Contenu blockchain. Chaînes de travail.
Tout d’abord, parlons de ce qui est prévu pour être stocké dans la blockchain. Les états des comptes (« portefeuilles » dans le cas de base) et des contrats intelligents y seront stockés (pour plus de simplicité, nous supposerons que c'est la même chose que les comptes). Essentiellement, ce sera une table de hachage ordinaire - les clés qu'elle contient seront des identifiants identifiant de compte, et les valeurs sont des structures de données contenant des éléments tels que :
- équilibre;
- code de contrat intelligent (uniquement pour les contrats intelligents) ;
- stockage de données de contrats intelligents (pour les contrats intelligents uniquement) ;
- statistiques;
- (facultatif) clé publique pour les transferts depuis le compte, par défaut account_id ;
- file d'attente des messages sortants (ici ils sont saisis pour être transmis au destinataire) ;
- une liste des derniers messages envoyés à ce compte.
Comme mentionné ci-dessus, les blocs eux-mêmes sont constitués de transactions - des messages envoyés à divers comptes account_id. Cependant, en plus de account_id, les messages contiennent également un champ de 32 bits ID_chaîne de travail — ce qu'on appelle l'identifiant chaîne de travail (chaîne de travail, blockchain fonctionnelle). Cela permet d’avoir plusieurs blockchains indépendantes les unes des autres avec des configurations différentes. Dans ce cas, workchain_id = 0 est considéré comme un cas particulier, chaîne de travail zéro — ce sont les soldes qu'il contient qui correspondront à la crypto-monnaie TON (Grams). Très probablement, au début, d’autres chaînes de travail n’existeront pas du tout.
Chaînes de fragments. Paradigme de partage infini.
Mais la croissance du nombre de blockchains ne s’arrête pas là. Parlons du partitionnement. Imaginons que chaque compte (account_id) se voit attribuer sa propre blockchain - elle contient tous les messages qui lui parviennent - et que les états de toutes ces blockchains sont stockés sur des nœuds séparés.
Bien sûr, c'est un gaspillage considérable : très probablement, dans chacun de ces chaînes de fragments (chaîne de fragments, blockchain de fragments) les transactions arriveront très rarement, et de nombreux nœuds puissants seront nécessaires (pour l'avenir, je constate que nous ne parlons pas seulement de clients sur téléphones mobiles - mais de serveurs sérieux).
Par conséquent, les shardchains combinent les comptes par les préfixes binaires de leurs identifiants : si une shardchain a un préfixe de 0110, alors elle inclura les transactions de tous les account_ids qui commencent par ces nombres. Ce préfixe_shard peut avoir une longueur de 0 à 60 bits - et l'essentiel est qu'elle puisse changer dynamiquement.
Dès qu'une des chaînes de fragments commence à recevoir trop de transactions, les nœuds qui y travaillent, selon des règles prédéterminées, la « divisent » en deux enfants - leurs préfixes seront un peu plus longs (et pour l'un d'eux, ce bit sera égal à 0, et pour l'autre - 1). Par exemple, préfixe_shard = 0110b se divisera en 01100b et 01101b. À leur tour, si deux chaînes de fragments « voisines » commencent à se sentir suffisamment à l’aise (pendant un certain temps), elles fusionneront à nouveau.
Ainsi, le partitionnement se fait « de bas en haut » - nous supposons que chaque compte a son propre fragment, mais pour le moment, ils sont « collés ensemble » par des préfixes. C'est ce que cela signifie Paradigme de partage infini (paradigme de partage infini).
Par ailleurs, je voudrais souligner que les chaînes de travail n'existent que virtuellement - en fait, ID_chaîne de travail cela fait partie de l'identifiant d'une chaîne de fragments spécifique. En termes formels, chaque shardchain est défini par une paire de nombres (ID_chaîne de travail, préfixe_shard).
Correction des erreurs. Blockchains verticales.
Traditionnellement, toute transaction sur une blockchain est considérée comme « gravée dans le marbre ». Cependant, dans le cas de TON, il est possible de « réécrire l’histoire » - au cas où quelqu’un (le soi-disant. noeud de pêcheur) prouvera que l'un des blocs a été signé de manière incorrecte. Dans ce cas, un bloc de correction spécial est ajouté à la shardchain correspondante, contenant le hachage du bloc lui-même en cours de correction (et non le dernier bloc de la shardchain). En considérant la shardchain comme une chaîne de blocs disposés horizontalement, nous pouvons dire que le bloc correcteur est attaché au bloc erroné non pas à droite, mais par le haut - on considère donc qu'il fait partie d'une petite « blockchain verticale ». . Ainsi, nous pouvons dire que les shardchains sont blockchains bidimensionnelles.
Si, après un bloc erroné, les modifications apportées par celui-ci ont été référencées par les blocs suivants (c'est-à-dire que de nouvelles transactions ont été effectuées sur la base de transactions invalides), des transactions correctives sont également ajoutées à ces blocs « par-dessus ». Si les blocages n’ont pas affecté les informations « concernées », ces « vagues correctives » ne s’appliquent pas à celles-ci. Par exemple, dans l'illustration ci-dessus, la transaction du premier bloc, augmentant le solde du compte C, a été reconnue comme incorrecte - par conséquent, la transaction diminuant le solde de ce compte dans le troisième bloc doit également être annulée, et un bloc correctif doit être validé au-dessus du bloc lui-même.
Il convient de noter que bien que les blocs correctifs soient représentés comme étant situés « au-dessus » de ceux d’origine, ils seront en fait ajoutés à la fin de la blockchain correspondante (là où ils devraient se trouver chronologiquement). La localisation bidimensionnelle montre uniquement à quel point de la blockchain ils seront « liés » (via le hachage du bloc d'origine qui s'y trouve).
Vous pouvez philosopher séparément sur la qualité de la décision de « changer le passé ». Il semblerait que si nous admettons la possibilité qu'un bloc incorrect apparaisse dans la shardchain, alors nous ne pouvons pas éviter la possibilité qu'un bloc correctif erroné apparaisse. Ici, autant que je sache, la différence réside dans le nombre de nœuds qui doivent parvenir à un consensus sur les nouveaux blocs – il y aura un nombre relativement restreint de personnes travaillant sur chaque shardchain. »groupe de travail» nœuds (qui change assez souvent de composition), et l'introduction de blocs correctifs nécessitera l'accord de chacun nœuds de validation. Je parlerai davantage des validateurs, des groupes de travail et d'autres rôles de nœuds dans le prochain article.
Une blockchain pour les gouverner tous
Il existe de nombreuses informations répertoriées ci-dessus sur les différents types de blockchains, qui elles-mêmes devraient également être stockées quelque part. Il s'agit notamment des informations suivantes :
- sur le nombre et les configurations des chaînes de travail ;
- sur le nombre de shardchains et leurs préfixes ;
- quels nœuds sont actuellement responsables de quelles chaînes de fragments ;
- hachages des derniers blocs ajoutés à toutes les chaînes de fragments.
Comme vous l'avez peut-être deviné, toutes ces choses sont enregistrées dans un autre stockage blockchain - chaîne principale (chaîne maîtresse, blockchain maître). En raison de la présence de hachages de blocs de toutes les chaînes de fragments dans ses blocs, cela rend le système hautement connecté. Cela signifie, entre autres, que la génération d'un nouveau bloc dans la masterchain aura lieu immédiatement après la génération des blocs dans les shardchains - on s'attend à ce que les blocs dans les shardchains apparaissent presque simultanément toutes les 5 secondes environ, et le bloc suivant dans le masterchain - une seconde après.
Mais qui sera responsable de la mise en œuvre de tout ce travail titanesque - pour l'envoi de messages, l'exécution de contrats intelligents, la formation de blocs dans les shardchains et la masterchain, et même la vérification des erreurs dans les blocs ? Tout cela sera-t-il fait secrètement par les téléphones de millions d’utilisateurs sur lesquels le client Telegram est installé ? Ou peut-être que l'équipe Durov abandonnera les idées de décentralisation et que ses serveurs le feront à l'ancienne ?
En fait, ni l’une ni l’autre réponse n’est correcte. Mais les marges de cet article s'épuisent rapidement, nous parlerons donc des différents rôles des nœuds (vous avez peut-être déjà remarqué des mentions de certains d'entre eux), ainsi que de la mécanique de leur travail, dans la partie suivante.
Source: habr.com