Le guide le plus complet de Tendermint Core

Rajarshi Mitra

5 months ago
Ultimate Guide to Tendermint
en flag
fr flag
de flag
es flag

Temps de lecture : 17 minutes

Cosmos est l'un des projets les plus prometteurs. Avec des gens comme Jae Kwon et Ethan Buchman dans leur équipe, cela a beaucoup de potentiel. À son cœur et à son âme se trouve Tendermint Core.

Ultimate Guide to Tendermint

Tendermint Core combine l'algorithme de consensus de Tendermint avec un protocole de potins p2p. Ainsi, lorsque vous mettez tout cela dans la pile logicielle, vous obtenez le Tendermint Core avec la couche d'application Cosmos-SDK.

Quoi qu'il en soit, avant d'aller plus loin, voyons pourquoi Tendermint est une telle nécessité.

Bitcoin et Blockchain

Lorsque Satoshi Nakamoto a créé Bitcoin, il a créé le tout premier système cryptographique décentralisé. La partie vraiment remarquable de cette découverte a été qu'il a pu résoudre le problème du général byzantin qui a aidé un réseau étendu (WAN) à parvenir à un consensus dans un environnement sans confiance. Bitcoin a utilisé l'algorithme de preuve de travail pour prendre soin de leur consensus.

Cela dit, la principale contribution de Bitcoin pourrait très bien être le fait qu'il a introduit le monde entier à la technologie blockchain.

Une blockchain est, dans les termes les plus simples, une série horodatée d'enregistrement immuable de données qui est gérée par un cluster d'ordinateurs ne appartenant pas à une seule entité. Chacun de ces blocs de données (c'est-à-dire bloc) est sécurisé et lié les uns aux autres en utilisant des principes cryptographiques (c'est-à-dire la chaîne).

En d'autres termes, une blockchain est une machine d'état déterministe répliquée sur des nœuds qui ne se font pas nécessairement confiance.

Par déterministe, nous entendons que si les mêmes mesures spécifiques sont prises, alors cela conduira toujours au même résultat.

Par exemple. 1 + 2 sera toujours 3.

Alors, qu'est-ce que l'état veut dire ? Regardons WRT Bitcoin et Ethereum.

Dans Bitcoin, l'état est une liste de soldes pour chaque compte, qui est une liste de sortie de transaction non dépensée (UTXO). Cet état est modifié via des transactions qui modifient le solde.

D'autre part, dans Ethereum, l'application est une machine virtuelle qui exécute des contrats intelligents. Chaque transaction passe par la machine virtuelle Ethereum et modifie l'état en fonction du contrat intelligent spécifique qui est appelé à l'intérieur.

Si vous regardez l'architecture de la technologie blockchain, alors vous aurez trois couches spécifiques :

Mise en réseau : Propagation de la transaction/information dans les nœuds

Consensus : Permet aux nœuds de prendre une décision à condition que les 2/3 des nœuds ne soient pas malveillants

Application : Responsable de la mise à jour de l'état donné un ensemble de transactions, c'est-à-dire le traitement des transactions. Compte tenu d'une transaction et d'un état, l'application renvoie un nouvel état.

Pour les repères visuels :

Problèmes avec l'architecture Blockchain actuelle

Il s'avère que construire une blockchain à partir de zéro avec toutes ces 3 couches est vraiment un travail difficile. Ainsi, de nombreux projets ont préféré construire en forçant la base de code Bitcoin. Maintenant, bien que cela économise beaucoup de temps, le fait est qu'ils sont toujours menottés par les limitations du protocole Bitcoin. Évidemment, vous ne pouvez pas exécuter de projets complexes lorsque vous utilisez un protocole bien connu pour ses problèmes de débit.

Les choses se sont beaucoup mieux passées quand Ethereum est entré en jeu. Ethereum a en fait donné aux développeurs une plate-forme qu'ils pourraient utiliser pour créer leur propre code personnalisé aka contrats et projets intelligents. Cependant, comme avec Bitcoin, Ethereum souffre également du même problème. Ils ont tous deux une architecture monolithique par opposition à modulaire.

Architecture monolithique vs Architecture modulaire

L'architecture monolithique signifie que tout est composé en une seule pièce. Lorsque le logiciel est considéré comme « monolithique », les composants sont interconnectés et interdépendants les uns avec les autres et la conception est plus autonome. Dans ce cas, l'architecture est plus étroitement couplée et les composants associés doivent être tous présents pour que le code soit exécuté ou compilé.

Bien que cela rend le système il a été créé pour plus robuste, vous ne pouvez pas vraiment en dériver et créer des codes personnalisés. Ce n'est pas le système le plus flexible. De plus, il y a un autre problème avec ce système. Si une composante du programme doit être mise à jour, l'application entière devra être retravaillée. Ce n'est pas vraiment la situation la plus idéale maintenant, n'est-ce pas ?

D'autre part, nous avons une architecture modulaire. Contrairement à Monolithic, les couches ne sont pas si liées les unes aux autres. Donc, bien qu'il ne soit pas aussi robuste, il est assez facile de mise à jour de l'ensemble de l'application en travaillant avec les différents modules séparés.

Étant donné que les modules sont si indépendants, l'architecture modulaire vous permet de réellement actualiser une section particulière sans provoquer de changements imprévus au reste du système. Les processus itératifs sont également beaucoup plus simples dans les programmes modulaires, par opposition à monolithiques.

Architecture et objectifs de Tendermint

Tendermint utilise l'architecture modulaire. Leurs objectifs sont les suivants :

Fournir les couches réseau et consensus d'une blockchain en tant que plate-forme où différentes applications décentralisées peuvent être construites

Les développeurs ont seulement besoin de s'inquiéter de la couche d'application de la blockchain, économisant toutes les heures qu'ils auraient gaspillées à travailler sur le consensus et la couche de mise en réseau aussi bien.

Tendermint inclut également le protocole de consensus Tendermint qui est l'algorithme de consensus byzantin tolérant aux pannes utilisé dans le moteur Tendermint Core

Voyons à quoi ressemblera l'architecture de Tendermint :

Ultimate Guide to Tendermint

Comme vous pouvez le voir, l'application est connectée à Tendermint Core via un protocole socket appelé APCI ou Application Blockchain Interface. Puisque Tendermint Core et l'application s'exécutant sur elle s'exécutent dans des processus UNIX distincts, ils doivent avoir une méthode pour parler les uns avec les autres. ABCI aide ces deux-là dans leur communication.

Alors, à quoi ressemble le design d'ABCI ? ABCI comprendra certains éléments de conception distincts :

#1 Protocole de message

Paires de messages de demande et de réponse

Les demandes sont faites par consensus pendant que la demande prend en charge la réponse

Il est défini en utilisant protobuf

#2 Serveur/Client

Le moteur de consensus exécute le client

L'application exécute le serveur

Il y a deux implémentations appropriées : octets bruts asynchrones et grpc

#3 Protocole Blockchain

ABCI est très orienté connexion. Les trois connexions pour Tendermint Core sont les suivantes :

Connexion Mempool : Cela vérifie si les transactions doivent être relayées avant qu'elles ne soient validées. Il ne peut utiliser que CheckTX

Connexion par consensus : Cette connexion aide à l'exécution des transactions qui ont été validées. La séquence de message est, pour chaque bloc, BeginBlock, [DelivertX,...], EndBlock, Commit

Connexion à la requête : aide à interroger l'état de l'application. Cette partie utilise uniquement la requête et les informations

Dans l'ensemble, l'objectif principal de Tendermint est de fournir aux développeurs un outil qui est non seulement pratique, mais a également un débit élevé. Voici les propriétés de Tendermint qui le rend si séduisant :

#1 Compatible Blockchain public ou privé

Différents projets ont des besoins différents. Certains projets doivent avoir un système ouvert où tout le monde peut participer et contribuer, comme Ethereum. D'autre part, nous avons des organisations comme l'industrie médicale, qui ne peuvent pas exposer leurs données à presque tout le monde. Pour eux, ils ont besoin de quelque chose comme la blockchain permise.

Ok, alors comment Tendermint peut-il aider à satisfaire ces deux besoins ? Rappelez-vous que Tendermint ne gère que le réseautage et le consensus pour la blockchain. Donc, cela aide dans le :

Propagation de la transaction entre les nœuds via le protocole potins

Aide les validateurs à s'entendre sur l'ensemble des transactions qui est ajouté à la blockchain.

Ce que cela signifie, c'est que la couche d'application est libre d'être définie de la manière que les développeurs veulent qu'elle soit définie. Il appartient aux développeurs de définir comment l'ensemble de validateurs est défini dans l'écosystème.

Les développeurs peuvent soit permettre à l'application d'avoir un système d'élection qui élit des validateurs en fonction du nombre de jetons natifs que ces validateurs ont jalonné dans l'écosystème.. aka Proof-of-Spot et créer une blockchain publique

De plus, les développeurs peuvent également créer une application qui définit un ensemble restreint de validateurs pré-approuvés qui prennent soin du consensus et des nouveaux nœuds qui entrent dans l'écosystème. Ceci est appelé preuve d'autorité et est la marque d'une blockchain autorisée ou privée.

#2 Haute Performance

Les applications réalisées via Tendermint Core peuvent s'attendre à des performances exceptionnelles. Tendermint Core a un temps de bloc de seulement 1 seconde. Il peut également gérer un volume de transactions de 10 000 transactions par seconde pour les transactions de 250 octets, tant que l'application le permet.

#3 Finalité

Qu'est-ce que la finalité ?

En termes simples, cela signifie qu'une fois qu'une certaine action a été exécutée, elle ne peut pas être reprise. Prenons donc l'exemple d'une simple transaction financière. Supposons que vous achetez des actions dans une entreprise, juste parce qu'un problème dans leur système, vous ne devriez pas perdre sur la propriété de vos actions. Comme vous pouvez l'imaginer, la finalité est très critique pour un système financier. Imaginez faire une transaction d'un million de dollars et le lendemain, cette transaction n'est plus valide à cause d'un problème.

Comme nous l'avons déjà mentionné, Bitcoin et Ethereum (jusqu'à la mise en œuvre complète de Casper FFG) n'ont pas vraiment la finalité du règlement. À l'occasion d'un hardfork ou d'une attaque de 51%, les transactions ont une chance d'être annulées.

D'autre part, Tendermint donne la finalité instantanée dans un délai d'une seconde à compter de la fin de la transaction. Les forks ne sont jamais créés dans le système, tant que moins de 2/3 des validateurs sont malveillants. Dès qu'un bloc est créé (ce qui est en moins d'une seconde), les utilisateurs peuvent être assurés que leur transaction est finalisée.

#4 Sécurité

Tendermint est sûr et oblige ses participants à être tenus responsables de leurs actions. Comme nous l'avons déjà dit, la menthe tendermint ne peut jamais être fourchue tant que moins de 2/3 des validateurs sont malveillants. Si dans certains cas, la blockchain fait une fourchette, il existe un moyen de déterminer la responsabilité. De plus, le consensus de Tendermint n'est pas seulement tolérant aux pannes, il est idéalement tolérant aux pannes byzantines

#5 Facile à utiliser

Une autre grande chose à propos de Tendermint est sa convivialité. Comme nous l'avons déjà mentionné, ils ont une architecture modulaire où la couche d'application peut être adaptée. Cela permet aux bases de code blockchain existantes d'être facilement liées à Tendermint via ABCIs. L'exemple parfait de ceci est Etheremint qui est fondamentalement la prise de code de la machine virtuelle Ethereum sur le dessus de Tendermint.

Ethermint fonctionne exactement comme Ethereum mais bénéficie également de toutes les fonctionnalités positives que nous avons énumérées ci-dessus. Tous les outils Ethereum comme Metamask et Truffle sont compatibles avec Ethermint.

#6 Évolutivité

La mise en œuvre de preuve de participation de Tendermint est beaucoup plus évolutive qu'un algorithme traditionnel de consensus de preuve de travail. La principale raison en est que les systèmes basés sur le POP ne peuvent pas faire le partage.

Le partage partitionne essentiellement horizontalement une base de données et crée des bases de données ou des fragments plus petits qui sont ensuite exécutés parallèlement par les nœuds. La raison en est qu'un bassin minier solide peut facilement prendre le contrôle d'un fragment.

Tendermint permettra la mise en œuvre de Sharding, ce qui augmentera considérablement l'évolutivité.

Protocole de consensus de Tendermint

Ok, alors regardons comment fonctionne le protocole de consensus de Tendermint. Qu'est-ce qu'un protocole de consensus ?

Voici comment Wikipédia définit la prise de décision par consensus :

« La prise de décision par consensus est un processus décisionnel de groupe dans lequel les membres du groupe élaborent et acceptent d'appuyer une décision dans le meilleur intérêt de l'ensemble. Le consensus peut être défini professionnellement comme une résolution acceptable, une résolution qui peut être appuyée, même si ce n'est pas le « favori » de chaque personne. Le « consensus » est défini par Merriam-Webster comme étant, premièrement, un accord général, et deuxièmement, une solidarité collective de croyance ou de sentiment. »

En termes plus simples, le consensus est un moyen dynamique de parvenir à un accord au sein d'un groupe. Alors que le vote se contente d'une règle majoritaire sans penser aux sentiments et au bien-être de la minorité, un consensus, d'autre part, permet de parvenir à un accord qui pourrait bénéficier à l'ensemble du groupe.

D'un point de vue plus idéaliste, le consensus peut être utilisé par un groupe de personnes dispersées dans le monde pour créer une société plus équitable et plus équitable.

Une méthode permettant de parvenir à la prise de décisions par consensus est appelée « mécanisme de consensus ».

Alors maintenant ce que nous avons défini ce qu'est un consensus, regardons quels sont les objectifs d'un mécanisme de consensus (données tirées de Wikipédia).

Recherche d'un accord : Un mécanisme de consensus devrait permettre au groupe de s'entendre autant que possible.

Collaborative : Tous les participants doivent viser à travailler ensemble pour obtenir un résultat qui accorde la priorité au meilleur intérêt du groupe.

Coopérative : Tous les participants ne devraient pas privilégier leurs propres intérêts et travailler en équipe plus que les individus.

Participation : Le mécanisme de consensus devrait être tel que chacun participe activement à l'ensemble du processus.

Inclusive : Le plus grand nombre possible de personnes devraient participer au processus de consensus. Cela ne devrait pas être comme un vote normal où les gens n'ont pas vraiment envie de voter parce qu'ils croient que leur vote n'aura pas de poids à long terme.

Égalitaire : Un groupe qui tente de parvenir à un consensus devrait être aussi égalitaire que possible. Ce que cela signifie fondamentalement que chaque vote a le même poids. Le vote d'une personne ne peut être plus important que celui d'une autre.

Maintenant que nous avons défini ce que sont les mécanismes de consensus et ce qu'ils devraient viser, nous devons penser à l'autre éléphant dans la salle.

Quels mécanismes de consensus devraient être utilisés pour une entité comme blockchain.

Avant Bitcoin, il y avait beaucoup d'itérations de systèmes de monnaie décentralisés peer-to-peer qui ont échoué parce qu'ils n'étaient pas en mesure de répondre au plus gros problème lorsqu'il s'agit de parvenir à un consensus. Ce problème est appelé « Problème général byzantin ».

Problème du général byzantin

Afin de faire quoi que ce soit dans un réseau pair à pair, tous les nœuds devraient être en mesure de parvenir à un consensus. Cependant, pour que ce système fonctionne, il met beaucoup l'accent sur les gens pour qu'ils agissent dans le meilleur intérêt de l'ensemble du réseau. Cependant, comme nous le savons déjà, les gens ne sont pas vraiment dignes de confiance lorsqu'il s'agit d'agir de manière éthique. C'est là que le problème du général byzantin entre en jeu.

Ultimate Guide to Tendermint

Imaginez cette situation.

Il y a une armée qui entoure un château bien fortifié. La seule façon de gagner est de s'ils attaquent le château ensemble en tant qu'unité. Cependant, ils sont confrontés à un gros problème. L'armée est loin l'un de l'autre et les généraux ne peuvent pas vraiment communiquer directement et coordonner l'attaque et certains généraux sont corrompus.

La seule chose qu'ils peuvent faire est d'envoyer un messager du général au général. Cependant, beaucoup de choses pourraient arriver au messager. Les généraux corrompus peuvent intercepter le messager et changer le message. Alors, que peuvent faire les généraux pour s'assurer qu'ils lancent une attaque coordonnée sans compter sur l'éthique de chaque général ? Comment peuvent-ils parvenir à un consensus sans confiance pour faire ce qui doit être fait ?

C'est le problème du général byzantin et Satoshi Nakamoto a résolu ce problème en utilisant le mécanisme de consensus de la preuve de travail (POW).

Qu'est-ce que la preuve de travail ?

Vérifions comment POW fonctionne avec le contexte de notre exemple donné ci-dessus. Supposons qu'un général veuille communiquer avec un autre général. Comment pensez-vous que ça va se passer ?

Un « nonce » est ajouté au message d'origine. Le nonce est une valeur hexadécimale aléatoire.

Ce nouveau message est ensuite haché. Supposons que les généraux conviennent à l'avance qu'ils n'enverront que des messages qui, lorsqu'ils sont hachés, commencent par 4 « 0 ».

Si le hachage ne donne pas le nombre souhaité de 0s, le nonce est modifié et le message est de nouveau haché. Ce processus se répète jusqu'à ce que le hachage souhaité soit reçu.

L'ensemble du processus prend beaucoup de temps et prend beaucoup de puissance de calcul.

Maintenant, quand ils obtiennent enfin la valeur hachée, le messager reçoit le message original et le nonce et dit de communiquer avec les autres généraux. Que se passe-t-il si quelqu'un essaie d'intercepter le message ? Tu te souviens de l'effet avalanche des fonctions de hachage ? Le message changera radicalement et comme il ne commencera plus avec le nombre requis de « 0 », les gens se rendront compte que le message a été falsifié.

Donc, pour placer les prisonniers de guerre dans le contexte de l'extraction de crypto :

Les mineurs essaient de résoudre des énigmes cryptographiques pour ajouter un bloc à la blockchain.

Le processus nécessite beaucoup d'efforts et de puissance de calcul.

Les mineurs présentent ensuite leur bloc au réseau bitcoin.

Le réseau vérifie ensuite l'authenticité du bloc en vérifiant simplement le hachage, s'il est correct, il est ajouté à la blockchain.

Donc, découvrir le nonce et le hachage requis devrait être difficile, cependant vérifier si c'est valide ou non devrait être simple. C'est l'essence même de la preuve de travail.

Maintenant, vous vous demandez probablement, pourquoi les mineurs devraient sacrifier leur temps et leurs ressources pour exploiter des bitcoins ? Eh bien, il s'avère qu'ils ont une incitation économique assez saine :

Lorsque vous découvrez un bloc, vous recevez une récompense de bloc de 12,5 bitcoins. La récompense est de moitié tous les 210 000 blocs.

Une fois que vous avez extrait un bloc, vous devenez le dictateur temporaire du bloc. Vous êtes responsable de la mise en place des transactions dans le bloc et avez donc droit à des frais de transaction.

Il n'y a qu'un nombre limité de bitcoins là-bas, 21 millions pour être exact. Qu'est-ce qui empêche ces mineurs d'extraire tous les bitcoins à la fois ?

Il s'avère que l'extraction de bitcoin devient progressivement plus difficile au fil du temps. Cette fonctionnalité est appelée « difficulté », et la difficulté de l'exploitation minière continue à augmenter à mesure que vous continuez à exploiter.

C'est pourquoi il est pratiquement impossible de nos jours pour les mineurs seuls de miner Bitcoins en utilisant uniquement leurs ordinateurs. Les mineurs ont maintenant uni leurs forces et créé des « pools miniers » pour regrouper leur puissance de calcul et les exploiter en tant que groupe. Ces pools utilisent des ASIC (Application-Specific Integrated Circuits) spécialement créés pour l'extraction de bitcoins.

Problèmes avec les prisonniers de guerre

Il y a trois problèmes principaux avec les algorithmes de validation de travail. Nous en avons déjà parlé en détail, donc nous allons simplement faire un aperçu général.

Perte d'énergie : Bitcoin mange plus de puissance que l'Irlande et la République slovaque. Cet énorme gaspillage d'énergie est l'un des principes de Bitcoin. C'est du gaspillage pour le bien du gaspillage.

Centralisation : Comme nous vous l'avons déjà dit, Bitcoin utilise des ASIC pour l'exploitation minière. Le problème est que les ASIC sont coûteux, et les pools avec plus d'argent ont tendance à avoir plus d'ASIC et, par conséquent, plus de puissance minière. En tant que tel, Bitcoin n'est pas aussi décentralisé qu'il le veut.

Évolutivité : L'architecture même des prisonniers de guerre empêche l'évolutivité. Bitcoin gère seulement 7 transactions par seconde. Pour un système financier moderne, il n'est tout simplement pas suffisant.

Entrez Tendermint

Donc, pour contrecarrer les nombreux problèmes avec le système de consensus de validation de travail, Jae Kwon, diplômée en informatique et en génie des systèmes, a créé Tendermint. Tendermint est un protocole purement basé sur BFT, construit dans un cadre sans autorisation avec le Proof-of-Spot (PO) comme mécanisme de sécurité sous-jacent.

En raison de sa complexité, Tendermint a mis près de 4 ans à être complétée.

Jae Kwon et le directeur de la Tendermint Ethan Buchman ont été inspirés par Raft et PBFT pour créer un système de consensus qui satisfaisait le problème du général byzantin. Il est

« modélisé comme un protocole déterministe, vivent sous synchrone partielle, qui atteint le débit dans les limites de la latence du réseau et des processus individuels eux-mêmes. »

Très bien, nous savons que c'est beaucoup de mots compliqués à jeter les uns après les autres, mais pour comprendre ce qu'est le consensus de Tendermint et pourquoi il a été conçu comme il a été conçu, vous devez comprendre ce que certains de ces termes compliqués signifient. Vous verrez comment chacun d'entre eux se lient les uns aux autres comme un puzzle complexe.

#1 FLP Impossibilité

L'impossibilité FLP (Fischer Lynch Paterson) indique qu'un algorithme de consensus ne peut avoir que 2 des 3 propriétés suivantes :

Sécurité

Résiliation garantie ou réactivité

Tolérance de pannes

Ultimate Guide to Tendermint

Crédit image : Moyen

En d'autres termes, l'impossibilité du FLP affirme que

« à la fois la résiliation et l'accord (vitalité et sécurité) ne peuvent être satisfaits de manière limitée dans le temps dans un système distribué asynchrone, s'il doit être résilient à au moins un défaut (ils prouvent leur résultat pour une tolérance générale aux pannes, qui est plus faible que la tolérance Byzantine, car elle ne nécessite qu'un seul Fail-stop — donc BFT est inclus dans les revendications d'impossibilité FLP). »

Donc, fondamentalement, il est tout à fait impossible pour un WAN asynchrone de parvenir à un consensus car il n'y a pas de temps spécifique que les nœuds prendront pour recevoir, traiter et répondre aux messages. C'est évidemment un gros problème car il est extrêmement impraticable pour un grand réseau de nœuds comme Bitcoin de supposer qu'ils vont se synchroniser.

Ok, donc la synchronicité allait être un problème. Cependant, les chercheurs Dwork, Lynch et Stockmeyers ont jeté une ligne de vie ici avec leur article intitulé « Consensus in the Presence of Partial Synchrony ». Cela a été appelé consensus DLS.

#2 Consensus DLS et Synchronocité partielle

Le document DLS indique qu'entre un système synchrone et un système asynchrone, il existe un système spécial qui est « partiellement synchrone ». Comme ce système partiellement synchrone peut avoir une limite supérieure donnée, il sera en mesure de concevoir un protocole BFT faisable.

Selon DLS, le véritable défi dans la conception des protocoles est d'en avoir un qui fonctionne correctement dans un système partiellement synchrone.

Donc, voyons comment les protocoles décentralisés populaires comme Bitcoin et Ethereum fonctionnent à cet égard.

Bitcoin a une limite supérieure connue qui est d'environ 10 minutes. Ainsi, un bloc de transactions est produit toutes les 10 minutes. Cette hypothèse de synchronisation est imposée au réseau de sorte que les nœuds obtiennent 10 minutes entières pour recueillir l'information et la transmettre via des commérages.

What is the State machine?

D'autre part, nous avons Ethereum qui fait des hypothèses de synchronisation pour leurs blocs et réseau en gardant un temps de bloc supérieur sur 15 secondes. Avec un temps de blocage si faible, ils sont plus évolutifs que Bitcoin, cependant, ils ne sont pas vraiment si efficaces. Les mineurs d'Ethereum produisent beaucoup de blocs orphelins.

#3 Vidité et résiliation

La résiliation est une propriété qui indique que chaque processeur correct devrait éventuellement prendre une décision. La plupart des algorithmes consensuels, que nous avons en ce moment, reposent sur des modèles synchrones pour leur sécurité et leur terminaison. Ils ont des limites fixes et des règles qui sont connues de sorte que, dans le cas où ils ne tiennent pas, la chaîne se fourche en plusieurs protocoles

Bien sûr, il y a des protocoles de consensus qui fonctionnent dans les réseaux asynchrones, mais en passant par le théorème de l'impossibilité FLP, ils ne peuvent pas être déterministes. Ce qui nous amène à....

#4 Protocoles déterministes vs non déterministes

Habituellement, les protocoles consensuels purement asynchrones dépendent de membres non déterministes tels que les oracles, ce qui implique un degré élevé d'incertitude et de complexité.

Alors, comment Tendermint traite-t-il tous ces facteurs ?

Tendermint est un consensus BFT essentiellement asynchrone, déterministe, où les validateurs ont un intérêt qui dénote leur pouvoir de vote. Dans le triangle d'impossibilité FLP, il préfère la tolérance aux pannes et la sécurité (consistance) à la vitalité.

Tendermint oscille constamment entre les périodes de synchronisation et d'asynchrone. Cela signifie que, même si elle repose sur des hypothèses de synchronisation pour faire des progrès, la vitesse de ladite progression ne dépend pas des paramètres du système mais dépend plutôt de la vitesse réelle du réseau.

De plus, Tendermint ne se fourche jamais en présence d'asynchrone si moins d'un tiers des validateurs sont corrompus ou négligents. C'est la raison même pour laquelle Tendermint est tolérant aux failles byzantines. Comme nous l'avons déjà dit, Tendermint met l'accent sur la sécurité au-dessus de la vitalité. Donc, si plus d'un tiers des validateurs sont malveillants, au lieu de la forking réseau, la blockchain de Tendermint viendra simplement à un arrêt temporaire jusqu'à ce que plus 2/3 validateurs arrivent à un consensus.

Tendermint est également complètement déterministe et il n'y a pas de hasard dans le protocole. Les leaders du système sont tous élus dans une version déterministe, via une fonction mathématique définie. Donc, nous pouvons réellement prouver mathématiquement que le système se comporte de la façon dont il est censé se comporter.

Tendermint - Le système de preuve de pieu

Dans un système de preuve de pieu (POS), nous avons certaines personnes appelées « validateurs ». Ces validateurs verrouillent une mise à l'intérieur du système. Après cela, ils ont la responsabilité de parier sur le bloc qui, à leur avis, va être ajouté à côté de la blockchain. Lorsque le bloc est ajouté, ils reçoivent une récompense proportionnelle à leur mise.

Très bien, c'est ainsi qu'un point de vente générique fonctionne. Maintenant, regardons comment fonctionne la menthe tendre.

Commençons par nous familiariser avec certains des termes que nous utiliserons :

Un réseau se compose de beaucoup de nœuds. Les nœuds connectés à un nœud particulier sont appelés ses homologues.

Le processus de consensus se déroule à une hauteur de bloc particulière H. Le processus de détermination du bloc suivant consiste en plusieurs rondes.

Le tour se compose de nombreux états qui sont : NewHeight, Propose, Prévote, Précommit et Commit. Chaque état est appelé Roundstep ou simplement « step ».

Un nœud est dit être à une hauteur donnée, ronde et pas, ou à (H, R, S), ou à (H, R) en bref pour omettre l'étape.

Prévoter ou préengager quelque chose signifie diffuser un vote préalable ou préengager un vote pour quelque chose.

Quand un bloc obtient 2/3 des prévotes à (H, R) alors il est appelé preuve de verrouillage ou PolC.

Qu'est-ce que la machine d'État ?

La machine d'état est le moteur du protocole Tendermint pour ainsi dire. Le diagramme suivant vous donne une bonne idée de ce à quoi il ressemblera :

What is the State machine?

Ok, qu'est-ce qui se passe ici ?

Rappelez-vous les états que chaque tour passe ? NewHeight, Proposer, Prévoter, Prévalider et valider.

Parmi ceux-ci, « Proposer, Prévoter, Préengager » consiste en un tour tandis que les deux autres sont des tours spéciaux. Dans un scénario idéal, la transition d'état agirait comme ceci :

NewHeight - (Proposer - Prévote - Précommit) + - Commit - NewHeight -...

Cependant, ce n'est pas ainsi que cela peut toujours fonctionner. Plusieurs tours peuvent être nécessaires avant que le bloc soit validé. Voici les raisons pour lesquelles plusieurs tours peuvent être nécessaires :

Le proposant désigné peut être absent.

Le bloc proposé est peut-être invalide.

Le bloc ne s'est pas propagé à temps.

2/3 des prévotes n'ont pas été reçus à temps par les nœuds du validateur.

Même si + 2/3 des prévotes sont nécessaires pour passer à l'étape suivante, au moins un validateur peut avoir voté nul ou voté malicieusement pour autre chose.

2/3 des précommits pour le bloc n'ont pas été reçus même si des prévotes ont pu être reçus.

Que se passe-t-il pendant chaque état ?

Très bien... alors maintenant regardons dans chaque état et voyons comment tout se rassemble.

Proposer

Dans ce stade, le proposant désigné, c'est-à-dire le nœud sélectionné propose un bloc à ajouter à (H, R). Cette étape se termine de l'une des deux façons suivantes :

Le bloc est proposé et qui entre dans l'étape de prévote.

Le temps du proposant pour choisir le bloc expire à partir duquel il entre de toute façon dans l'étape de prévote.

Prévote

Maintenant, nous arrivons à l'étape du prévote. À cette étape, chaque validateur doit prendre une décision.

Si d'une manière ou d'une autre, le validateur est verrouillé sur un bloc proposé d'un tour précédent, ils signent automatiquement et diffusent ce bloc.

Si le validateur a reçu une proposition acceptable pour la ronde en cours, il signe et diffuse un prévote pour le bloc proposé.

Cependant, s'ils trouvent quelque chose de louche avec la proposition ou n'ont reçu aucune proposition du tout (par exemple si le temps de parole du proposant est écoulé), ils signent avec un prévote « néant ».

Aucun blocage ne se produit au cours de cette étape.

Pendant cette période, tous les nœuds propagent les prévotes dans tout le système via le protocole potins.

Pré-engagement

Maintenant, nous entrons dans la dernière étape du « round » appelé « precommit ». En entrant dans cette phase, les validateurs s'engagent à prendre leur décision en diffusant leurs prévotes. L'un des trois scénarios suivants peut se produire :

Si le validateur reçoit 2/3 des prévotes pour un bloc acceptable particulier, le validateur signe et diffuse son précommit sur le bloc. Ils sont aussi enfermés à ce bloc. Un validateur peut se verrouiller sur un seul bloc à la fois.

Cependant, si le validateur reçoit plus de 2/3 des prévotes NUL, ils déverrouillent et les précommits tournent vers « NIL ».

Enfin, s'ils n'ont pas reçu une super majorité de 2/3 du tout, ils ne signent pas ou ne verrouillent rien.

Tout au long de cette étape, les nœuds continuent à bavarder continuellement sur les précommits dans tout le réseau.

En fin de compte, si le bloc proposé obtient plus de 2/3ème précommits, alors nous passons vers l'étape « Commit ». Cependant, s'ils n'atteignent pas cette étape, ils entrent dans l'étape « Proposer » du prochain tour.

Commettre

L'état Commit ne fait pas partie du « round ». Avec NewHeight, c'est l'un des deux tours spéciaux. Pendant l'état de validation, deux conditions parallèles sont vérifiées pour voir si elles sont remplies ou non.

Premièrement, les validateurs doivent recevoir le bloc qui a été préengagé par le réseau. Une fois cela fait, ils signent et diffusent leur engagement.

Deuxièmement, ils doivent attendre jusqu'à ce qu'ils aient reçu au moins 2/3 précommits pour le bloc.

Une fois cela fait, le bloc est engagé sur le réseau.

Huit nouveaux

Il suffit d'incrémenter la hauteur du bloc de 1 pour montrer que le bloc a été ajouté.

Choisir les validateurs

Comme vous l'avez peut-être compris, le choix de l'ensemble initial de validateurs est essentiel pour que Cosmos fonctionne. Alors, comment exactement ils vont être choisis ?

Contrairement au Bitcoin où tout le monde peut devenir mineur à tout moment, il n'y a que tellement de validateurs que le système Tendermint peut prendre en charge. Puisque les validateurs auront individuellement besoin de faire beaucoup de fonctions, l'augmentation du nombre de validateurs ne fera qu'entraîner des retards.

C'est pourquoi Cosmos a décidé de choisir 100 validateurs pendant la journée Genesis (c'est-à-dire le jour de la collecte de fonds). Le nombre de validateurs augmentera de 13% chaque année jusqu'à 10 ans quand il s'installera sur 300.

Ultimate Guide to Tendermint

Alors, qu'en est-il des résultats ?

Comme le dit le livre blanc cosmos :

« Tendermint offre des performances exceptionnelles. Dans les benchmarks de 64 nœuds répartis sur 7 centres de données sur 5 continents, sur les instances de cloud de base, le consensus de Tendermint peut traiter des milliers de transactions par seconde, avec des latences de validation de l'ordre de une à deux secondes. Notamment, la performance de plus d'un millier de transactions par seconde est maintenue même dans des conditions hostiles, les validateurs s'écrasant ou diffusant des votes malveillants. »

Le graphique ci-dessous appuie l'allégation formulée ci-dessus :

Casper vs Menthe

Avec Tendermint, Casper est une autre implémentation populaire du protocole POS.

Alors que Tendermint se concentre sur la sécurité, Casper met l'accent sur la vitalité et l'impossibilité du FLP. Alors, que se passe-t-il à Casper pendant une fourchette ?

Casper FFG permettra à une blockchain de continuer à être construite, tout en ayant également la propriété que tous les nœuds seront conscients que cette chaîne n'est pas finalisée. Ainsi, la blockchain peut rester disponible sans aucune finalité. Les validateurs de la chaîne ont le choix de passer à la chaîne fourchue. Si plus des 2/3 des validateurs votent, ils changent de chaîne.

De plus, Casper a un célèbre mécanisme de découpage. Toute sorte d'attaque malveillante conduira à des validateurs à obtenir leur mise instantanément coupée.

Conclusion

Donc, vous l'avez là. Nous espérons que nous vous avons donné autant d'informations précieuses que possible. Que pensez-vous de Tendermint et de son potentiel ? Sound off sur la section commentaire ci-dessous !

Temps de lecture : 17 minutes Cosmos est l'un des projets les plus prometteurs là-bas. Avec des gens comme Jae Kwon et Ethan Buchman dans leur équipe, cela a beaucoup de potentiel. À son cœur et à son âme se trouve Tendermint Core. Tendermint Core combine l'algorithme de consensus de Tendermint avec un protocole de potins p2p. Ainsi, lorsque vous mettez tout cela dans la pile logicielle, vous obtenez le Tendermint Core avec la couche d'application Cosmos-SDK. Quoi qu'il en soit, avant d'aller plus loin, voyons pourquoi Tendermint est une telle nécessité. Bitcoin et Blockchain Lorsque Satoshi Nakamoto a créé Bitcoin, il a créé le tout premier système cryptographique décentralisé. La partie vraiment remarquable de cette découverte a été qu'il a pu résoudre le problème du général byzantin qui a aidé un réseau étendu (WAN) à parvenir à un consensus dans un environnement sans confiance. Bitcoin a utilisé l'algorithme de preuve de travail pour prendre soin de leur consensus. Cela dit, la principale contribution de Bitcoin pourrait très bien être le fait qu'il a introduit le monde entier à la technologie blockchain. Une blockchain est, dans les termes les plus simples, une série horodatée d'enregistrement immuable de données qui est gérée par un cluster d'ordinateurs ne appartenant pas à une seule entité. Chacun de ces blocs de données (c'est-à-dire bloc) est sécurisé et lié les uns aux autres en utilisant des principes cryptographiques (c'est-à-dire la chaîne). En d'autres termes, une blockchain est une machine d'état déterministe répliquée sur des nœuds qui ne se font pas nécessairement confiance. Par déterministe, nous entendons que si les mêmes mesures spécifiques sont prises, alors cela conduira toujours au même résultat. Par exemple. 1 + 2 sera toujours 3. Alors, qu'est-ce que l'état veut dire ? Regardons WRT Bitcoin et Ethereum. Dans Bitcoin, l'état est une liste de soldes pour chaque compte, qui est une liste de sortie de transaction non dépensée (UTXO). Cet état est modifié via des transactions qui modifient le solde. D'autre part, dans Ethereum, l'application est une machine virtuelle qui exécute des contrats intelligents. Chaque transaction passe par la machine virtuelle Ethereum et modifie l'état en fonction du contrat intelligent spécifique qui est appelé à l'intérieur. Si vous regardez l'architecture de la technologie blockchain, alors vous aurez trois couches spécifiques : Mise en réseau : La propagation de la transaction/information à travers les nœuds Consensus : Permet aux nœuds de prendre une décision à condition que 2/3 des nœuds ne sont pas malveillants Application : Responsable de la mise à jour l'état donné un ensemble de transactions, c'est-à-dire le traitement des transactions. Compte tenu d'une transaction et d'un état, l'application renvoie un nouvel état. Pour les indices visuels : Problèmes avec l'architecture Blockchain actuelle Il s'avère que construire une blockchain à partir de zéro avec toutes ces 3 couches est vraiment un travail difficile. Ainsi, de nombreux projets ont préféré construire en forçant la base de code Bitcoin. Maintenant, bien que cela économise beaucoup de temps, le fait est qu'ils sont toujours menottés par les limitations du protocole Bitcoin. Évidemment, vous ne pouvez pas exécuter de projets complexes lorsque vous utilisez un protocole bien connu pour ses problèmes de débit. Les choses se sont beaucoup mieux passées quand Ethereum est entré en jeu. Ethereum a en fait donné aux développeurs une plate-forme qu'ils pourraient utiliser pour créer leur propre code personnalisé aka contrats et projets intelligents. Cependant, comme avec Bitcoin, Ethereum souffre également du même problème. Ils ont tous deux une architecture monolithique par opposition à modulaire. Architecture monolithique vs Architecture modulaire L'architecture monolithique signifie que tout est composé en une seule pièce. Lorsque le logiciel est considéré comme « monolithique », les composants sont interconnectés et interdépendants les uns avec les autres et la conception est plus autonome. Dans ce cas, l'architecture est plus étroitement couplée et les composants associés doivent être tous présents pour que le code soit exécuté ou compilé. Bien que cela rend le système il a été créé pour plus robuste, vous ne pouvez pas vraiment en dériver et créer des codes personnalisés. Ce n'est pas le système le plus flexible. De plus, il y a un autre problème avec ce système. Si une composante du programme doit être mise à jour, l'application entière devra être retravaillée. Ce n'est pas vraiment la situation la plus idéale maintenant, n'est-ce pas ? D'autre part, nous avons une architecture modulaire. Contrairement à Monolithic, les couches ne sont pas si liées les unes aux autres. Donc, bien qu'il ne soit pas aussi robuste, il est assez facile de mise à jour de l'ensemble de l'application en travaillant avec les différents modules séparés. Étant donné que les modules sont si indépendants, l'architecture modulaire vous permet de réellement actualiser une section particulière sans provoquer de changements imprévus au reste du système. Les processus itératifs sont également beaucoup plus simples dans les programmes modulaires, par opposition à monolithiques. L'architecture et les objectifs de Tendermint utilise l'architecture modulaire. Leurs objectifs sont les suivants : Fournir la mise en réseau et les couches de consensus d'une blockchain comme une plate-forme où différentes applications décentralisées peuvent être construites Les développeurs ont seulement besoin de s'inquiéter de la couche d'application de la blockchain, économisant toutes les heures qu'ils auraient gaspillées à travailler sur le consensus et la couche de mise en réseau. Tendermint inclut également le protocole de consensus Tendermint qui est l'algorithme de consensus byzantin tolérant aux pannes utilisé dans le moteur Tendermint Core Regardons à quoi ressemblera l'architecture de Tendermint : Comme vous pouvez le voir, l'application est connectée à Tendermint Core via un protocole de socket appelé APCI ou Application Blockchain Interface. Puisque Tendermint Core et l'application s'exécutant sur elle s'exécutent dans des processus UNIX distincts, ils doivent avoir une méthode pour parler les uns avec les autres. ABCI aide ces deux-là dans leur communication. Alors, à quoi ressemble le design d'ABCI ? ABCI aura des composants de conception distincts : #1 Message Protocol Paires de messages de requête et de réponse Les demandes sont faites par consensus pendant que l'application prend soin de la réponse Il est défini en utilisant protobuf #2 Server/Client Le moteur de consensus exécute le client L'application exécute le serveur Il y a deux implémentations appropriées : octets bruts asynchrones et grpc #3 Blockchain Protocol ABCI est très orienté connexion. Les trois connexions pour Tendermint Core sont les suivantes : Connexion Mempool : Ceci vérifie si les transactions doivent être relayées avant qu'elles ne soient validées. Elle ne peut utiliser que CheckTX Consensus connection : Cette connexion aide à l'exécution des transactions qui ont été validées. La séquence de message est, pour chaque bloc, BeginBlock, [DelivertX,...], EndBlock, Commit Query Connection : Aide à interroger l'état de l'application. Cette partie n'utilise que Query and Info All dans l'ensemble, l'objectif principal de Tendermint est de fournir aux développeurs un outil qui est non seulement pratique, mais a également un débit élevé. Voici les propriétés de Tendermint qui le rend si séduisant : #1 Publics ou Private Blockchain Compatible Différents projets ont des besoins différents. Certains projets doivent avoir un système ouvert où tout le monde peut participer et contribuer, comme Ethereum. D'autre part, nous avons des organisations comme l'industrie médicale, qui ne peuvent pas exposer leurs données à presque tout le monde. Pour eux, ils ont besoin de quelque chose comme la blockchain permise. Ok, alors comment Tendermint peut-il aider à satisfaire ces deux besoins ? Rappelez-vous que Tendermint ne gère que le réseautage et le consensus pour la blockchain. Donc, cela aide dans la : Propagation de la transaction entre les nœuds via le protocole potins Aide les validateurs à s'entendre sur l'ensemble des transactions qui est ajouté à la blockchain. Ce que cela signifie, c'est que la couche d'application est libre d'être définie de la manière que les développeurs veulent qu'elle soit définie. Il appartient aux développeurs de définir comment l'ensemble de validateurs est défini dans l'écosystème. Les développeurs peuvent soit permettre à l'application d'avoir un système d'élection qui sélectionne les validateurs en fonction du nombre de jetons natifs que ces validateurs ont jalonné dans l'écosystème.. aka Proof-of-Spot et créer une blockchain publique Plus, les développeurs peuvent également créer une application qui définit un ensemble restreint des validateurs pré-approuvés qui prennent soin du consensus et des nouveaux nœuds qui entrent dans l'écosystème. Ceci est appelé preuve d'autorité et est la marque d'une blockchain autorisée ou privée. #2 Les applications hautes performances réalisées via Tendermint Core peuvent s'attendre à des performances exceptionnelles. Tendermint Core a un temps de bloc de seulement 1 seconde. Il peut également gérer un volume de transactions de 10 000 transactions par seconde pour les transactions de 250 octets, tant que l'application le permet. #3 Finalité Qu'est-ce que la finalité ? En termes simples, cela signifie qu'une fois qu'une certaine action a été exécutée, elle ne peut pas être reprise. Prenons donc l'exemple d'une simple transaction financière. Supposons que vous achetez des actions dans une entreprise, juste parce qu'un problème dans leur système, vous ne devriez pas perdre sur la propriété de vos actions. Comme vous pouvez l'imaginer, la finalité est très critique pour un système financier. Imaginez faire une transaction d'un million de dollars et le lendemain, cette transaction n'est plus valide à cause d'un problème. Comme nous l'avons déjà mentionné, Bitcoin et Ethereum (jusqu'à la mise en œuvre complète de Casper FFG) n'ont pas vraiment la finalité du règlement. À l'occasion d'un hardfork ou d'une attaque de 51%, les transactions ont une chance d'être annulées. D'autre part, Tendermint donne la finalité instantanée dans un délai d'une seconde à compter de la fin de la transaction. Les forks ne sont jamais créés dans le système, tant que moins de 2/3 des validateurs sont malveillants. Dès qu'un bloc est créé (ce qui est en moins d'une seconde), les utilisateurs peuvent être assurés que leur transaction est finalisée. #4 Security Tendermint est sécurisé et oblige ses participants à être responsables de leurs actions. Comme nous l'avons déjà dit, la menthe tendermint ne peut jamais être fourchue tant que moins de 2/3 des validateurs sont malveillants. Si dans certains cas, la blockchain fait une fourchette, il existe un moyen de déterminer la responsabilité. De plus, le consensus de Tendermint n'est pas seulement tolérant aux pannes, il est idéalement byzantin aux pannes #5 Facile à utiliser Une autre grande chose à propos de Tendermint est sa convivialité. Comme nous l'avons déjà mentionné, ils ont une architecture modulaire où la couche d'application peut être adaptée. Cela permet aux bases de code blockchain existantes d'être facilement liées à Tendermint via ABCIs. L'exemple parfait de ceci est Etheremint qui est fondamentalement la prise de code de la machine virtuelle Ethereum sur le dessus de Tendermint. Ethermint fonctionne exactement comme Ethereum mais bénéficie également de toutes les fonctionnalités positives que nous avons énumérées ci-dessus. Tous les outils Ethereum tels que Metamask et Truffle sont compatibles avec Ethermint. #6 Scalability La mise en œuvre de preuve d'enjeu de Tendermint est beaucoup plus évolutive qu'un algorithme traditionnel de validation de travail. La principale raison en est que les systèmes basés sur le POP ne peuvent pas faire le partage. Le partage partitionne essentiellement horizontalement une base de données et crée des bases de données ou des fragments plus petits qui sont ensuite exécutés parallèlement par les nœuds. La raison en est qu'un bassin minier solide peut facilement prendre le contrôle d'un fragment. Tendermint permettra la mise en œuvre de Sharding, ce qui augmentera considérablement l'évolutivité. Protocole de consensus de Tendermint Ok, alors examinons comment fonctionne le protocole de consensus de Tendermint. Qu'est-ce qu'un protocole de consensus ? C'est ainsi que Wikipedia définit la prise de décision par consensus : « La prise de décision par consensus est un processus décisionnel de groupe dans lequel les membres du groupe développent et acceptent de soutenir une décision dans le meilleur intérêt de l'ensemble. Le consensus peut être défini professionnellement comme une résolution acceptable, une résolution qui peut être appuyée, même si ce n'est pas le « favori » de chaque personne. Le « consensus » est défini par Merriam-Webster comme étant, premièrement, un accord général, et deuxièmement, une solidarité collective de croyance ou de sentiment. » En termes plus simples, le consensus est un moyen dynamique de parvenir à un accord au sein d'un groupe. Alors que le vote se contente d'une règle majoritaire sans penser aux sentiments et au bien-être de la minorité, un consensus, d'autre part, permet de parvenir à un accord qui pourrait bénéficier à l'ensemble du groupe. D'un point de vue plus idéaliste, le consensus peut être utilisé par un groupe de personnes dispersées dans le monde pour créer une société plus équitable et plus équitable. Une méthode permettant de parvenir à la prise de décisions par consensus est appelée « mécanisme de consensus ». Alors maintenant ce que nous avons défini ce qu'est un consensus, regardons quels sont les objectifs d'un mécanisme de consensus (données tirées de Wikipédia). Recherche d'un accord : Un mécanisme de consensus devrait permettre au groupe de s'entendre autant que possible. Collaborative : Tous les participants devrait viser à travailler ensemble pour parvenir à un résultat qui accorde la priorité au mieux des intérêts du groupe. Coopérative : Tous les participants ne devraient pas privilégier leurs propres intérêts et travailler en équipe plus que les individus. Participation : Le mécanisme de consensus devrait être tel que chacun participe activement à l'ensemble du processus. Inclusive : Le plus grand nombre possible de personnes devraient participer au processus de consensus. Cela ne devrait pas être comme un vote normal où les gens n'ont pas vraiment envie de voter parce qu'ils croient que leur vote n'aura pas de poids à long terme. Égalitaire : Un groupe qui tente de parvenir à un consensus devrait être aussi égalitaire que possible. Ce que cela signifie fondamentalement que chaque vote a le même poids. Le vote d'une personne ne peut pas être plus important que celui d'une autre. Maintenant que nous avons défini les mécanismes de consensus et ce qu'ils devraient viser, nous devons penser à l'autre éléphant dans la salle. Quels mécanismes de consensus devraient être utilisés pour une entité comme blockchain. Avant Bitcoin, il y avait beaucoup d'itérations de systèmes de monnaie décentralisés peer-to-peer qui ont échoué parce qu'ils n'étaient pas en mesure de répondre au plus gros problème lorsqu'il s'agit de parvenir à un consensus. Ce problème est appelé « Problème général byzantin ». Problème général byzantin Afin de faire quoi que ce soit dans un réseau pair à pair, tous les nœuds devraient être en mesure de parvenir à un consensus. Cependant, pour que ce système fonctionne, il met beaucoup l'accent sur les gens pour qu'ils agissent dans le meilleur intérêt de l'ensemble du réseau. Cependant, comme nous le savons déjà, les gens ne sont pas vraiment dignes de confiance lorsqu'il s'agit d'agir de manière éthique. C'est là que le problème du général byzantin entre en jeu. Imaginez cette situation. Il y a une armée qui entoure un château bien fortifié. La seule façon de gagner est de s'ils attaquent le château ensemble en tant qu'unité. Cependant, ils sont confrontés à un gros problème. L'armée est loin l'un de l'autre et les généraux ne peuvent pas vraiment communiquer directement et coordonner l'attaque et certains généraux sont corrompus. La seule chose qu'ils peuvent faire est d'envoyer un messager du général au général. Cependant, beaucoup de choses pourraient arriver au messager. Les généraux corrompus peuvent intercepter le messager et changer le message. Alors, que peuvent faire les généraux pour s'assurer qu'ils lancent une attaque coordonnée sans compter sur l'éthique de chaque général ? Comment peuvent-ils parvenir à un consensus sans confiance pour faire ce qui doit être fait ? C'est le problème du général byzantin et Satoshi Nakamoto a résolu ce problème en utilisant le mécanisme de consensus de la preuve de travail (POW). Qu'est-ce que la preuve de travail ? Vérifions comment POW fonctionne avec le contexte de notre exemple donné ci-dessus. Supposons qu'un général veuille communiquer avec un autre général. Comment pensez-vous que ça va se passer ? Un « nonce » est ajouté au message d'origine. Le nonce est une valeur hexadécimale aléatoire. Ce nouveau message est ensuite haché. Supposons que les généraux conviennent à l'avance qu'ils n'enverront que des messages qui, lorsqu'ils sont hachés, commencent par 4 « 0"s. Si le hachage ne donne pas le nombre souhaité de 0, le nonce est changé et le message est de nouveau haché. Ce processus se répète jusqu'à ce que le hachage souhaité soit reçu. L'ensemble du processus prend beaucoup de temps et prend beaucoup de puissance de calcul. Maintenant, quand ils obtiennent enfin la valeur hachée, le messager reçoit le message original et le nonce et dit de communiquer avec les autres généraux. Que se passe-t-il si quelqu'un essaie d'intercepter le message ? Tu te souviens de l'effet avalanche des fonctions de hachage ? Le message changera radicalement et comme il ne commencera plus avec le nombre requis de « 0 », les gens se rendront compte que le message a été falsifié. Donc, pour placer POW dans le contexte de l'extraction de crypto : Les mineurs essaient de résoudre des énigmes cryptographiques pour ajouter un bloc à la blockchain. Le processus nécessite beaucoup d'efforts et de puissance de calcul. Les mineurs présentent ensuite leur bloc au réseau bitcoin. Le réseau vérifie ensuite l'authenticité du bloc en vérifiant simplement le hachage, s'il est correct, il est ajouté à la blockchain. Donc, découvrir le nonce et le hachage requis devrait être difficile, cependant vérifier si elle est valide ou non devrait être simple. C'est l'essence même de la preuve de travail. Maintenant, vous vous demandez probablement, pourquoi les mineurs devraient sacrifier leur temps et leurs ressources pour exploiter des bitcoins ? Eh bien, s'avère qu'ils ont une incitation économique assez saine : Lorsque vous découvrez un bloc, vous recevez une récompense de bloc de 12,5 bitcoins. La récompense est de moitié tous les 210 000 blocs. Une fois que vous avez extrait un bloc, vous devenez le dictateur temporaire du bloc. Vous êtes responsable de la mise en place des transactions dans le bloc et avez donc droit à des frais de transaction. Il n'y a qu'un nombre limité de bitcoins là-bas, 21 millions pour être exact. Qu'est-ce qui empêche ces mineurs d'extraire tous les bitcoins à la fois ? Il s'avère que l'extraction de bitcoin devient progressivement plus difficile au fil du temps. Cette fonctionnalité est appelée « difficulté », et la difficulté de l'exploitation minière continue à augmenter à mesure que vous continuez à exploiter. C'est pourquoi il est pratiquement impossible de nos jours pour les mineurs seuls de miner Bitcoins en utilisant uniquement leurs ordinateurs. Les mineurs ont maintenant uni leurs forces et créé des « pools miniers » pour regrouper leur puissance de calcul et les exploiter en tant que groupe. Ces pools utilisent des ASIC (Application-Specific Integrated Circuits) spécialement créés pour l'extraction de bitcoins. Problèmes avec les prisonniers de guerre Il y a trois problèmes principaux avec les algorithmes de preuve de travail. Nous en avons déjà parlé en détail, donc nous allons simplement faire un aperçu général. Perte d'énergie : Bitcoin mange plus de puissance que l'Irlande et la République slovaque. Cet énorme gaspillage d'énergie est l'un des principes de Bitcoin. C'est du gaspillage pour le bien du gaspillage. Centralisation : Comme nous vous l'avons déjà dit, Bitcoin utilise des ASIC pour l'exploitation minière. Le problème est que les ASIC sont coûteux, et les pools avec plus d'argent ont tendance à avoir plus d'ASIC et, par conséquent, plus de puissance minière. En tant que tel, Bitcoin n'est pas aussi décentralisé qu'il le veut. Évolutivité : L'architecture même des prisonniers de guerre empêche l'évolutivité. Bitcoin gère seulement 7 transactions par seconde. Pour un système financier moderne, il n'est tout simplement pas suffisant. Entrez Tendermint Donc, pour contrecarrer les nombreux problèmes avec le système de consensus de preuve de travail, Jae Kwon, diplômée en informatique et en génie des systèmes, a créé Tendermint. Tendermint est un protocole purement basé sur BFT, construit dans un cadre sans autorisation avec le Proof-of-Spot (PO) comme mécanisme de sécurité sous-jacent. En raison de sa complexité, Tendermint a mis près de 4 ans à être complétée. Jae Kwon et le directeur de la Tendermint Ethan Buchman ont été inspirés par Raft et PBFT pour créer un système de consensus qui satisfaisait le problème du général byzantin. Il est « modélisé comme un protocole déterministe, vivant sous synchrone partielle, qui atteint le débit dans les limites de la latence du réseau et des processus individuels eux-mêmes ». Très bien, nous savons que c'est beaucoup de mots compliqués à jeter les uns après les autres, mais pour comprendre ce qu'est le consensus de Tendermint et pourquoi il a été conçu comme il a été conçu, vous devez comprendre ce que certains de ces termes compliqués signifient. Vous verrez comment chacun d'entre eux se lient les uns aux autres comme un puzzle complexe. #1 FLP Impossibilité Le FLP (Fischer Lynch Paterson) Impossibilité indique qu'un algorithme de consensus ne peut avoir que 2 des 3 propriétés suivantes : Sécurité Garantie terminaison ou liveness Tolérance de défaillance Crédit d'image : Moyen Dans en d'autres termes, l'impossibilité FLP affirme que « la résiliation et l'accord (vitalité et sécurité) ne peuvent être satisfaits de manière limitée dans le temps dans un système distribué asynchrone, s'il doit être résilient à au moins un défaut (ils prouvent leur résultat pour une tolérance générale aux pannes, qui est plus faible que Byzantine , car il ne nécessite qu'un seul nœud d'arrêt de défaillance, donc BFT est inclus dans les revendications d'impossibilité FLP). » Donc, fondamentalement, il est tout à fait impossible pour un WAN asynchrone de parvenir à un consensus car il n'y a pas de temps spécifique que les nœuds prendront pour recevoir, traiter et répondre aux messages. C'est évidemment un gros problème car il est extrêmement impraticable pour un grand réseau de nœuds comme Bitcoin de supposer qu'ils vont se synchroniser. Ok, donc la synchronicité allait être un problème. Cependant, les chercheurs Dwork, Lynch et Stockmeyers ont lancé une ligne de vie ici avec leur article intitulé « Consensus in the Presence of Partial Synchrony ». Ce document a été appelé consensus DLS. #2 DLS Consensus and Partial Synchronocity Le document DLS indique qu'entre un système synchrone et un système asynchrone, il existe un système spécial qui est « partiellement synchrone ». Comme ce système partiellement synchrone peut avoir une limite supérieure donnée, il sera en mesure de concevoir un protocole BFT faisable. Selon DLS, le véritable défi dans la conception des protocoles est d'en avoir un qui fonctionne correctement dans un système partiellement synchrone. Donc, voyons comment les protocoles décentralisés populaires comme Bitcoin et Ethereum fonctionnent à cet égard. Bitcoin a une limite supérieure connue qui est d'environ 10 minutes. Ainsi, un bloc de transactions est produit toutes les 10 minutes. Cette hypothèse de synchronisation est imposée au réseau de sorte que les nœuds obtiennent 10 minutes entières pour recueillir l'information et la transmettre via des commérages. D'autre part, nous avons Ethereum qui fait des hypothèses de synchronisation pour leurs blocs et réseau en gardant un temps de bloc supérieur sur 15 secondes. Avec un temps de blocage si faible, ils sont plus évolutifs que Bitcoin, cependant, ils ne sont pas vraiment si efficaces. Les mineurs d'Ethereum produisent beaucoup de blocs orphelins. #3 Liveness and Cessation Termination est une propriété qui indique que chaque processeur correct devrait éventuellement prendre une décision. La plupart des algorithmes consensuels, que nous avons en ce moment, reposent sur des modèles synchrones pour leur sécurité et leur terminaison. Ils ont des limites fixes et des règles qui sont connus de sorte que, dans le cas où ils ne tiennent pas, la chaîne se fourche en plusieurs protocoles Bien sûr, il y a des protocoles de consensus qui fonctionnent dans les réseaux asynchrones, cependant en passant par le théorème de l'impossibilité FLP, ils ne peuvent pas être déterministes. Ce qui nous amène à.... #4 Protocoles déterministes vs non déterministes Habituellement, les protocoles consensuels purement asynchrones dépendent de membres non déterministes tels que les oracles qui impliquent un degré élevé d'incertitude et de complexité. Alors, comment Tendermint traite-t-il tous ces facteurs ? Tendermint est un consensus BFT essentiellement asynchrone, déterministe, où les validateurs ont un intérêt qui dénote leur pouvoir de vote. Dans le triangle d'impossibilité FLP, il préfère la tolérance aux pannes et la sécurité (consistance) à la vitalité. Tendermint oscille constamment entre les périodes de synchronisation et d'asynchrone. Cela signifie que, même si elle repose sur des hypothèses de synchronisation pour faire des progrès, la vitesse de ladite progression ne dépend pas des paramètres du système mais dépend plutôt de la vitesse réelle du réseau. De plus, Tendermint ne se fourche jamais en présence d'asynchrone si moins d'un tiers des validateurs sont corrompus ou négligents. C'est la raison même pour laquelle Tendermint est tolérant aux failles byzantines. Comme nous l'avons déjà dit, Tendermint met l'accent sur la sécurité au-dessus de la vitalité. Donc, si plus d'un tiers des validateurs sont malveillants, au lieu de la forking réseau, la blockchain de Tendermint viendra simplement à un arrêt temporaire jusqu'à ce que plus 2/3 validateurs arrivent à un consensus. Tendermint est également complètement déterministe et il n'y a pas de hasard dans le protocole. Les leaders du système sont tous élus dans une version déterministe, via une fonction mathématique définie. Donc, nous pouvons réellement prouver mathématiquement que le système se comporte de la façon dont il est censé se comporter. Tendermint - Le système de preuve de pieu Dans un système de preuve de pieu (POS), nous avons certaines personnes appelées « validateurs ». Ces validateurs verrouillent une mise à l'intérieur du système. Après cela, ils ont la responsabilité de parier sur le bloc qui, à leur avis, va être ajouté à côté de la blockchain. Lorsque le bloc est ajouté, ils reçoivent une récompense proportionnelle à leur mise. Très bien, c'est ainsi qu'un point de vente générique fonctionne. Maintenant, regardons comment fonctionne la menthe tendre. Commençons par nous familiariser avec certains des termes que nous allons utiliser : Un réseau se compose de beaucoup de nœuds. Les nœuds connectés à un nœud particulier sont appelés ses homologues. Le processus de consensus se déroule à une hauteur de bloc particulière H. Le processus de détermination du bloc suivant consiste en plusieurs rondes. Le tour se compose de nombreux États qui sont : NewhHuit, Proposer, Prévoter, Précomit, et Commit. Chaque état est appelé Roundstep ou simplement « step ». Un nœud est dit être à une hauteur donnée, ronde et pas, ou à (H, R, S), ou à (H, R) en bref pour omettre l'étape. Prévoter ou préengager quelque chose signifie diffuser un vote préalable ou préengager un vote pour quelque chose. Quand un bloc obtient 2/3 des prévotes à (H, R) alors il est appelé preuve de verrouillage ou PolC. Qu'est-ce que la machine d'État ? La machine d'état est le moteur du protocole Tendermint pour ainsi dire. Le diagramme suivant vous donne une bonne idée de ce que cela va ressembler : Ok, alors que se passe-t-il ici ? Rappelez-vous les états que chaque tour passe ? NewHeight, Proposer, Prévoter, Prévalider et valider. Parmi ceux-ci, « Proposer, Prévoter, Préengager » consiste en un tour tandis que les deux autres sont des tours spéciaux. Dans un scénario idéal, la transition d'état agirait comme ceci : NewHeight - (Propose - Prevote - Precommit) + - Commit - NewHeight -... Cependant, ce n'est pas comme ça que cela peut toujours fonctionner. Plusieurs tours peuvent être nécessaires avant que le bloc soit validé. Voici les raisons pour lesquelles plusieurs rondes peuvent être nécessaires : Le proposant désigné peut être absent. Le bloc proposé est peut-être invalide. Le bloc ne s'est pas propagé dans le temps. 2/3 des prévotes n'ont pas été reçus à temps par les nœuds du validateur. Même si + 2/3 des prévotes sont nécessaires pour passer à l'étape suivante, au moins un validateur peut avoir voté ou voté malicieusement pour autre chose. 2/3 des précommits pour le bloc n'ont pas été reçus même si des prévotes ont pu être reçus. Que se passe-t-il pendant chaque état ? Très bien... alors maintenant regardons dans chaque état et voyons comment tout se rassemble. Proposer Dans ce stade, le proposant désigné, c'est-à-dire le nœud sélectionné propose un bloc à ajouter à (H, R). Cette étape se termine de deux façons : Le bloc est proposé et qui entre dans l'étape de prévote. Le temps du proposant pour choisir le bloc expire à partir duquel il entre de toute façon dans l'étape de prévote. Prévoter Maintenant, nous arrivons à l'étape du prévote. À cette étape, chaque validateur doit prendre une décision. Si d'une manière ou d'une autre, le validateur est verrouillé sur un bloc proposé d'un tour précédent, ils signent automatiquement et diffusent ce bloc. Si le validateur a reçu une proposition acceptable pour la ronde en cours, il signe et diffuse un prévote pour le bloc proposé. Cependant, s'ils trouvent quelque chose de louche avec la proposition ou n'ont reçu aucune proposition du tout (par exemple si le temps de parole du proposant est écoulé), ils signent avec un prévote « néant ». Aucun blocage ne se produit au cours de cette étape. Pendant cette période, tous les nœuds propagent les prévotes dans tout le système via le protocole potins. Pré-commit Maintenant, nous entrons dans la dernière étape du « round » appelé « precommit ». En entrant dans cette phase, les validateurs s'engagent à prendre leur décision en diffusant leurs prévotes. Un des trois scénarios suivants peut se produire : Si le validateur reçoit 2/3 des prévotes pour un bloc acceptable particulier, le validateur signe et diffuse son précommit sur le bloc. Ils sont aussi enfermés à ce bloc. Un validateur peut se verrouiller sur un seul bloc à la fois. Cependant, si le validateur reçoit plus de 2/3 des prévotes NUL, ils déverrouillent et les précommits tournent vers « NIL ». Enfin, s'ils n'ont pas reçu une super majorité de 2/3 du tout, ils ne signent pas ou ne verrouillent rien. Tout au long de cette étape, les nœuds continuent à bavarder continuellement sur les précommits dans tout le réseau. En fin de compte, si le bloc proposé obtient plus de 2/3ème précommits, alors nous passons vers l'étape « Commit ». Cependant, s'ils n'atteignent pas cette étape, ils entrent dans l'étape « Proposer » du prochain tour. Commit L'état Commit ne fait pas partie du « round ». Avec NewHeight, c'est l'un des deux tours spéciaux. Pendant l'état de validation, deux conditions parallèles sont vérifiées pour voir si elles sont remplies ou non. Premièrement, les validateurs doivent recevoir le bloc qui a été préengagé par le réseau. Une fois cela fait, ils signent et diffusent leur engagement. Deuxièmement, ils doivent attendre jusqu'à ce qu'ils aient reçu au moins 2/3 précommits pour le bloc. Une fois cela fait, le bloc obtient engagé dans le réseau. NewHeight incrémente simplement la hauteur du bloc de 1 pour montrer que le bloc a été ajouté. Choisir les validateurs Comme vous l'avez peut-être compris, le choix de l'ensemble initial de validateurs est essentiel pour que Cosmos fonctionne. Alors, comment exactement ils vont être choisis ? Contrairement au Bitcoin où tout le monde peut devenir mineur à tout moment, il n'y a que tellement de validateurs que le système Tendermint peut prendre en charge. Puisque les validateurs auront individuellement besoin de faire beaucoup de fonctions, l'augmentation du nombre de validateurs ne fera qu'entraîner des retards. C'est pourquoi Cosmos a décidé de choisir 100 validateurs pendant la journée Genesis (c'est-à-dire le jour de la collecte de fonds). Le nombre de validateurs augmentera de 13% chaque année jusqu'à 10 ans quand il s'installera sur 300. Alors, qu'en est-il des résultats ? Comme le dit le livre blanc cosmos : « Tendermint offre des performances exceptionnelles. Dans les benchmarks de 64 nœuds répartis sur 7 centres de données sur 5 continents, sur les instances de cloud de base, le consensus de Tendermint peut traiter des milliers de transactions par seconde, avec des latences de validation de l'ordre de une à deux secondes. Notamment, la performance de plus d'un millier de transactions par seconde est maintenue même dans des conditions hostiles, les validateurs s'écrasant ou diffusant des votes malveillants. » Le graphique ci-dessous appuie l'affirmation faite ci-dessus : Casper vs Tendermint Avec Tendermint, Casper est une autre implémentation populaire du protocole POS. Alors que Tendermint se concentre sur la sécurité, Casper met l'accent sur la vitalité et l'impossibilité du FLP. Alors, que se passe-t-il à Casper pendant une fourchette ? Casper FFG permettra à une blockchain de continuer à être construite, tout en ayant également la propriété que tous les nœuds seront conscients que cette chaîne n'est pas finalisée. Ainsi, la blockchain peut rester disponible sans aucune finalité. Les validateurs de la chaîne ont le choix de passer à la chaîne fourchue. Si plus des 2/3 des validateurs votent, ils changent de chaîne. De plus, Casper a un célèbre mécanisme de découpage. Toute sorte d'attaque malveillante conduira à des validateurs à obtenir leur mise instantanément coupée. Conclusion Donc, vous l'avez. Nous espérons que nous vous avons donné autant d'informations précieuses que possible. Que pensez-vous de Tendermint et de son potentiel ? Sound off sur la section commentaire ci-dessous !

Like what you read? Give us one like or share it to your friends

52
1

1
Discussion

Please to comment
newest oldest most voted

Ultra great article !
The most easiest way to try:
A top quality blockchain hackathon for bests talents! Tendermint, the Fintech Chaire of the Université Paris-Dauphine and Chain Accelerator organize a hackathon during the weekend of 13-14 April (PBW). 10 k€ and tickets for Paris Blockchain Week Summit to win.
The goal is to build a blockchain compatible with the ecosystem Cosmos / Tendermint, as well as the corresponding user interface. Participants use Cosmos-SDK, a Golang framework for building blockchains easily from modules. At the University Paris Dauphine Paris.5

Hungry for knowledge?
New guides and courses each week
Looking to invest?
Market data, analysis, and reports
Just curious?
A community of blockchain experts to help

Get started today and earn 4 bonus blocks

Already have an account? Sign In