Suite à l’article introductif sur Cosmos, nous allons approfondir certains points en une série de 4 articles.

Dans ce premier article détaillé nous développerons :

• Les différents composants de Tendermint
• Le Hub Cosmos
• Les zones de Cosmos
• La communication inter-blockchain

Rappelons tout d’abord que Cosmos est un réseau de blockchains indépendantes, appelées zones, alimentées et soutenues par Tendermint Core, un moteur de consensus de type PBFT à haute performance et sécurisé. Un algorithme de consensus pour toutes les zones qui assure une bonne scalabilité des blockchains connexes.

La première zone sur Cosmos s’appelle le Cosmos Hub. Très attendue elle a été lancée en Mars 2019. Le Cosmos Hub est une crypto-monnaie de preuve d’enregistrement multi-actifs avec un mécanisme de gouvernance simple qui permet au réseau de s’adapter et de se mettre à niveau. De plus, le hub Cosmos peut être étendu en connectant d’autres zones.

Le concentrateur et les zones du réseau Cosmos communiquent entre eux via un protocole de communication inter-blockchain (IBC), une sorte de protocole UDP ou TCP virtuel pour les chaînes de blocs. Les jetons peuvent être transférés d’une zone à une autre rapidement et en toute sécurité, sans qu’il soit nécessaire de disposer de liquidités d’échange entre zones. Au lieu de cela, tous les transferts de jetons entre zones passent par le hub Cosmos, qui enregistre le nombre total de jetons détenus par chaque zone. Le concentrateur isole chaque zone de la défaillance d’autres zones. Étant donné que tout le monde peut connecter une nouvelle zone au Cosmos Hub, les zones permettent une compatibilité future avec les nouvelles innovations de la chaîne de blocs.

Tendermint

Dans cette section, nous décrirons le protocole de consensus Tendermint et l’interface utilisée pour créer des applications avec ce protocole. Pour plus de détails, voir l’annexe .

VALIDATEURS

Dans les algorithmes byzantins classiques à tolérance de pannes (BFT), chaque nœud a le même poids. Dans Tendermint, les nœuds ont un pouvoir de vote non négatif, et les nœuds ayant un pouvoir de vote positif sont appelés des validateurs. Les validateurs participent au protocole de consensus en diffusant des signatures cryptographiques, ou votes, afin de convenir du bloc suivant.

Les pouvoirs de vote des validateurs sont déterminés à la genèse ou sont modifiés de manière déterministe par la blockchain, en fonction de l’application. Par exemple, dans une application de preuve de participation telle que le Cosmos Hub, le nombre de voix au vote peut être déterminé par le nombre de jetons de jalonnement cautionné.

REMARQUE: Les fractions comme ⅓ se rapportent à des fractions du nombre total de voix attribuées, jamais au nombre total de validateurs, à moins que tous les validateurs aient le même poids. > Signifie “plus que”, ≥⅓ signifie “au moins”.

CONSENSUS

Tendermint est un protocole de consensus BFT partiellement synchrone dérivé de l’algorithme de consensus DLS [20] . Tendermint se distingue par sa simplicité, ses performances et son sens des responsabilités. Le protocole nécessite un ensemble connu de validateurs fixes, chaque validateur étant identifié par sa clé publique. Les validateurs tentent de parvenir à un consensus sur un bloc à la fois, un bloc étant une liste de transactions. Le vote pour un consensus sur un bloc se déroule en tour. Chaque tour a un chef de file, ou un proposant, qui propose un bloc. Les validateurs votent ensuite, par étapes, sur l’opportunité d’accepter le bloc proposé ou de passer au tour suivant. Le proposant pour un tour est choisi de manière déterministe dans la liste ordonnée de validateurs, proportionnellement à leur pouvoir de vote.

Les détails complets du protocole sont décrits ici.

La sécurité de Tendermint découle de son utilisation de la tolérance aux pannes byzantine optimale via un vote à la super-majorité (> ⅔) et un mécanisme de verrouillage. Ensemble, ils s’assurent que :

• ≥⅓ le droit de vote doit être byzantin pour causer une violation de la sécurité lorsque plus de deux valeurs sont commises.
• Si un groupe de validateurs réussit à violer la sécurité, ou même tente de le faire, il peut être identifié par le protocole. Cela inclut à la fois le vote pour des blocs en conflit et la diffusion de votes non justifiés.

Malgré ses fortes garanties, Tendermint offre des performances exceptionnelles. Sur les benchmarks de 64 nœuds répartis sur 7 centres de données sur 5 continents, sur des instances de cloud computing standard, Tendermint Consensus peut traiter des milliers de transactions par seconde, avec des latences de validation de l’ordre de une à deux secondes. Il est à noter que la performance de plus de mille transactions par seconde est maintenue même dans des conditions de confrontation sévères, les validateurs bloquant ou diffusant des votes conçus de manière malveillante. Voir la figure ci-dessous pour plus de détails.

CLIENTS LÉGERS

L’un des principaux avantages de l’algorithme de consensus de Tendermint est la sécurité simplifiée des clients légers, ce qui en fait un candidat idéal pour les cas d’utilisation mobile et d’Internet des objets. Alors qu’un client Bitcoin light doit synchroniser les chaînes d’en-têtes de bloc et trouver celui qui contient le plus de preuves de travail, les clients Tendermint light doivent uniquement suivre les modifications apportées à l’ensemble des validateurs, puis vérifier les >⅔ PreCommits du dernier bloc pour déterminer le dernier état.

Les épreuves de client léger succinctes permettent également la communication entre les chaînes de blocs.

PRÉVENIR LES ATTAQUES

Tendermint dispose de mesures de protection pour empêcher certaines attaques notables, telles que la double dépense à long terme et rien en jeu et la censure. Celles-ci sont développées plus en détail en annexe.

ABCI

L’algorithme de consensus Tendermint est implémenté dans un programme appelé Tendermint Core. Tendermint Core est un «moteur de consensus» indépendant de toute application et capable de transformer toute application Blackbox déterministe en une chaîne de blocs répliquée de manière distribuée. Tendermint Core se connecte aux applications de la blockchain via l’interface ABCI (Application Blockchain Interface) [17]. ABCI est une interface qui définit la limite entre le moteur de réplication (la chaîne de blocs) et la machine à états (l’application). En utilisant un protocole de socket, nous permettons à un moteur de consensus s’exécutant dans un processus de gérer un état d’application s’exécutant dans un autre. Ainsi, ABCI permet aux applications blockchain d’être programmées dans n’importe quel langage, pas seulement le langage de programmation dans lequel le moteur de consensus est écrit. En outre, ABCI permet de remplacer facilement la couche consensus de toute pile de blockchain existante.

Nous faisons une analogie avec la célèbre crypto-monnaie Bitcoin. Bitcoin est une chaîne de blocs de crypto-monnaie dans laquelle chaque nœud conserve une base de données UTXO (Unspent Transaction Output) entièrement auditée. Si on voulait créer un système semblable à Bitcoin sur ABCI, Tendermint Core serait responsable de :

• Partage de blocs et de transactions entre nœuds
• Établir un ordre canonique / immuable de transactions (la blockchain)

Pendant ce temps, l’application ABCI serait responsable de

• Maintenir la base de données UTXO
• Validation des signatures cryptographiques des transactions
• Empêcher les transactions de dépenser des fonds inexistants
• Autoriser les clients à interroger la base de données UTXO

Tendermint est capable de décomposer la conception de la blockchain en proposant une API très simple entre le processus de candidature et le processus de consensus.

Cosmos, vue d’ensemble

Cosmos est un réseau de blockchains parallèles indépendantes, toutes alimentées par des algorithmes de consensus BFT classiques tels que Tendermint 1.

La première blockchain de ce réseau sera le hub Cosmos. Le hub Cosmos se connecte à de nombreuses autres chaînes de blocs (ou zones) via un nouveau protocole de communication inter-chaînes. Le hub Cosmos suit de nombreux types de jetons et enregistre le nombre total de jetons dans chaque zone connectée. Les jetons peuvent être transférés d’une zone à une autre rapidement et en toute sécurité, sans qu’il soit nécessaire de procéder à un échange de liquide entre zones, car tous les transferts de jetons entre zones passent par le hub Cosmos.

Cette architecture résout de nombreux problèmes auxquels l’espace de la blockchain est confrontée, tels que l’interopérabilité des applications, leur évolutivité et leur évolutivité transparente. Par exemple, des zones dérivées de Bitcoind, de Go-Ethereum, de CryptoNote, de ZCash ou de n’importe quel système blockchain peuvent être connectées au Cosmos Hub. Ces zones permettent à Cosmos de s’adapter à l’infini pour répondre à la demande de transactions mondiale. Les zones conviennent également parfaitement pour un échange distribué, qui sera également pris en charge.

Cosmos n’est pas un simple grand livre distribué, et le Hub Cosmos n’est pas un jardin clos ou le centre de son univers. Nous concevons un protocole pour un réseau ouvert de grands livres distribués pouvant servir de nouvelle base pour les futurs systèmes financiers, reposant sur les principes de la cryptographie, des principes économiques sains, de la théorie du consensus, de la transparence et de la responsabilité.

TENDERMINT-BFT

Cosmos Hub est la première blockchain publique du réseau Cosmos, optimisée par l’algorithme de consensus BFT de Tendermint. Le projet open source Tendermint a été créé en 2014 pour traiter les problèmes de rapidité, d’évolutivité et d’environnement de l’algorithme de consensus de validation de travail de Bitcoin. En utilisant et en améliorant les algorithmes BFT éprouvés développés au MIT en 1988 [20], l’équipe Tendermint a été la première à démontrer de manière conceptuelle une crypto-monnaie de preuve d’enjeu qui résout le problème du non-en-jeu subi par la preuve de la première génération des crypto-monnaies telles que NXT et BitShares1.0.

Aujourd’hui, pratiquement tous les portefeuilles mobiles Bitcoin utilisent des serveurs de confiance pour leur permettre de vérifier les transactions. En effet, la validation du travail nécessite l’attente de nombreuses confirmations avant qu’une transaction puisse être considérée comme irréversiblement engagée. Des attaques à double dépense ont déjà été démontrées sur des services tels que CoinBase.

Contrairement aux autres systèmes de consensus blockchain, Tendermint offre une vérification instantanée et sécurisée du paiement des clients mobiles. Etant donné que Tendermint est conçu pour ne jamais faire de fourchette, les portefeuilles mobiles peuvent recevoir une confirmation de transaction instantanée, ce qui permet aux paiements sans confiance et pratiques de devenir une réalité sur les smartphones. Cela a également des conséquences importantes pour les applications de l’Internet des objets.

Les validateurs dans Cosmos ont un rôle similaire à celui des mineurs Bitcoin, mais utilisent plutôt des signatures cryptographiques pour voter. Les validateurs sont des machines sécurisées et dédiées, responsables de la validation des blocs. Les non-validateurs peuvent déléguer leurs jetons de jalonnement (appelés «atomes») à tous validateur afin de gagner une partie des honoraires forfaitaires et des récompenses atomiques, mais ils courent le risque de se faire punir si le validateur délégué se fait pirater ou enfreint le protocole. Les garanties de sécurité éprouvées de Tendermint BFT consensus et le dépôt de garantie des parties prenantes (validateurs et mandataires) fournissent une sécurité quantifiable et prouvable pour les nœuds et les clients légers.

LA GOUVERNANCE

Les grands livres publics distribués devraient avoir une constitution et un système de gouvernance. Bitcoin s’appuie sur Bitcoin Foundation et sur l’exploitation pour coordonner les mises à niveau, mais le processus est lent. Ethereum s’est scindé en ETH et ETC après avoir tenté de résoudre le problème de TheDAO, en grande partie parce qu’il n’existait auparavant aucun contrat social ni aucun mécanisme permettant de prendre de telles décisions.

Les validateurs et les mandataires du Cosmos Hub peuvent voter sur des propositions pouvant modifier automatiquement les paramètres prédéfinis du système (comme la limite de gaz en bloc), coordonner les mises à niveau, ainsi que voter sur les amendements à la constitution lisible par l’homme qui régissent les règles du système Cosmos Hub. La constitution permet la cohésion des parties prenantes sur des questions telles que le vol et les bugs (tels que l’incident TheDAO), permettant ainsi une résolution plus rapide et plus propre.

Chaque zone peut également avoir sa propre constitution et son propre mécanisme de gouvernance. Par exemple, le Cosmos Hub peut avoir une constitution qui impose l’immuabilité sur le Hub (pas de restauration, à l’exception des bogues de l’implémentation du nœud Cosmos Hub), tandis que chaque zone peut définir ses propres règles en matière de restauration.

En permettant l’interopérabilité entre différentes zones politiques, le réseau Cosmos offre à ses utilisateurs une liberté ultime et un potentiel d’expérimentation sans autorisation.

Le hub et les zones

Nous décrivons ici un nouveau modèle de décentralisation et d’évolutivité. Cosmos est un réseau de nombreuses blockchains alimentées par Tendermint. Alors que les propositions existantes visent à créer une «chaîne de blocs unique» avec un ordre de transaction global total, Cosmos permet à plusieurs chaînes de blocs de s’exécuter simultanément tout en maintenant l’interopérabilité.

À la base, le Cosmos Hub gère de nombreuses chaînes de blocs indépendantes appelées «zones» (parfois appelées «fragments», en référence à la technique de mise à l’échelle de la base de données appelée «partage»). Un flux constant de commits de blocs récents à partir des zones postées sur le hub permet au hub de suivre l’état de chaque zone. De même, chaque zone suit l’état du hub (mais les zones ne se suivent pas entre elles, sauf indirectement via le hub). Des paquets d’informations sont ensuite communiqués d’une zone à une autre en affichant des preuves Merkle comme preuve que les informations ont été envoyées et reçues. Ce mécanisme est appelé communication inter-blockchain, ou IBC en abrégé.

Chacune des zones peut être elle-même un concentrateur pour former un graphe acyclique, mais dans un souci de clarté, nous ne décrirons que la configuration simple comportant un seul concentrateur et de nombreuses zones autres que des concentrateurs.

LE HUB

Cosmos Hub est une blockchain qui héberge un grand livre distribué multi-ressources, dans lequel les jetons peuvent être détenus par des utilisateurs individuels ou par des zones elles-mêmes. Ces jetons peuvent être déplacés d’une zone à l’autre dans un paquet IBC spécial appelé «paquet de pièces». Le concentrateur est responsable de la préservation de l’invariance globale de la quantité totale de chaque jeton dans les zones. Les transactions par paquets de pièces IBC doivent être validées par les chaînes de blocs expéditeur, concentrateur et destinataire.

Étant donné que le hub Cosmos joue le rôle de grand livre central pour l’ensemble du système, la sécurité du hub revêt une importance primordiale. Bien que chaque zone puisse constituer une suite de chaînes Tendermint sécurisée par 4 personnes au maximum (voire moins si le consensus BFT n’est pas nécessaire), le Hub doit être sécurisé par un ensemble de validateurs globalement décentralisés pouvant résister aux scénarios d’attaques les plus sévères, tels que comme une partition de réseau continental ou une attaque parrainée par un État-nation.

LES ZONES

Une zone Cosmos est une blockchain indépendante qui échange des messages IBC avec le Hub. Du point de vue du concentrateur, une zone est un compte à signatures multiples à adhésion dynamique multi-ressources pouvant envoyer et recevoir des jetons à l’aide de paquets IBC. À l’instar d’un compte de crypto-monnaie, une zone ne peut pas transférer plus de jetons qu’elle en a, mais peut en recevoir d’autres de ceux qui en ont. Une zone peut être désignée comme «source» d’un ou de plusieurs types de jetons, ce qui lui donne le pouvoir de gonfler cette offre de jetons.

Les validateurs d’une zone connectée au hub peuvent jalonner les atomes du hub Cosmos. Tandis que des attaques à double dépense sur ces zones entraîneraient la réduction d’atomes avec la responsabilité de Tendermint, une zone où >⅔ des droits de vote sont byzantins peut commettre un état invalide. Cosmos Hub ne vérifie ni n’exécute pas les transactions validées sur d’autres zones. Il incombe donc aux utilisateurs d’envoyer des jetons aux zones auxquelles ils font confiance. À l’avenir, le système de gouvernance du Cosmos Hub pourrait donner lieu à des propositions d’amélioration du Hub prenant en compte les défaillances de zone. Par exemple, les transferts de jetons sortants de certaines (ou de toutes) zones peuvent être limités afin de permettre la coupure de circuit d’urgence des zones (arrêt temporaire des transferts de jetons) lorsqu’une attaque est détectée.

Communication inter-blockchain (IBC)

Nous allons maintenant voir comment le hub et les zones communiquent entre eux. Par exemple, s’il existe trois blockchains, «Zone1», «Zone2» et «Hub», nous souhaitons que «Zone1» produise un paquet destiné à «Zone2» passant par «Hub». Pour déplacer un paquet d’une blockchain à une autre, une épreuve est postée sur la chaîne de réception. La preuve indique que la chaîne d’envoi a publié un paquet pour la destination alléguée. Pour que cette chaîne vérifie cette épreuve, la chaîne destinataire doit pouvoir suivre les en-têtes de bloc de l’expéditeur. Ce mécanisme est similaire à celui utilisé par sidechains, qui nécessite que deux chaînes en interaction se connaissent via un flux bidirectionnel de datagrammes de preuve d’existence (transactions).

Le protocole IBC peut naturellement être défini en utilisant deux types de transactions : une IBCBlockCommitTxtransaction, qui permet à une chaîne de blocs de prouver à tout observateur son dernier bloc de hachage, et une IBCPacketTxtransaction, qui permet à une chaîne de blocs de prouver à tout observateur que le paquet donné a bien été publié par l’application de l’expéditeur, via un code Merkle-proof au récent block-hash.

En scindant les mécanismes IBC en deux transactions distinctes, nous permettons au mécanisme de marché des taxes natif de la chaîne de réception de déterminer les paquets à valider (c’est-à-dire accusés de réception), tout en laissant une totale liberté sur la chaîne d’envoi quant au nombre de paquets sortants autorisés. .

Dans l’exemple ci-dessus, pour mettre à jour le hachage de bloc de «Zone1» sur «Hub» (ou de «Hub» sur «Zone2»), une IBCBlockCommitTx transaction doit être enregistrée sur «Hub» avec le hachage de bloc de «Zone1 ”(Ou sur“ Zone2 ”avec le bloc-hash de“ Hub ”).

Voir IBCBlockCommitTx et IBCPacketTx pour plus d’informations sur les deux types de transaction IBC.