<\/a><\/noindex><\/p>\nConcepts de base<\/h3>\n <\/p>\n
Compte<\/strong> (account<\/em>). Un ensemble de donn\u00e9es identifiable par un nombre de 256 bits account_id<\/em> (il s'agit le plus souvent de la cl\u00e9 publique du propri\u00e9taire du compte). Dans le cas de base (voir ci-dessous blockchain z\u00e9ro<\/em>), ces donn\u00e9es d\u00e9signent le solde de l'utilisateur. \u00ab Emprunter \u00bb un montant sp\u00e9cifique account_id<\/em> peut \u00eatre fait par n'importe qui, mais sa valeur ne peut \u00eatre modifi\u00e9e que selon des r\u00e8gles d\u00e9finies.<\/p>\n<\/p>\n
Contrat intelligent<\/strong> (smart-contract<\/em>). En somme, c'est un cas particulier de compte, compl\u00e9t\u00e9 par le code du contrat intelligent et le stockage de ses variables. Dans le cas d'un \u00ab portefeuille \u00bb, on peut d\u00e9poser et retirer de l'argent selon des r\u00e8gles relativement simples et pr\u00e9d\u00e9finies, alors que pour un contrat intelligent, ces r\u00e8gles sont \u00e9crites sous forme de code (dans un langage de programmation Turing-complet).<\/p>\n<\/p>\n
\u00c9tat de la blockchain<\/strong> (state of blockchain<\/em>). L'ensemble des \u00e9tats de tous les comptes \/ contrats intelligents (de mani\u00e8re abstraite \u2014 une table de hachage o\u00f9 les cl\u00e9s sont les identifiants des comptes et les valeurs sont les donn\u00e9es stock\u00e9es dans les comptes).<\/p>\n<\/p>\n
Message<\/strong> (message<\/em>). J'ai utilis\u00e9 l'expression \u00ab d\u00e9poser et retirer de l'argent \u00bb \u2014 c'est un exemple particulier de message (\u00ab transf\u00e9rer N grammes<\/em> du compte account_1<\/em> au compte account_2<\/em>\u00bb). \u00c9videmment, seul un n\u0153ud poss\u00e9dant la cl\u00e9 secr\u00e8te du compte peut envoyer un tel message. account_1<\/em> \u2014 et capable de le confirmer par une signature. La livraison de tels messages \u00e0 un compte ordinaire entra\u00eene l'augmentation de son solde, tandis que le contrat intelligent ex\u00e9cute son code (qui traitera la r\u00e9ception du message). Bien s\u00fbr, d'autres messages peuvent exister (transportant non des sommes d'argent, mais des donn\u00e9es arbitraires entre des contrats intelligents).<\/p>\n<\/p>\n
La transaction<\/strong> (transaction<\/em>). Le fait de livrer un message est appel\u00e9 transaction. Les transactions modifient l'\u00e9tat 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'\u00e9tat de la blockchain comme une base de donn\u00e9es incr\u00e9mentielle \u2014 tous les blocs sont des \u00ab diffs \u00bb qui doivent \u00eatre appliqu\u00e9s successivement pour obtenir l'\u00e9tat actuel de la BDD. Nous parlerons des sp\u00e9cificit\u00e9s de l'emballage de ces \u00ab diffs \u00bb (et de la restauration de l'\u00e9tat complet \u00e0 partir d'eux) dans le prochain article.<\/p>\n<\/p>\n
Blockchain dans TON : qu'est-ce que c'est et \u00e0 quoi \u00e7a sert ?<\/h3>\n <\/p>\n
Comme mentionn\u00e9 dans l'article pr\u00e9c\u00e9dent, la blockchain est une structure de donn\u00e9es, dont les \u00e9l\u00e9ments (blocs) sont ordonn\u00e9s en \u00ab cha\u00eene \u00bb, et chaque bloc suivant de la cha\u00eene contient le hachage du pr\u00e9c\u00e9dent<\/em>. Dans les commentaires, une question a \u00e9t\u00e9 pos\u00e9e : pourquoi une telle structure de donn\u00e9es est-elle n\u00e9cessaire, alors que nous avons d\u00e9j\u00e0 DHT \u2014 une table de hachage distribu\u00e9e ? Il est \u00e9vident que certaines donn\u00e9es peuvent \u00eatre stock\u00e9es dans DHT, mais cela ne convient que pour des informations qui ne sont pas trop \u00ab sensibles \u00bb. Les soldes des cryptomonnaies ne peuvent pas \u00eatre stock\u00e9s dans DHT \u2014 principalement en raison de l'absence de v\u00e9rifications sur l'int\u00e9grit\u00e9<\/em>. En fait, toute la complexit\u00e9 de la structure de la blockchain augmente pour emp\u00eacher toute interf\u00e9rence avec les donn\u00e9es qu'elle contient.<\/p>\n<\/p>\n
Cependant, la blockchain dans TON semble encore plus complexe que dans la plupart des autres syst\u00e8mes distribu\u00e9s \u2014 et il y a deux raisons \u00e0 cela. La premi\u00e8re est le d\u00e9sir de minimiser le besoin de forks<\/em>. Dans les cryptomonnaies traditionnelles, tous les param\u00e8tres sont fix\u00e9s d\u00e8s le d\u00e9part et toute tentative de les modifier conduit en fait \u00e0 l'apparition d'un \u00ab univers alternatif de cryptomonnaie \u00bb. La seconde raison est le soutien de la fragmentations (sharding<\/em>, shardization<\/em>) de la blockchain. La blockchain est une structure qui ne peut pas se r\u00e9duire au fil du temps ; en g\u00e9n\u00e9ral, chaque n\u0153ud responsable du bon fonctionnement du r\u00e9seau est oblig\u00e9 de la stocker dans son int\u00e9gralit\u00e9. Dans les syst\u00e8mes traditionnels (centralis\u00e9s), pour r\u00e9soudre de tels probl\u00e8mes, on utilise le sharding : une partie des enregistrements de la base de donn\u00e9es est sur un serveur, une autre partie est sur un autre, etc. Dans le cas des cryptomonnaies, cette fonctionnalit\u00e9 est encore assez rare \u2014 en particulier parce qu'il est compliqu\u00e9 d'ajouter le sharding \u00e0 un syst\u00e8me qui ne l'a pas pr\u00e9vu d\u00e8s le d\u00e9part.<\/p>\n<\/p>\n
Comment TON pr\u00e9voit-il de r\u00e9soudre les deux probl\u00e8mes d\u00e9crits ci-dessus ?<\/p>\n
<\/p>\n
Le contenu de la blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Tout d'abord, parlons de ce qui sera stock\u00e9 dans la blockchain. Y seront conserv\u00e9s les \u00e9tats des comptes (les \u00ab portefeuilles \u00bb dans le cas de base) et des contrats intelligents (pour simplifier, consid\u00e9rons que c'est la m\u00eame chose que des comptes). En r\u00e9alit\u00e9, ce sera une table de hachage classique \u2014 les identifiants seront les cl\u00e9s account_id<\/strong>, et les valeurs seront des structures de donn\u00e9es comprenant des \u00e9l\u00e9ments tels que :<\/p>\n<\/p>\n
\nle solde ;<\/li>\n le code du contrat intelligent (uniquement pour les contrats intelligents) ;<\/li>\n le stockage de donn\u00e9es du contrat intelligent (uniquement pour les contrats intelligents) ;<\/li>\n les statistiques ;<\/li>\n (en option<\/em>) la cl\u00e9 publique pour les transferts depuis le compte, par d\u00e9faut account_id ;<\/li>\nla queue des messages sortants (ici, ils sont enregistr\u00e9s pour \u00eatre envoy\u00e9s au destinataire) ;<\/li>\n la liste des derniers messages livr\u00e9s \u00e0 ce compte.<\/li>\n<\/ul>\n<\/p>\n
Comme mentionn\u00e9 ci-dessus, les blocs se composent directement de transactions \u2014 messages livr\u00e9s \u00e0 diff\u00e9rents comptes account_id. Cependant, outre account_id, les messages contiennent \u00e9galement un champ de 32 bits workchain_id<\/em> \u2014 l'identifiant de la soi-disant workchain<\/strong> (workchain<\/em>, working blockchain<\/em>). Cela permet d'avoir plusieurs blockchains ind\u00e9pendantes avec des configurations diff\u00e9rentes. Dans ce cas, workchain_id = 0 est consid\u00e9r\u00e9 comme un cas particulier, la workchain nulle<\/strong> \u2014 les soldes qui s'y trouvent correspondront \u00e0 la cryptomonnaie TON (Grams). Il est probable qu'au d\u00e9but, il n'y aura pas d'autres workchains.<\/p>\n<\/p>\n
Sharding des cha\u00eenes. Paradigme infini du sharding.<\/h3>\n <\/p>\n
Mais la croissance du nombre de blockchains ne s'arr\u00eate pas l\u00e0. Examinons le sharding. Imaginons que chaque compte (account_id) dispose de sa propre blockchain \u2014 toutes les messages qui lui sont destin\u00e9s y sont stock\u00e9s \u2014 et les \u00e9tats de toutes ces blockchains sont conserv\u00e9s sur des n\u0153uds s\u00e9par\u00e9s.<\/p>\n
<\/p>\n
Bien s\u00fbr, c'est assez co\u00fbteux : il est probable que dans chacun de ces shardchains<\/strong> (shardchain<\/em>, blockchain shard<\/em>) les transactions arriveront tr\u00e8s rarement et de nombreux n\u0153uds puissants seront n\u00e9cessaires (pour anticiper, je pr\u00e9cise que ce ne sont pas juste des clients sur des t\u00e9l\u00e9phones mobiles \u2014 mais de v\u00e9ritables serveurs).<\/p>\n<\/p>\n
C'est pourquoi les shardchains regroupent les comptes par pr\u00e9fixes binaires de leurs identifiants : si un shardchain a pour pr\u00e9fixe 0110, toutes les transactions des account_id qui commencent par ces chiffres y seront incluses. Ce shard_prefix<\/em> peut avoir une longueur de 0 \u00e0 60 bits \u2014 et ce qui est important, c'est qu'il peut changer dynamiquement.<\/p>\n<\/p>\n
<\/p>\n
D\u00e8s qu'un des shardchains re\u00e7oit un nombre excessif de transactions, les n\u0153uds qui y travaillent, selon des r\u00e8gles pr\u00e9d\u00e9finies, le \u00ab fendent \u00bb en deux enfants \u2014 leurs pr\u00e9fixes seront plus longs d'un bit (et pour l'un d'eux, ce bit sera \u00e9gal \u00e0 0, et pour l'autre, \u00e0 1). Par exemple, shard_prefix<\/em> = 0110<\/u>b se fendra en 0110<\/u>0b et 0110<\/u>1b. Inversement, si deux shardchains \u00ab voisins \u00bb commencent \u00e0 se sentir suffisamment \u00e0 l'aise (pendant un certain temps), ils se rejoindront \u00e0 nouveau.<\/p>\n <\/p>\n
Ainsi, le sharding s'effectue \u00ab de bas en haut \u00bb \u2014 nous supposons que chaque compte poss\u00e8de son shard, mais ils sont \u2014 pour un temps \u2014 \u00ab coll\u00e9s \u00bb par pr\u00e9fixes. C'est ce que sous-entend Infinite Sharding Paradigm<\/strong> (la paradigm du sharding infini.<\/em>).<\/p>\n<\/p>\n
Il convient de souligner que les workchains existent uniquement de mani\u00e8re virtuelle \u2014 en r\u00e9alit\u00e9, workchain_id<\/em> il s'agit d'une partie de l'identifiant d'un shardchain sp\u00e9cifique. Pour le dire de mani\u00e8re formelle, chaque shardchain est d\u00e9fini par une paire de nombres (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Correction des erreurs. Blockchains verticales.<\/h3>\n <\/p>\n
On consid\u00e8re traditionnellement que toute transaction dans une blockchain est \u00ab grav\u00e9e dans la pierre \u00bb. Cependant, dans le cas de TON, la possibilit\u00e9 de \u00ab r\u00e9\u00e9crire l'histoire \u00bb est pr\u00e9vue \u2014 dans le cas o\u00f9 quelqu'un (le fameux n\u0153ud \u00ab p\u00eacheur \u00bb<\/em>) prouvera qu'un des blocs a \u00e9t\u00e9 sign\u00e9 incorrectement. Dans ce cas, un bloc correctif sp\u00e9cial est ajout\u00e9 au shardchain correspondant, contenant le hachage du bloc corrig\u00e9 (et non du dernier bloc du shardchain). En repr\u00e9sentant le shardchain comme une cha\u00eene de blocs dispos\u00e9e horizontalement, on peut dire que le bloc correctif s'attache au bloc d\u00e9fectueux non pas \u00e0 droite, mais au-dessus \u2014 c'est pourquoi on consid\u00e8re qu'il fait partie d'une petite \u00ab cha\u00eene de blocs verticale \u00bb. Ainsi, on peut dire que les shardchains sont des blockchains bidimensionnelles<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Dans le cas o\u00f9 des blocs ult\u00e9rieurs r\u00e9f\u00e9rencent les modifications apport\u00e9es par le bloc erron\u00e9 (c'est-\u00e0-dire, des transactions valides bas\u00e9es sur des informations invalides), des blocs correctifs sont \u00e9galement ajout\u00e9s \u00ab au-dessus \u00bb de ces blocs. Si les blocs n'ont pas touch\u00e9 \u00e0 l'information \u00ab affect\u00e9e \u00bb, ces \u00ab ondes correctrices \u00bb ne se propagent pas \u00e0 eux. Par exemple, dans l'illustration ci-dessus, la transaction du premier bloc, qui augmente le solde du compte C, a \u00e9t\u00e9 reconnue comme incorrecte \u2014 donc la transaction qui diminue le solde de ce compte dans le troisi\u00e8me bloc doit aussi \u00eatre annul\u00e9e, et un bloc correctif est engag\u00e9 au-dessus du bloc lui-m\u00eame.<\/p>\n
<\/p>\n
Il convient de noter \u2014 bien que les blocs correctifs soient repr\u00e9sent\u00e9s comme situ\u00e9s \u00ab au-dessus \u00bb des originaux, en r\u00e9alit\u00e9, ils seront ajout\u00e9s \u00e0 la fin de la blockchain correspondante (l\u00e0 o\u00f9 ils devraient se trouver chronologiquement). La disposition bidimensionnelle ne montre que le point dans la blockchain auquel ils seront \u00ab attach\u00e9s \u00bb (gr\u00e2ce au hachage du bloc original qui s'y trouve).<\/p>\n
<\/p>\n
On peut r\u00e9fl\u00e9chir s\u00e9par\u00e9ment sur la question de savoir dans quelle mesure il est bon de \u00ab changer le pass\u00e9 \u00bb. Il semblerait que si nous admettons la possibilit\u00e9 de l'apparition d'un bloc incorrect dans le shardchain, nous devons \u00e9galement permettre l'\u00e9ventualit\u00e9 d'un bloc correctif erron\u00e9. Ici, autant que je puisse juger, la diff\u00e9rence r\u00e9side dans le nombre de n\u0153uds qui doivent atteindre un consensus sur les nouveaux blocs \u2014 une relativement petite \u00ab\u00e9quipe de travail<\/em>\u00bb de n\u0153uds (chang\u00e9e assez fr\u00e9quemment) travaillera sur chaque shardchain, tandis que l'ajout de blocs correctifs n\u00e9cessitera l'accord de tous les n\u0153uds validateurs<\/em>. Je parlerai plus en d\u00e9tail des validateurs, des \u00e9quipes de travail et d'autres r\u00f4les des n\u0153uds dans le prochain article.<\/p>\n<\/p>\n
Une blockchain pour les gouverner tous<\/h3>\n <\/p>\n
Ci-dessus, de nombreuses informations sur les diff\u00e9rents types de blockchains, qui doivent \u00e9galement \u00eatre stock\u00e9es quelque part. En particulier, il s'agit des informations suivantes :<\/p>\n
<\/p>\n
\nsur le nombre et les configurations des workchains ;<\/li>\n sur le nombre de shardchains et leurs pr\u00e9fixes ;<\/li>\n sur les n\u0153uds actuellement responsables de quels shardchains ;<\/li>\n les hachages des derniers blocs ajout\u00e9s \u00e0 tous les shardchains.<\/li>\n<\/ul>\n<\/p>\n
Comme vous l'avez d\u00e9j\u00e0 devin\u00e9, toutes ces choses sont enregistr\u00e9es dans une autre blockchain de stockage \u2014 masterchain<\/strong> (masterchain<\/em>, blockchain ma\u00eetre<\/em>). Gr\u00e2ce \u00e0 la pr\u00e9sence de hachages dans ses blocs provenant de tous les shardchains, il rend le syst\u00e8me fortement interli\u00e9. Cela signifie \u00e9galement que la g\u00e9n\u00e9ration d'un nouveau bloc dans le masterchain se produira imm\u00e9diatement apr\u00e8s la g\u00e9n\u00e9ration de blocs dans les shardchains - on s'attend \u00e0 ce que des blocs dans les shardchains apparaissent presque simultan\u00e9ment environ toutes les 5 secondes, et qu'un nouveau bloc dans le masterchain apparaisse une seconde apr\u00e8s cela.<\/p>\n<\/p>\n
Mais qui sera responsable de la mise en \u0153uvre de tout ce travail titanesque - du transfert de messages, de l'ex\u00e9cution des contrats intelligents, de la formation des blocs dans les shardchains et le masterchain, tout en v\u00e9rifiant les blocs pour des erreurs ? Est-ce que tout cela sera fait en cachette par les t\u00e9l\u00e9phones de millions d'utilisateurs ayant install\u00e9 le client Telegram ? Ou bien, peut-\u00eatre, l'\u00e9quipe Durov abandonnera-t-elle les id\u00e9es de d\u00e9centralisation et ce seront leurs serveurs qui le feront \u00e0 l'ancienne ?<\/p>\n
<\/p>\n
En r\u00e9alit\u00e9, ni l'un ni l'autre de ces r\u00e9ponses n'est correct. Mais l'espace de cet article touche rapidement \u00e0 sa fin, donc la discussion sur les diff\u00e9rents r\u00f4les des n\u0153uds (vous avez peut-\u00eatre d\u00e9j\u00e0 remarqu\u00e9 certaines mentions \u00e0 leur sujet), ainsi que sur les m\u00e9canismes de leur fonctionnement se poursuivra dans la prochaine partie.<\/p>\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"TON](\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\")
<\/p>\n