TON : Telegram Open Network. Partie 1 : Introduction, niveau réseau, ADNL, DHT, réseaux superposés

Depuis deux semaines, Runet parle de Telegram et de la situation concernant son blocage absurde et impitoyable par Roskomnadzor. Cela a touché beaucoup de gens en ricochet, mais tout cela constitue des sujets pour des publications sur Geektimes. Ce qui m'a surpris, c'est que je n'ai toujours pas vu sur Habr une seule analyse du réseau TON — Telegram Open Network, qui est prévu sur la base de Telegram. J'ai voulu pallier ce manque, car il y a beaucoup à étudier là-bas — même sans déclarations officielles à son sujet.

Je rappelle que des rumeurs circulent selon lesquelles Telegram aurait lancé un ICO fermé de grande envergure, ayant déjà rassemblé des sommes incroyables. On suppose que dès cette année, une cryptomonnaie nommée Gram sera lancée — et chaque utilisateur de Telegram aura automatiquement un portefeuille, ce qui crée en soi un avantage considérable par rapport aux autres cryptomonnaies.

Malheureusement, comme il n'y a pas de déclarations officielles, je ne peux me baser que sur un document d'origine inconnue, ce dont je vous avertis tout de suite. Bien sûr, il pourrait s'agir d'un faux très habile, mais il se peut également que ce soit un véritable livre blanc du futur système, écrit par Nikolai Durov (et probablement divulgué par quelqu'un des investisseurs). Mais même si c'est un faux, personne ne nous interdira de l'étudier et d'en discuter, n'est-ce pas ?

Que dit ce document ? Je vais essayer de le résumer avec mes propres mots, fidèlement au texte, mais en français et de manière un peu plus humaine (que Nikolai me pardonne pour sa tendance à s'égarer dans les mathématiques formelles). Gardez à l'esprit que même en cas d'authenticité, il s'agit d'une description préliminaire du système, et il est très probable qu'elle change d'ici au lancement public.

Nous découvrons qu'en plus de la cryptomonnaie, il est prévu encore beaucoup, beaucoup d'autres choses. Détaillons cela dans l'ordre.

• TON Blockchain. C'est la base du système entier. Si vous ne savez absolument pas ce qu'est un blockchain , je vous recommande de vous renseigner, car il y aura de nombreux blockchains ici. Imbriqués les uns dans les autres, virtuellement fragmentés et même des blockchains « verticaux » à l'intérieur des blocs d'autres blockchains. Et il y aura aussi plusieurs termes qui sonnent bien, comme Instant Hypercube Routing et Infinite Sharding Paradigm, mais nous en reparlerons plus tard. Et bien sûr, la preuve d'enjeu et les contrats intelligents.
• TON P2P Network. Un réseau pair-à-pair, sur la base duquel le fonctionnement du système sera construit. C'est de cela qu'il sera principalement question dans cette partie de la narration.
• Stockage TON. Un stockage de fichiers qui sera construit indépendamment de la blockchain sur le réseau peer-to-peer mentionné ci-dessus. On peut le comparer aux torrents.
• Proxy TON. C'est un service dont le but est d'augmenter l'anonymat des participants au réseau. Tout paquet peut être envoyé non pas directement, mais par des tunnels intermédiaires avec un chiffrement supplémentaire — similaire à I2P ou TOR.
• DHT TON. Une table de hachage distribuée pour stocker des valeurs arbitraires. Elle est également construite au-dessus de Réseau TON (mais l'utilise également) et aide Stockage TON à trouver des nœuds « partageurs », et Proxy TON — des relais intermédiaires. Cependant, il convient de noter qu'à la différence de la blockchain, cette table de hachage n'est pas un espace de stockage sécurisé — il ne faut pas y conserver d'informations importantes.
• Services TON. Une plateforme pour des services variés. En fait, c'est un nouvel internet par-dessus tout ce qui a été décrit précédemment. L'échange de données se fait par Réseau TON/Proxy TON, et la logique réside dans les smart contracts eux-mêmes TON Blockchain. Et l'interface avec des URL assez familières.
• DNS TON. Puisqu'il s'agit des URL familières, il faut également un convertisseur de celles-ci en adresses de 256 bits — comptes, contrats, services et nœuds.
• Paiements TON. Et c'est ici que la question monétaire entre en jeu. Ce ne sera pas seulement gram — comme avec l'Ethereum, tous les « tokens » seront possibles ; les grams ne seront qu'une monnaie « par défaut ».

C'est la première partie décrivant le niveau « terrestre » du TON — sa partie réseau, construite au-dessus de protocoles traditionnels. La prochaine partie traitera de la « chair » — blockchain qui sera soutenue par le système décrit ci-dessous. Ainsi, mon ordre de récit diffère quelque peu de celui utilisé dans le document mentionné ci-dessus (qui commence directement par le niveau abstrait).

Concepts de base

TL (Type Language). C'est un format binaire abstrait pour des structures de données arbitraires. Il est utilisé dans le protocole de Telegram et sera activement utilisé dans le TON. Si vous voulez vous familiariser avec lui en détail — voici sa description.

Hachage (hash). Une fonction qui produit une transformation irréversible d'une structure de données arbitraire en un numéro unique de longueur fixe. Dans la documentation, on parle beaucoup de la fonction SHA-256.

Nœud du réseau (node). Un nœud est un logiciel qui assurera le fonctionnement du système. En particulier, il est prévu que chaque application cliente de Telegram intègre un nœud de TON. À un niveau bas, les nœuds ont des adresses IPv4/IPv6 et communiquent via le protocole UDP, à un niveau plus élevé, ils possèdent des adresses abstraites et mettent en œuvre le protocole ADNL (pour plus d'informations sur les adresses abstraites et ADNL, voir ci-dessous). Lorsque l'on parle de certaines parties du système effectuant des actions ou stockant des données, cela signifie que ce sont les nœuds du réseau qui le font.

Adresse abstraite (ou simplement adresse, address). L'adresse d'un nœud est déterminée par sa clé publique. Plus strictement, il s'agit d'un hachage de 256 bits (SHA256) de la structure de données contenant la clé publique (l'algorithme cryptographique spécifique n'est pas précisé — les courbes elliptiques et RSA-2048 sont citées comme exemples). Pour qu'un nœud puisse interagir avec un autre, il doit connaître non seulement l'adresse de celui-ci, mais aussi cette structure de données. Théoriquement, un nœud physique peut créer un nombre illimité d'adresses (correspondant à différentes clés).

Ensuite, une telle association est souvent utilisée : une « pré-image » sous forme de structure TL (contenant pratiquement toutes les données), et un hachage de 256 bits de celle-ci, utilisé pour l'adressage.

Blockchain (blockchain). La blockchain est une structure de données dont les éléments (blocs) sont ordonnés en une « chaîne », chaque bloc suivant de la chaîne contenant le hachage du précédent. Cela assure l'intégrité — les modifications ne peuvent être effectuées que par l'ajout de nouveaux blocs.

Service (service). Les services dans le cadre de TON peuvent être de différents types, en fonction de leur utilisation ou non de la blockchain. Par exemple, un (ou plusieurs) nœud du réseau peut traiter certaines demandes RPC via le protocole ADNL décrit ci-dessous, sans créer de nouvelles entrées dans la blockchain — comme des serveurs web traditionnels. Il est également envisagé de mettre en œuvre HTTP sur ADNL, ainsi que de faire passer le messager lui-même à ce protocole. À l'instar de TOR ou I2P, cela le rendra plus résistant à diverses censures.

Dans le même temps, plusieurs services impliquent à la fois l'interaction avec la blockchain et le traitement des requêtes en dehors de celle-ci. Par exemple, pour TON Storage — un stockage de fichiers — il n'est pas très judicieux de stocker les fichiers eux-mêmes dans la blockchain. Seuls les hachages des fichiers (ainsi que certaines métainformations à leur sujet) seront contenus, et des nœuds spécialisés du réseau agiront en tant que « serveurs de fichiers » prêts à les fournir à d'autres nœuds via ADNL.

Service brouillard (fog service). Il s'agit de certains services qui supposent la décentralisation et la participation ouverte. Par exemple, TON Proxy est un service qui peut être soutenu par tout participant souhaitant fournir son nœud en tant qu'intermédiaire (proxy) pour transmettre des paquets entre d'autres nœuds. S'il le désire, il peut exiger un tarif qu'il a fixé — en utilisant le système TON Payments pour les micropaiements (qui, à son tour, est également un service de brouillard).

ADNL : Abstract Datagram Network Layer

Au niveau le plus bas, l'interaction entre les nœuds se fera via le protocole UDP (bien que d'autres options soient acceptables).

Comme mentionné ci-dessus, afin qu'un nœud puisse envoyer un paquet à un autre, il doit connaître l'une de ses clés publiques (et, par conséquent, l'adresse qui lui est associée). Il chiffre le paquet avec cette clé et ajoute au début du paquet une adresse de 256 bits du destinataire — puisque chaque nœud peut avoir plusieurs adresses de ce type, cela lui permettra de déterminer quelle clé utiliser pour le décryptage.

De plus, au lieu de l'adresse du destinataire, un identifiant peut se trouver au début du paquet de données. canal. Dans ce cas, le traitement du paquet dépendra des accords spécifiques entre les nœuds — par exemple, les données envoyées dans un certain canal peuvent être destinées à un autre nœud et doivent lui être réadressées (c'est cela le service Proxy TON). Un autre cas particulier peut être une interaction directe entre les nœuds, mais avec un cryptage selon une paire de clés individuelle pour ce canal (préalablement formées selon le protocole de Diffie-Hellman).

Enfin, un cas spécial est le canal « zéro » — si un nœud ne connaît pas encore les clés publiques de ses « voisins », il peut leur envoyer des paquets sans aucun chiffrement. Cela est prévu uniquement pour l'initialisation — une fois que les nœuds auront envoyé des informations sur leurs clés, celles-ci doivent être utilisées pour les interactions futures.

Le protocole décrit ci-dessus (256 bits d'identifiant de canal + contenu du paquet) s'appelle ADNL. La documentation mentionne la possibilité de mettre en œuvre un équivalent de TCP au-dessus de celui-ci ou une superstructure propre — RLDP (Reliable Large Datagram Protocol), mais ne donne pas de détails sur leur mise en œuvre.

TON DHT : Table de hachage distribuée

Comme dans d'autres systèmes distribués, TON prévoit la mise en œuvre d'une DHT — table de hachage distribuée. Plus précisément — la table est de type Kademlia.Si vous n'êtes pas familiarisé avec ce type de tables de hachage — ne vous inquiétez pas, je vais expliquer brièvement comment elles fonctionnent.

Au sens abstrait, la DHT associe des clés de 256 bits à certaines valeurs binaires de longueur arbitraire. Les clés dans la table sont des hachages d'une structure TL définie (ces structures elles-mêmes sont également stockées avec la DHT). Cela ressemble beaucoup à la formation des adresses des nœuds — et elles peuvent effectivement apparaître dans la DHT (par exemple, une adresse IP d'un nœud correspondant à une adresse abstraite, si elle ne la masque pas). Mais dans l'ensemble, les « prototypes de clés » (leurs des descriptions, descriptions de clés) sont des métadonnées qui pointent vers le « propriétaire » de l'enregistrement dans la table de hachage (c'est-à-dire la clé publique d'un nœud quelconque), le type de valeur stockée et les règles selon lesquelles cet enregistrement peut ensuite être modifié. Par exemple, une règle peut autoriser la modification de la valeur uniquement par le propriétaire — ou interdire de réduire la valeur (pour se protéger des attaques par répétition).

En plus des clés de 256 bits, le concept d'adresses DHT est introduit. La différence avec les adresses de nœuds classiques est que l'adresse DHT est toujours liée à une adresse IP. Si un nœud ne cache pas son IP, il peut utiliser une adresse classique pour la DHT. Cependant, plus souvent pour les besoins de la DHT, une adresse distincte, « semi-permanente », sera créée.

Un concept de distance est introduit pour les clés et les adresses DHT — tout cela est conforme aux tables. Kademlia La distance entre les clés est égale au XOR (OU exclusif Bit à Bit) de celles-ci. Comme dans les tables Kademlia, la valeur correspondante à une clé donnée doit être stockée sur s les nœuds ayant la distance la plus courte à cette clé (s ici — un nombre relativement petit).

Pour qu'un nœud DHT puisse interagir avec d'autres nœuds similaires, il maintient en mémoire une table de routage DHT — les adresses DHT et IP des nœuds avec lesquels il a interagi auparavant, regroupées par distance. Il y a 256 de ces groupes (correspondant au bit le plus significatif de la valeur de distance — c'est-à-dire que les nœuds à une distance de 0 à 255 iront dans un groupe, de 256 à 65535 dans le suivant, etc.). À l'intérieur de chaque groupe, un nombre limité de « meilleurs » nœuds (en termes de latence) est stocké.

Chaque nœud doit supporter plusieurs opérations : stockage de valeur pour une clé, recherche de nœuds et recherche de valeurs. La recherche de nœuds implique de renvoyer les nœuds les plus proches d'une clé donnée à partir de la table de routage ; la recherche de valeurs est similaire, sauf dans le cas où le nœud connaît la valeur d'une clé (il la renvoie simplement). Par conséquent, si un nœud veut trouver une valeur dans le DHT pour une clé, il envoie des requêtes à un petit nombre de nœuds les plus proches de cette clé dans sa table de routage. Si parmi leurs réponses, la valeur recherchée n’est pas trouvée, mais qu’il y a d'autres adresses de nœuds, la requête est répétée à ces derniers.

Le DHT TON peut être utilisé à diverses fins, par exemple pour mettre en œuvre un stockage de fichiers similaire au torrent (voir Stockage TON); pour déterminer les adresses des nœuds mettant en œuvre certains services ; pour stocker des informations sur les propriétaires de comptes dans la blockchain. Mais l'application la plus importante est la découverte de nœuds par leurs adresses abstraites. Pour cela, l'adresse est utilisée comme clé, et la valeur à trouver est nécessaire. À la suite d'une requête, soit le nœud lui-même sera trouvé (si l'adresse recherchée était son adresse DHT semi-permanente), soit la valeur sera une adresse IP et un port pour la connexion — ou une autre adresse à utiliser comme tunnel intermédiaire.

Les réseaux superposés dans TON

Le protocole ADNL décrit ci-dessus permet à n'importe quel nœud d'échanger des informations avec les autres — certes, pas nécessairement par les chemins les plus optimaux. On peut dire qu'avec ADNL, tous les nœuds forment un graphe global TON (idéalement — connexe). Mais il est également prévu de créer des réseaux superposés — des sous-graphes à l'intérieur de ce graphe.

À l'intérieur de ce réseau, l'interaction se fait uniquement directement — à travers des connexions préalablement établies entre les nœuds participants du réseau (via les canaux ADNL décrits ci-dessus). La formation de ces connexions entre voisins et la recherche de ces voisins est un processus automatique qui vise à maintenir la connectivité du réseau superposé et à minimiser les latences lors des échanges de données.

De plus, un moyen est prévu pour diffuser rapidement de grandes mises à jour en mode broadcast à l'intérieur du réseau — elles sont découpées en morceaux, complétées par un code de correction d'erreurs, et toutes ces parties sont transmises d'un participant à un autre. Ainsi, un participant n'a pas besoin de recevoir toutes les parties en entier avant de les transmettre plus loin dans le réseau.

Les réseaux superposés peuvent être publics ou privés. Devenir participant d'un réseau public n'est pas difficile — il suffit de trouver une structure TL la décrivant (elle peut être publique — ou accessible par une certaine clé dans le DHT). Dans le cas d'un réseau privé, cette structure doit être connue du nœud à l'avance.

La suite à suivre

J'ai décidé de diviser la présentation de TON en plusieurs articles. Cette partie se termine ici, et dans le suivant, je passe à l'examen de la structure de la blockchain (plus précisément, des blockchains) qui composera TON.

Source : habr.com