Au cours des derniers mois, toute l'attention de la communauté mondiale de la blockchain a été rivée au lancement de l'un des plus grands projets de crypto-monnaie - Telegram Open Network (TON).
À quoi ressemble vraiment la blockchain TON? Le réseau TON est-il vraiment décentralisé? Quelle est sa réelle évolutivité? Comment devenir validateur de réseau?
Les réponses à ces questions et à d'autres ont été recherchées par l'équipe du projet
Mercuryo , qui participe activement au réseau de test depuis début septembre 2019.
Le 15 novembre 2019, les services Telegram sont passés à testnet 2 et la troisième phase des tests a commencé. Notre équipe a continué à participer aux tests, devenant les premiers validateurs du réseau après TON.
Pour participer au processus de validation, l'utilisateur doit non seulement disposer d'un nombre suffisant de pièces (jetons GRAM), mais également d'un nœud de réseau complet en cours d'exécution (TON Blockchain Full Node).
Théoriquement, tout utilisateur peut devenir un validateur à la condition qu'il possède la part minimale nécessaire de l'actif (en grammes) dans la chaîne principale, mais dans la pratique, un certain nombre de questions se posent auxquelles notre équipe répondra dans cet article.
De plus, nous souhaitons partager notre expérience sur l’utilisation de
tonlib-cli , actuellement, il n'y a pratiquement aucune information documentée, contrairement à la version de base décrite en détail dans
HowTo. TON Blockchain
Le composant principal du Telegram Open Network est un système de blockchain flexible, ci-après dénommé TON Blockchain, qui, selon les développeurs eux-mêmes, est capable de traiter des millions de transactions par seconde, prenant en charge Turing Complete Smart Contracts, les spécifications officielles mises à jour de la blockchain, les transferts multidevises, ainsi que les canaux de micropaiement pour les réseaux de paiement hors chaîne (hors chaîne).
«L'architecture TON Blockchain est unique car elle possède des fonctionnalités spécifiques telles qu'un mécanisme de blockchain vertical« auto-réparateur »et un routage instantané à hypercube, qui permet à la blockchain d'être à la fois rapide et fiable. évolutive et durable. "
Comme mentionné ci-dessus,
TON Blockchain est le nom conventionnel d'un réseau décentralisé (un ensemble de chaînes de blocs) ou d'une blockchain 2D composé de trois types principaux de blockchains.
Master blockchain ou Masterchain est une chaîne unique de blocs contenant des informations générales sur le protocole et les valeurs actuelles de ses paramètres, un ensemble de validateurs et leurs partages, un ensemble de chaînes de travail actuellement actives et leurs «fragments», ainsi qu'un ensemble de hachages des derniers blocs masterchains et shardchaynov.
Blockchains de travail ou Workchains - un ensemble (jusqu'à 232) de blockchains qui sont des «chevaux de bataille» qui contiennent des transactions de transfert d'actifs et des contrats intelligents. Dans le même temps, les chaînes de travail individuelles peuvent avoir leurs propres «règles», formats d'adresse de compte, formats de transaction, diverses machines virtuelles (VM) pour les contrats intelligents, différents jetons de base ou cryptomonnaies, etc. Mais tous doivent satisfaire à certains critères de base d'interopérabilité afin d'assurer une interaction relativement simple entre eux. Ainsi, la blockchain TON est intrinsèquement hétérogène, tout comme les blockchains EOS et Polkadot.
Shard blockchains ou Shardchains - un sous-ensemble de blockchains (jusqu'à 260) au sein d'un ensemble de chaînes de travail, garantissant le fonctionnement du système de partitionnement et ayant les mêmes règles et le même format de bloc que les chaînes de travail. Les Shardchains ne contiennent qu'un sous-ensemble de comptes, en fonction des premiers bits (les plus significatifs) de l'adresse de chaque compte particulier. Étant donné que toutes les chaînes de partage ont un format et des règles communs pour les blocs de construction, la chaîne de blocs TON à cet égard est homogène et répond aux exigences décrites dans l'une des propositions de mise à l'échelle d'Ethereum.
Chaque bloc de la chaîne de partage (ainsi que la chaîne principale) n'est en fait pas seulement un bloc, mais une petite chaîne de blocs. En règle générale, cette "blockchain block" ou "blockchain verticale" se compose exactement d'un bloc, de sorte qu'elle peut être considérée comme un bloc de la blockchain "ordinaire" correspondante (ou "chaîne de blocs horizontale"). Cependant, s'il devient nécessaire de corriger des blocs incorrects, un nouveau bloc est entré dans la "chaîne verticale de blocs", contenant soit le remplacement du bloc "horizontal" existant, soit la "différence de bloc", contenant uniquement une description des parties de la version précédente du bloc qui doivent être remplacées. Ce mécanisme spécifique à TON pour remplacer les blocs non valides détectés sans avoir besoin d'un hard fork est appelé une
blockchain 2D , ou
simplement 2-blockchain.Algorithmes de consensus et mécanisme de protection du réseau
TON propose une blockchain basée sur le
paradigme de partage infini (Proof of Stake ou PoS). Selon la documentation du développeur:
«Presque toutes les implémentations de blockchains utilisant le sharding sont basées sur le modèle descendant: nous imaginons d'abord une blockchain, puis nous décidons comment la diviser en plusieurs parties interagissant les unes avec les autres (shardchains) pour augmenter l'efficacité et augmenter l'évolutivité.
L'approche de TON en matière de partage est basée sur le principe ascendant, ce qui signifie que la chaîne de blocs d'origine est extrêmement évolutive et que chaque chaîne de partage individuelle ne contient qu'un seul compte ou contrat intelligent. Au niveau suivant, nous avons un grand nombre de «chaînes de comptes», chacune décrivant les transitions entre les états d'un seul compte et s'envoyant des messages contenant des informations sur les transactions. En même temps, il n'est pas pratique d'avoir des centaines de millions de blockchains, les mises à jour (c'est-à-dire de nouveaux blocs) dans chacun d'entre eux apparaissent plutôt rarement, donc, pour leur mise en œuvre plus efficace, nous avons regroupé ces «chaînes de comptes» en «shardchains», dont chaque bloc est essentiellement est une collection de blocs de chaînes de comptes qui ont été liés à ce fragment particulier. Ainsi, les «chaînes de comptes» ne sont en fait que des blocs virtuels ou logiques au sein des «chaînes de partage» réellement existantes. Ce mécanisme met en lumière de nombreuses décisions de conception de la blockchain TON et nous l'appelons le «paradigme de partage infini».
Le réseau de consensus TON se compose de différents types de nœuds:
validateurs, nominateurs, hameçonneurs et collateurs.
Les validateurs sont des nœuds PoS et des fabricants de blocs.
Les pêcheurs surveillent le réseau de consensus afin de trouver une erreur ou d'identifier un nœud de consensus supposé malveillant, et si le phishing confirme sans ambiguïté que le nœud est tel, il reçoit une récompense sous forme de confiscation d'une partie de la part de ce validateur.
La tâche des
collateurs est de préparer des blocs de chaînes de partage et de les fournir pour validation aux nœuds PoS, pour lesquels ils reçoivent leur part de la récompense pour la création du bloc. Dans le même temps, les collecteurs sont essentiellement des participants supplémentaires au consensus, car les validateurs génèrent presque toujours des blocs par eux-mêmes.
Les proposants prêtent leurs actifs (jetons
Gramme ) aux validateurs à des fins lucratives. En fait, les candidats ne sont pas inclus dans l'infrastructure des validateurs, mais partagent seulement leur grande part initiale de l'actif entre eux en échange d'un pourcentage proportionnel de la rémunération totale. Ainsi, le régime et le montant de la rémunération que les candidats reçoivent dépendent entièrement des résultats du travail des validateurs, tandis que les candidats «votent» pour les validateurs, en leur prêtant des jetons Gram. Les nominateurs peuvent être des détenteurs de jetons individuels ou des pools qui gèrent les fonds des utilisateurs individuels de TON et agissent en même temps comme validateurs, agissant en tant que délégués par le biais du contrat intelligent TON. Dans ce cas, la rémunération totale d'un tel pool est répartie entre ses participants au prorata de leurs contributions.
Le processus de génération de nouveaux blocs se déroule comme suit: un certain nombre de validateurs sélectionne des blocs de chaîne principale (fragments) adaptés à la validation à l'aide d'un algorithme spécial, puis un plus petit sous-ensemble de validateurs est sélectionné pour chacun de ces fragments dans l'ordre déterminé de manière pseudo-aléatoire avec un intervalle d'environ tous les 1024 blocs.
Ainsi, pour chaque bloc, il existe un ensemble de validateurs sélectionnés de manière pseudo-aléatoire pour déterminer le bloc candidat qui a la priorité la plus élevée. Les validateurs et autres nœuds vérifient la validité des candidats de bloc proposés. Si le validateur signe automatiquement (non intentionnellement) un candidat invalide pour des blocs, il est alors puni de la perte d'une partie ou de la totalité de sa rémunération, ou de la suspension de sa participation à la sélection des validateurs pendant un certain temps.
Ensuite, les validateurs doivent parvenir à un consensus basé sur l'algorithme BFT (Byzantine Resiliency Protocol), similaire au
protocole pBFT ou
Honey Badger BFT . Ensuite, une fois le consensus atteint, un nouveau bloc est créé, tandis que les frais de transaction sont répartis entre les valideurs.
Il convient de noter que chaque validateur peut être sélectionné pour participer à plusieurs sous-ensembles de validateurs; par conséquent, il est supposé que tous les algorithmes de validation et de consensus sont exécutés en parallèle.
Une fois que tous les nouveaux blocs de fragments de la chaîne ont été générés ou que le délai est écoulé, un message apparaît indiquant qu'un nouveau bloc de chaîne maître a été créé, qui comprend les hachages des derniers blocs de tous les fragments en fonction du consensus pBFT de tous les valideurs.
TON Testnet: une expérience pratique dans le Telegram Open Network
L'équipe du projet
Mercuryo participe activement au réseau de test depuis septembre 2019 et, au cours de la période de test, nous avons acquis une expérience que nous aimerions partager avec vous.
Méthodes d'accès au réseau
L'interaction avec le réseau TON, d'une manière ou d'une autre, se résume à l'utilisation de spécifications TL qui décrivent comment interagir avec l'API. Les fichiers de spécifications sont disponibles
ici .
Il existe trois types d'API:
ton_api - pour interagir avec la console du moteur de validation Full Node
lite_api - pour travailler avec lite-client
tonlib - tout ce qui concerne le portefeuille est collecté ici et c'est la seule
API tonlib-cli accessible au public
Création de portefeuille
La façon la plus simple de créer un portefeuille est d'utiliser le test Gram Wallet, qui est disponible sur le site
officiel pour les systèmes d'exploitation Windows, macOS et Linux.
Il existe également plusieurs façons d'interagir via l'interface de ligne de commande: de base et en utilisant
tonlib-cli . Malheureusement, pour le moment, il n'y a pas de compatibilité entre eux.
Ici, nous ne considérerons que les outils que les développeurs TON proposent eux-mêmes. Si la version de base est documentée en détail dans
HowTo , les informations sur l'utilisation de
tonlib-cli sont pratiquement absentes.
Comme mentionné ci-dessus, dans TON, il existe 3 API pour différentes tâches. Les fonctions associées au fonctionnement du portefeuille sont responsables de
tonlib .
Pour commencer à travailler avec
tonlib-cli , en plus de l'interface de ligne de commande elle-même, vous devez disposer d'un fichier de configuration pour la connexion au serveur de réseau public TON, disponible
ici .
La connexion est effectuée par l'équipe
tonlib-cli -c ton-lite-client-test1.config.json -v 0où -v 0 est le paramètre responsable de la sortie des informations de débogage.
Liste des commandes:
Pour créer une adresse de portefeuille, utilisez la commande
genkey et une liste de phrases mnémoniques qui peuvent être nécessaires pour restaurer l'accès à l'adresse en cas de perte de la clé privée.
Liste des clés
La commande de
touches affiche une liste de clés. Pour d'autres opérations lors de l'exécution d'autres commandes, il est nécessaire d'utiliser leur numéro de série, c'est-à-dire pour la première clé, il y aura
id 0 .
Initialisation d'adresse
Après avoir créé l'adresse, elle doit être enregistrée sur le réseau. Pour ce faire, vous devez d'abord le reconstituer. Initialement, un contrat intelligent spécial a été utilisé pour cela -
testgiver , mais maintenant il est plus facile et plus pratique d'utiliser un bot spécial dans le télégramme
@test_ton_bot .
Immédiatement après le réapprovisionnement, le statut du compte est défini comme uninited_accountState et ne changera qu'après l'envoi de jetons de test GRM à partir de cette adresse.
Si vous avez déjà des jetons sur votre solde et que vous devez activer un autre portefeuille, vous pouvez utiliser la commande
transferf puis, avec la reconstitution du portefeuille, il sera initialisé.
Vous pouvez connaître l'état du portefeuille à l'aide de la commande
getstate 0.
Obtenir l'historique des transactions à l'aide de la commande
gethistory <num_of_key>où <num_of_key> est le numéro de séquence de touches
Base réseau
Comme avec la plupart des blockchains existantes, TON est basé sur des serveurs qui stockent un historique complet de toutes les blockchains qui ont jamais été créées sur le réseau.
Pour exécuter un nœud complet dans le réseau de test TON, 8 cœurs productifs, 4 à 8 Go de RAM suffisent, au moment de la rédaction, les données occupaient environ 50 Go de disque dur, mais il est préférable d'avoir une marge d'au moins 100 Go. Il convient de noter qu'il est préférable d'utiliser un lecteur SSD, car Un grand nombre d'IOPS sont nécessaires pour l'enregistrement, sinon la synchronisation avec le réseau sera très lente.
En tant qu'OS fonctionnel, il est préférable d'utiliser Ubuntu 18.04, comme la plupart des tests communautaires y sont effectués.
Guides d'installationREADME.txtFullNode-HOWTO.txtValidator-HOWTO.txtSystème de validation
Il est connu que la blockchain TON se compose de blocs shardchain et masterchain, qui sont créés et vérifiés par des nœuds désignés spéciaux appelés validateurs. Les validateurs reçoivent une récompense pour leur «travail»: maintenir la santé de la blockchain TON, tandis que les revenus sont distribués proportionnellement au sein de la communauté des validateurs.
À première vue, tout est clair, mais en pratique, un certain nombre de questions se posent à ce sujet:
- Y a-t-il une restriction de réseau sur le steak de validateur maximum?
La limite de la taille d'un partage pour un valideur peut toujours être vérifiée avec la commande
getconfig 17 , qui affichera la taille réelle des steaks autorisés:
La capture d'écran montre que la taille minimale du partage est actuellement de 10 000 GRAM. Cependant, si un validateur n'obtient pas plus de 100 000 GRAM pour un tour de scrutin, il n'a pas le droit de participer aux élections. Dans le même temps, le nombre maximal de jetons par validateur ne peut pas dépasser 10 000 000 GRAM et pour que le vote ait lieu, la taille minimale du steak total doit dépasser 1 000 000 GRAM.
- Comment les validateurs sont-ils sélectionnés?
Pour postuler à la participation au processus de validation, vous devez avoir un minimum de 10 000 GRAM. L'algorithme du processus électoral est décrit en détail dans le contrat intelligent
elector-code.fcTrès probablement, le contrat sera différent dans le réseau principal, donc la version actuelle est applicable uniquement pour le réseau de test.
Une part de 10 000 GRAM ne signifie pas que vous pouvez devenir validateur, car la réception de jetons de test pourrait être facilement automatisée par des demandes
adressées au
testeur .
À l'heure actuelle, presque tous les validateurs, lorsqu'ils participent au vote, fixent un facteur maximal d'un montant de 2,7 et un steak d'un montant de 120 000 GRAM, car il y a la plupart de ces paris, en raison de leur poids, le steak minimum monte à 120 000 / 2,7 = 45 000 GRAM (contrairement à 100 000 selon la documentation officielle). Mais même avec un steak aussi minime, vos chances sont presque nulles, car les trois meilleurs validateurs ont un facteur max de 2, ce qui élève la part minimale à 60000 GRAM, ce qui vous permet de devenir un validateur dans le testnet.
Si tous les validateurs actuels augmentaient leur facteur maximum ou réduisaient la taille du steak, alors il serait possible de devenir un validateur avec un steak minimum, étant donné que le nombre maximum de validateurs (1000 nœuds) ne serait pas dépassé.
- Si le système de validation est centralisé, alors toute la chaîne de blocs aussi?
Il n'y a pas de chèques, c'est-à-dire personne ne contrôle les validateurs de manière centralisée; les proposants eux-mêmes déterminent les risques lors du choix d'un validateur.
- Quels types d'amendes sont prévues pour les validateurs?
Il n'y a aucune information pour le moment, très probablement il y aura un mécanisme de consensus dans le document, car même les nœuds désynchronisés ont reçu des récompenses dans le testnet.
Pour créer des contrats intelligents TON, deux langages de programmation spéciaux sont utilisés:
Fift et
FunC . Si
Fift possède au moins une
documentation générale, il
est presque impossible de trouver des informations sur
FunC (même dans les
conditions d' un
concours de développement
, il est indiqué qu'elles ne peuvent être obtenues qu'en analysant son code source).
Pendant les tests, il a été possible de découvrir que la base de code
FunC n'est pas si volumineuse (par rapport à
Fift ) et vous permet de l'apprendre beaucoup plus rapidement, donc travailler avec
FunC est beaucoup plus facile qu'avec
Fift .
- Questions réelles / urgentes / ouvertes
Synchronisation lente
https://github.com/ton-blockchain/ton/issues/100Autorisations pour le moteur de validation
+0 = requêtes lite-client habituelles
+1 = requêtes complètes de statistiques sur les nœuds
+2 = requêtes complètes de modification de la configuration du code
+4 = requêtes potentiellement dangereuses (telles que l'exportation de clé privée ou la signature de chaînes arbitraires)
+8 = réservé pour les extensions futures (ne fait rien pour le moment)
- Comment faire fonctionner PIPE avec lite-client?
Par défaut, la sortie lite-client est envoyée à stderr, donc pour la traiter, vous devez d'abord rediriger la sortie de stderr vers stdout:
$ lite-client 2 >> (grep ...)
- Quelles sont les options d'accès programmatique au réseau?
https://github.com/ton-blockchain/ton/issues/76- Quelle configuration de serveur est requise pour le validateur?
L'utilisation d'un serveur biprocesseur est officiellement recommandée (au moins 8 cœurs par processeur). Le logiciel n'est pas très exigeant en RAM, donc 16 Go suffisent. Vous devez utiliser un SSD comme lecteur principal, dont la taille minimale recommandée est de 512 Go. Un disque dur de 8 To est suffisant pour stocker des données archivées.
Vous devez impérativement disposer d'une connexion Internet haut débit: avec une charge moyenne prévue de 100 Mbit / s, vous devez être capable de gérer des pics de charge jusqu'à 1 Gbit / s.
Il est recommandé d'utiliser XFS comme système de fichiers, car les informations sur chaque bloc sont stockées dans un fichier séparé. Il est connu, par exemple, que ext4 ne fonctionne pas très bien avec un grand nombre de petits fichiers et peut conduire à une situation où vous n'avez tout simplement pas d'inodes libres avec suffisamment d'espace disque.
- Comment savoir qu'un nœud est synchronisé?
Le journal terminera le message de synchronisation, ou l'utilisation de
validator-engine-console -c "getstats" unixtime et masterchainblocktime devrait être presque la même.
- Combien de validateurs peuvent être en ligne?
Getconfig 16
max_validators: 1000 max_main_validators: 100 min_validators: 5
- Comment trouver les validateurs actifs actuels?
Getconfig 34
Ensemble de validateurs getconfig 32 précédent
- Temps pour quels validateurs sont sélectionnés?
Le livre blanc indique que les validateurs sont sélectionnés pour un mois, mais dans le testnet cette fois est beaucoup moins et vous pouvez le découvrir dans la
configuration de getconfig 15.Après le redémarrage de testnet, les intervalles de temps pour les valideurs ont changé:
ConfigParam (15) = (validators_elected_for: 65536 élections_start_before: 32768 élections_end_before: 8192 enjeu_held_for: 32768)
D'où il résulte qu'un groupe de validateurs est sélectionné pendant 65536 secondes.
Validator-HOWTO . -,
getconfig 1 . .
result: [ 0 ], , timestamp, . , :
> runmethod -1:A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list
, TON - UDP TCP. , Telegram , .. IP , . TON : , . , , Telegram , , ADNL Proxy.
10 . . 159 IP-, , :
126 DIGITAL OCEAN ( TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it
IP- . , TON, -.
, Telegram Open Network WEB 3.0 , Telegram.
TON , « », . , :
- , ;
- - (Fift FunC), ;
- , ;
- telegram-, TON;
TON
(Infinite Sharding Paradigm) , , .. , , , , , , . TON , « » . , , TON .
, , TON , , « » , , , .
, , TON ( Gram). , , , TON PoS, , -.
PoS . , - , PoS , . PoS, , . , PoS , .
Grams Wallet — Gram
-
TON Grams Wallet , Telegram, - , Telegram FZ-LLC ( ).
, , , , , 18 , , , , Telegram FZ-LLC .
, , (. Linux). , (. 4, . 4.3), , Telegram Open Network:
« TON Blockchain ».
Our open source
Go-binding library, TON TONLIB.
Mercuryo Go, , -, .
https://github.com/mercuryoio/tonlib-gotonlib api , , :
- (//// );
- /gram/boc- ;
- ;
- ;
- Tongo ;
:
- . . tonlib;
- . ;
- tongo. - ;
- tl . ;
Telegram Open Network, Grams Wallet .