Share Dialog
Share Dialog
Subscribe to Pipocho
Subscribe to Pipocho
subscribe://
Depuis que Satoshi Nakamoto a publié le White Paper sur le Bitcoin, nous avons assisté à une explosion de l'adoption des blockchains par les développeurs et les utilisateurs.
Cette augmentation de l'adoption a introduit une nouvelle série de problèmes, notamment autour des contraintes au niveau des couches de consensus, de réseau et d'application.
En raison de ces problèmes, les équipes ont sauté sur l'occasion d'introduire leurs propres solutions uniques pour résoudre ces limitations. Qu'il s'agisse de Solana et de sa tentative de construire une blockchain de layer 1 hautement performante ou d'Ethereum et de ses solutions de scalabilité de layer 2, les nouvelles approches n'ont pas manqué.
Aujourd'hui, nous allons nous plonger dans l’univers Cosmos, qui a adopté l'une des approches les plus uniques de la mise à l'échelle des blockchains. Plus précisément, au lieu de construire sur/autour d'une seule blockchain de layer 1, Cosmos a pris la décision de se pencher sur un avenir multi-chaîne composé de plusieurs blockchains spécialisées et souveraines qui sont interopérables grâce à une pile technologique commune.
Cosmos cherche à résoudre trois problèmes principaux de la blockchain : la gouvernance, la scalabilité et la durabilité. Ainsi, le réseau Cosmos est un réseau décentralisé de blockchains indépendantes, évolutives et interopérables, chacune étant alimentée par un mécanisme de consensus tolérant aux pannes byzantines (BFT) qu’est le Tendermint Core.
Dans un avenir multi-chain, vous pourriez conserver les propriétés de sécurité des blockchains de layer 1 tout en résolvant le problème de l'évolutivité (en répartissant les calculs/transactions entre différents layer 1. Cela permet également de mettre en place un concept appelé "blockchains spécifiques à une application" tel que décrit dans le blog “Why application-specific blockchains make sense”.
"Développer votre dApp comme une blockchain signifie que vous n'avez qu'à définir les types de transaction et les fonctions de transition d'état dont votre application a besoin. Cela augmentera considérablement les performances de l'application."
Il est affirmé que si de nombreuses blockchains se sont concentrées sur les couches de mise en réseau et de consensus, c'est en fait la couche application qui constitue le véritable goulot d'étranglement.
En effet, les blockchains spécifiques à une application offrent des avantages supplémentaires tels que la sécurité (puisque les machines virtuelles offrent une large surface d'attaque) et la gouvernance (la gouvernance peut être gérée sur une base individuelle, application par application).
Désormais, il existe donc deux modèles avec chacun leurs forces et leurs faiblesses, et les développeurs doivent opter pour celui qui convient le mieux à leur cas d'utilisation:
La couche application d’une blockchain peut-être une machine virtuelle (ex: EVM pour Ethereum) et les applications décentralisées (dApp) sont construites par-dessus.
Une application décentralisée peut-être construite directement sous forme de blockchain spécifique.
Développons dès à présent les caractéristiques principales de Cosmos :
Tendermint (Tendermint Core + ABCI)
Cosmos SDK
Protocole Inter-Blockchain Communication (IBC)
Jusqu'à récemment, les trois couches, Application, Consensus et Réseau, étaient toutes nécessaires pour construire une blockchain.
Sur Bitcoin, la couche d’application est intégrée au reste du protocole, les seules applications pouvant y exister sont celles qui ont été développé par son créateur: dans ce cas là, une application de paiement seulement.
Puis, Ethereum a séparé la couche d’application de celle de réseau et de consensus. Ethereum a donc simplifié le développement des dApps sur les blockchains avec l'EVM.
Tendermint est un ensemble d'outils et de technologies prêts à l'emploi pour la mise en œuvre des couches de consensus et de mise en réseau des projets blockchain. Tendermint s’apparente donc à un moteur blockchain puisque les différentes couches de chaque projet blockchain peuvent être séparées.
Avec cette approche, les développeurs sont plus flexibles et peuvent se concentrer uniquement sur la couche d’application. Ainsi, le temps de développement d’une application blockchain est considérablement réduit.
A noter que c’est le rôle de la couche application de définir la composition du groupe de validateurs. Les développeurs peuvent donc créer des blockchains publiques (en PoS) et privées (en PoA) mais pas en PoW car elles ont une finalité probabiliste de par leur couche consensus (cf. plus bas). Dans les deux cas, les validateurs ne valident que les transactions spécifiques à l'application. Si votre application présente un problème, la gouvernance peut le résoudre sans gêner les autres applications de l'écosystème.
En revanche, si un problème survient dans une application décentralisée construite au-dessus d'une machine virtuelle, rien ne pourra être fait pour le résoudre si la gouvernance de la blockchain sous-jacente n'y consent pas. Par exemple, si une application décentralisée construite sur Ethereum est piratée et que des fonds sont volés, il ne sera pas possible de réparer les dégâts si la communauté Ethereum ne le veut pas. (ex: piratage de Parity multisig). A l’inverse une VM est utile si vous ne voulez pas déployer un réseau de validateurs pour votre application.
Explorons maintenant plus en détail les deux principaux composants de Tendermint:
A. Tendermint Core (mécanisme de consensus)
B. ABCI (l'API de la couche réseau).
Le mécanisme de consensus de Tendermint est appelé Tendermint Core et est alimenté par le modèle de consensus Byzantine Fault Tolerant (BFT), un modèle sûr et fiable pour atteindre le consensus entre les nœuds. En termes simples, Byzantine signifie traître (ou mauvais acteur), et le modèle BFT peut tolérer qu’1/3 des validateurs byzantins parviennent à un consensus.
Le processus BFT résumé en quatre étapes principales :
Propose : un nouveau validateur propose un nouveau bloc.
Pré-voter (première étape du vote) : au moins 2/3 des validateurs pré-votent pour le bloc proposé.
Pré-valider (deuxième étape du vote) : au moins 2/3 des validateurs pré-valide le bloc proposé.
Valider: le validateur valide le bloc proposé sur la blockchain.
À chaque étape, si quelque chose ne va pas, il existe certaines règles et conditions pour faire face à la situation. Par exemple, si un validateur ne parvient pas à valider un bloc, les autres validateurs ignorent ce bloc après un certain temps d'attente et passent au tour de décision suivant (cf. “New Round” sur le schéma).
Par contre, pour atteindre le consensus et propager les transactions/blocs, les validateurs doivent communiquer entre eux à travers les différentes étapes décrites précédemment (pré-voter, pré-valider, valider). Par conséquent, le débit de l'ensemble du système dépend fortement du nombre de validateurs. Plus il y a de validateurs dans le système, plus le débit sera faible.
L'interface Application Blockchain (ABCI) est un ensemble de méthodes prêtes à l'emploi pour connecter le mécanisme de consensus (Tendermint Core) à la logique de la couche application. Par conséquent, l'ABCI est le principal composant de la couche de mise en réseau, et tous les messages et transactions doivent être acheminés par l'ABCI. Il peut y avoir plusieurs connexions de socket ABCI à une application.
Voici les plus importantes :
CheckTx : ce message peut être utilisé pour accepter ou rejeter des transactions, avant qu'elles ne soient stockées en mémoire ou communiquées aux autres pairs.
BeginBlock : un programme qui est appelé avant chaque nouveau bloc qui a été accepté par au moins 2/3 des validateurs.
DeliverTx : invoque la logique applicative pour interpréter, traiter la transaction et mettre à jour l'état.
EndBlock : un programme pour terminer le traitement de chaque bloc.
Commit : pour finaliser le traitement du bloc.
Il convient également de mentionner que ABCI est, à la base, un ensemble d'appels d'API. Par conséquent, les développeurs ont toute latitude pour utiliser différents langages de programmation (par exemple Solidity, Rust, C++) afin d'utiliser ces méthodes dans leur couche d'application.
Même si Tendermint réduit le temps de développement d'une blockchain de plusieurs années à quelques semaines, la construction d'une application blockchain sécurisée à partir de zéro reste une tâche difficile. Le Cosmos SDK (software developement kit) est un cadre modulaire qui simplifie le processus de création d'applications de blockchain sécurisées.
Il est basé sur deux principes majeurs :
Modularité : Créer un écosystème de modules qui permet aux développeurs de créer facilement des blockchains spécifiques à une application sans avoir à coder chaque élément de fonctionnalité à partir de zéro.
Sécurité basée sur les capacités : La possibilité de définir des limites de sécurité entre ces modules pour mieux les interpréter tout en limitant la portée des interactions malveillantes et/ou indésirables.
Le Cosmos SDK est livré avec un ensemble d'outils permettant de construire la couche de l'application: des interfaces de ligne de commande (CLI), des serveurs REST et une variété d'autres bibliothèques utilitaires. Comme il est conçu pour être modulaire, les développeurs peuvent l’utiliser en conjonction avec Tendermint Core et ABCI pour utiliser les fonctionnalités existantes du mécanisme de consensus et de la couche de mise réseau.
Avec l'aide de Tendermint (Tendermint Core + ABCI) et du Cosmos SDK, les développeurs ont désormais un moyen de construire rapidement des blockchains sécurisées et personnalisées. Avec l'aide du protocole Inter-Blockchain Communication (IBC) open-source, ces blockchains peuvent maintenant être connectées entre elles. C’est un protocole qui exploite la propriété de finalité instantanée* du consensus Tendermint Core pour permettre à différentes blockchains de communiquer entre elles, leur permettant de transférer des tokens et d'autres données en toute confiance.
Pensez-y de cette façon : Les dApps peuvent facilement interagir les unes avec les autres, quelles que soient les différences entre les règles et les protocoles qui existent sur des blockchains distinctes, comme des galaxies ou des systèmes stellaires uniques dans un univers où les lois de la physique s'appliquent à tous.
*La finalité est instantanée signifie qu’il n'est pas nécessaire d'attendre des confirmations (que d’autre blocs soient validés) pour s’assurer que la transaction est valide. Les forks de blocs ne sont jamais créés, tant que moins d’1/3 des validateurs sont malveillants (byzantin). Les utilisateurs peuvent être sûrs que leurs transactions sont finalisées dès qu’un bloc est créé. Au contraire, sur Bitcoin il est recommandé d’attendre un minimum de 6 blocs et sur Ethereum plusieurs dizaines de blocs, soit plusieurs minutes avant de considérer une transaction comme finalisée et valide. Cela va dépendre de la puissance de calcul (taux de hachage) consacrée à la sécurisation de la blockchain.
La plupart des bridges inter-chaînes sont construits par des tiers indépendants et leur sécurité varient considérablement en fonction des protocoles avec lesquels ils interagissent, ce qui peut compromettre leur sécurité et offrir une expérience déplorable. Mais contrairement à de nombreuses solutions de bridges inter-chaînes, le protocole de communication inter-blockchain (IBC) ne dépend pas d'un intermédiaire pour vérifier la validité des transactions inter-chaînes.
C’est un protocole qui oriente les connexions, de bout en bout, avec état, qui permet aux modules sur des systèmes distribués distincts de communiquer de manière fiable, ordonnée et authentifiée. C’est un protocole qui permet aux blockchains de se connecter les unes aux autres.
L'IBC définit la manière dont les données sont envoyées et reconnues sur les blockchains, mais ne définit pas la nature de ces données ni la manière dont elles doivent être structurées. La promesse étant de fournir une couche de base fiable, sans permission et générique (TAO), tout en permettant la composabilité et la modularité avec la séparation des préoccupations en déplaçant les conceptions d'application vers une couche de niveau supérieur (APP).
En effet, l’IBC se compose en deux couches :
La couche transport et réseau (TAO pour transport, autorisation, organisation) fournit l'infrastructure nécessaire pour établir des connexions sécurisées et authentifier les paquets de données entre les chaînes.
Cette couche est implémentée sous forme de smart-contracts appelés “TAO module” qui fonctionnent sur les deux blockchains connectées l'une à l'autre via IBC. Ils sont composés d’on-chain light client pour vérifier que les états présentés existent réellement sur la blockchain opposée sans s’appuyer sur des tiers de confiance, connection abstraction et channel abstraction pour connecter les 2 smart-contracts sur les 2 blockchains et relayer les paquets de données.
La couche application (APP) est construite par-dessus la couche transport et définit exactement comment les paquets de données doivent être conditionnés et interprétés par les chaînes émettrices et réceptrices. C’est donc la couche avec laquelle les utilisateurs finaux interagissent.
Grosso modo, la couche transport et réseau (TAO) de l'IBC peut être considérée comme le service postal et les paquets de données comme l’enveloppe. En dernier lieu, la couche d’application (APP) peut être considérée comme le récepteur chargé d'ouvrir l'enveloppe et d'interpréter le contenu de la lettre.
Exemple 1: IBC entre chaînes homogènes (chaînes existantes au sein de l'écosystème Cosmos et utilisant Tendermint)
La chaîne A verrouille les jetons et transmet la preuve à la chaîne B. Une fois la vérification effectuée, la chaîne B mint ses propres tokens représentatifs (un peu comme des justificatifs), qui peuvent ensuite être détruits pour déverrouiller les tokens originaux de la chaîne A. La valeur que les jetons représentent peut donc être transférée d'une chaîne à l'autre, mais pas le jeton lui-même.
Exemple 2: IBC et blockchains non-Tendermint/hétérogènes (Bitcoin & Ethereum dans cet exemple)
Il est important d'avoir la certitude qu'un bloc est permanent afin d'avoir la certitude qu'une modification du solde d'un compte est permanente. Une Peg-Zone peut fixer un nombre supposé de blocs (un seuil de finalité) afin de permettre de manière plus sûre un transfert de la valeur de tokens vers l'écosystème Cosmos. Si cette transaction n'est pas permanente, la chaîne B pourrait mint des tokens représentatifs (justificatifs) qui garantissent des jetons qui ne sont pas réellement verrouillés sur la chaîne A.
L'IBC permet à deux blockchains de se transférer des tokens, mais à partir de là, comment créer un réseau de blockchains ? Vous pourriez connecter chaque blockchain du réseau à toutes les autres blockchains via des connexions IBC directes, mais le problème est que le nombre de connexions dans le réseau croît de manière quadratique avec le nombre de blockchains. Ainsi, 100 blockchains dans le réseau qui doivent chacune maintenir une connexion IBC, cela donne 4950 connexions. Pour résoudre ce problème, Cosmos vise une architecture modulaire avec deux classes de blockchains : les Hubs et les Zones.
Les Zones sont des blockchains ordinaires faisant tourner une ou plusieurs services décentralisés tandis que les Hubs sont des blockchains spécialement conçues pour connecter les Zones entre elles. Une fois qu'une Zone crée une connexion IBC avec un Hub, elle a automatiquement accès à toutes les autres Zones qui lui sont connectées. Cela signifie que chaque Zone n'a besoin d'établir qu'un nombre limité de connexions avec un ensemble de Hubs.
Le premier écosystème connecté à Cosmos est Ethereum. Cela passe par le développement de peg-zone, pour connecter la chaîne Ethereum principale, et de EVMOS (anciennement Ethermint), une blockchain faisant tourner la machine virtuelle de Ethereum (EVM) et compatible avec IBC.
Au cœur de l'écosystème Cosmos se trouve le Cosmos Hub et son token ATOM natif. Le Cosmos Hub a ouvert une nouvelle ère dans l'industrie des blockchains en devenant la première blockchain publique de type PoS (Proof-of-Stake) construite sur un mécanisme de consensus BFT. Le Cosmos Hub est appelé à jouer un rôle majeur dans l'interchain en offrant une grande variété de services et fonctionnalités (Staking, Voting, Interchain Account…). Chaque nouveau service sur le Hub génère des frais, et les frais génèrent des récompenses. Plus il y a d'activité sur le Hub, plus les services versent de frais et plus les holder d'ATOM reçoivent de récompenses.
D’autre part, les développeurs se sont rendus compte que la sécurité de ces réseaux n’est pas tout à fait parfaite. Lorsque l’on utilise la preuve d’enjeu, la sécurité du réseau est indirectement liée a la valeur des actifs placés en garantie. Plus la valeur est élevée, plus le réseau est difficile à attaquer. Les validateurs malhonnête ne prennent le risque d’attaquer le réseau que dans le cas où ils peuvent faire un paris qui ne leur coûte pas grand chose s’ils sont perdants. C’est donc d’autant plus vrai sur un réseau à faible capitalisation.
La valeur de l’enjeu verrouillé sur le Cosmos Hub est utilisé pour garantir la sécurité des consumer chain ****de moindre importance qui ont choisis d’y avoir recours. Si le validateur fait un mauvais travail en produisant des blocs sur l'une ou l'autre chaîne, il risque de voir ses tokens ATOMs détruits par un mécanisme appelé "slashing". En contrepartie, les validateurs participants gèrent deux nodes, l'un pour le Cosmos Hub et l'autre pour la consumer chain, et reçoivent des droits et des récompenses sur les deux chain. A noter que l’Interchain Security est permise grâce au protocole spécifique Cross Chain Validation de l’IBC (Inter-Blockchain Communication).
Cette sécurité inter-chaînes supprime la nécessité pour les nouvelles chaînes de créer leur propre ensemble de validateurs.
Dans un cadre traditionnel, l'utilisateur final se connecte à une interface représentant la chaîne A et transmet un actif à la chaîne B via une transaction IBC. L'utilisateur doit ensuite se connecter à une autre interface, représentant cette fois la chaîne B, et effectuer le reste du flux.
Interchain Account permet d'utiliser un compte virtuel pour utiliser le smart-contract sur une autre blockchain, ce qui permet à l'utilisateur de réaliser l'ensemble du flux tout en améliorant son expérience puisque les chaînes se passent l’ensemble des d'instructions et exécutent les transactions de manière invisible - le tout sans que l'utilisateur ait à quitter la première interface.
Cela signifie que toute action telle que les transferts, le jalonnement ou le vote sur des propositions de gouvernance qui peut être effectuée sur B (appelée la "chaîne hôte"), peut être effectuée à partir de A (appelée la "chaîne contrôleur").
En d’autre terme, les ICA permettent une composabilité native dans les transactions cross-chain, ce qui permettra aux chaînes non seulement d'échanger des données, mais aussi d'écrire des états, au lieu d'obliger l'utilisateur final à se déplacer entre différentes interfaces au fur et à mesure qu'un actif se déplace.
Pour rappel, un système composable est un système dont les différents composants peuvent être découplés, remaniés et réintégrés en tant que blocs de construction dans des systèmes plus vastes. La composabilité est ce qui permet à un ensemble d'être meilleur que la somme de ses parties. L'activation de la composabilité dans l'IBC permet de déployer l'innovation dans des applications distinctes sans avoir à mettre à niveau l'ensemble de l'Interchain, ce qui fournit un modèle d'innovation plus évolutif qui préserve la compatibilité.
En conclusion, le réseau de blockchain Cosmos s’articule autour d’une suite de logiciel Tendermint (Core + ABCI), d’un ensemble d'outils Cosmos SDK et d’un protocole de réseau IBC afin de construire des blockchains spécifiques à une application.
Tendermint (Core + ABCI) permet d’avoir un temps de blocs de quelque secondes, de gérer des centaines de transactions par seconde et d’avoir une finalité instantanée à la publication du bloc sans sacrifier la sécurité. Par contre, le nombre de validateur est beaucoup plus limité à cause de la communication qui doit avoir lieu entre eux pour faire tourner le réseau. Le max théorique est de 300 validateurs mais en pratique la plupart des blockchains basées sur Tendermint ont 100 validateurs ou moins. Même le Cosmos Hub ne supporterait que 175 validateurs, sûrement pour ne pas sacrifier le débit.
le protocole de réseau (IBC) basé sur des chaines dédiées: un réseau de réseaux. Plutôt que d’avoir une seule chaîne avec toutes les applications possibles, elle est constituée d’une multitude de consumer chain spécialisées et indépendante. La solution proposée par Cosmos est de mettre en place un protocole de communication à vocation universel et qui permet de communiquer avec d’autre chaines sans passer par un bridge: le protocole IBC. On peut donc envoyer tout un tas de chose (de simple messages, des actifs fongibles ou pas, une requête pour utiliser une fonction dans un smart-contract, des flux de donnés utilisés par des oracles…). Par exemple, Avalanche pourrait implémenter le protocole IBC, ce qui rendrait tout cet écosystème directement connecté à toutes les chaines Cosmos.
Finalement, il faut une couche d’application à rajouter par dessus. Le Cosmos SDK (software developement kit) est un kit de développement dans lequel on retrouve une liste de module qui couvre la preuve d’enjeu, la gouvernance, les situation de crises, la création de nouveau jeton… en d’autre termes une base de librairie qui permet de très rapidement lancer des solutions sans avoir à re-développer. Tout est pré-développé, il suffit juste de rajouter des paramètres et des bouts de codes.
collect://
Source:
https://blogchaincafe.com/cosmos-un-bref-apercu
https://research.thetie.io/a-journey-through-the-cosmos-atom/
https://medium.com/coinmonks/tendermint-cosmos-sdk-demystified-47385cf77cf6
https://web3pills.substack.com/p/a-deep-dive-on-cosmos?sd=pf
https://blog.cosmos.network/why-application-specific-blockchains-make-sense-32f2073bfb37
subscribe://
Depuis que Satoshi Nakamoto a publié le White Paper sur le Bitcoin, nous avons assisté à une explosion de l'adoption des blockchains par les développeurs et les utilisateurs.
Cette augmentation de l'adoption a introduit une nouvelle série de problèmes, notamment autour des contraintes au niveau des couches de consensus, de réseau et d'application.
En raison de ces problèmes, les équipes ont sauté sur l'occasion d'introduire leurs propres solutions uniques pour résoudre ces limitations. Qu'il s'agisse de Solana et de sa tentative de construire une blockchain de layer 1 hautement performante ou d'Ethereum et de ses solutions de scalabilité de layer 2, les nouvelles approches n'ont pas manqué.
Aujourd'hui, nous allons nous plonger dans l’univers Cosmos, qui a adopté l'une des approches les plus uniques de la mise à l'échelle des blockchains. Plus précisément, au lieu de construire sur/autour d'une seule blockchain de layer 1, Cosmos a pris la décision de se pencher sur un avenir multi-chaîne composé de plusieurs blockchains spécialisées et souveraines qui sont interopérables grâce à une pile technologique commune.
Cosmos cherche à résoudre trois problèmes principaux de la blockchain : la gouvernance, la scalabilité et la durabilité. Ainsi, le réseau Cosmos est un réseau décentralisé de blockchains indépendantes, évolutives et interopérables, chacune étant alimentée par un mécanisme de consensus tolérant aux pannes byzantines (BFT) qu’est le Tendermint Core.
Dans un avenir multi-chain, vous pourriez conserver les propriétés de sécurité des blockchains de layer 1 tout en résolvant le problème de l'évolutivité (en répartissant les calculs/transactions entre différents layer 1. Cela permet également de mettre en place un concept appelé "blockchains spécifiques à une application" tel que décrit dans le blog “Why application-specific blockchains make sense”.
"Développer votre dApp comme une blockchain signifie que vous n'avez qu'à définir les types de transaction et les fonctions de transition d'état dont votre application a besoin. Cela augmentera considérablement les performances de l'application."
Il est affirmé que si de nombreuses blockchains se sont concentrées sur les couches de mise en réseau et de consensus, c'est en fait la couche application qui constitue le véritable goulot d'étranglement.
En effet, les blockchains spécifiques à une application offrent des avantages supplémentaires tels que la sécurité (puisque les machines virtuelles offrent une large surface d'attaque) et la gouvernance (la gouvernance peut être gérée sur une base individuelle, application par application).
Désormais, il existe donc deux modèles avec chacun leurs forces et leurs faiblesses, et les développeurs doivent opter pour celui qui convient le mieux à leur cas d'utilisation:
La couche application d’une blockchain peut-être une machine virtuelle (ex: EVM pour Ethereum) et les applications décentralisées (dApp) sont construites par-dessus.
Une application décentralisée peut-être construite directement sous forme de blockchain spécifique.
Développons dès à présent les caractéristiques principales de Cosmos :
Tendermint (Tendermint Core + ABCI)
Cosmos SDK
Protocole Inter-Blockchain Communication (IBC)
Jusqu'à récemment, les trois couches, Application, Consensus et Réseau, étaient toutes nécessaires pour construire une blockchain.
Sur Bitcoin, la couche d’application est intégrée au reste du protocole, les seules applications pouvant y exister sont celles qui ont été développé par son créateur: dans ce cas là, une application de paiement seulement.
Puis, Ethereum a séparé la couche d’application de celle de réseau et de consensus. Ethereum a donc simplifié le développement des dApps sur les blockchains avec l'EVM.
Tendermint est un ensemble d'outils et de technologies prêts à l'emploi pour la mise en œuvre des couches de consensus et de mise en réseau des projets blockchain. Tendermint s’apparente donc à un moteur blockchain puisque les différentes couches de chaque projet blockchain peuvent être séparées.
Avec cette approche, les développeurs sont plus flexibles et peuvent se concentrer uniquement sur la couche d’application. Ainsi, le temps de développement d’une application blockchain est considérablement réduit.
A noter que c’est le rôle de la couche application de définir la composition du groupe de validateurs. Les développeurs peuvent donc créer des blockchains publiques (en PoS) et privées (en PoA) mais pas en PoW car elles ont une finalité probabiliste de par leur couche consensus (cf. plus bas). Dans les deux cas, les validateurs ne valident que les transactions spécifiques à l'application. Si votre application présente un problème, la gouvernance peut le résoudre sans gêner les autres applications de l'écosystème.
En revanche, si un problème survient dans une application décentralisée construite au-dessus d'une machine virtuelle, rien ne pourra être fait pour le résoudre si la gouvernance de la blockchain sous-jacente n'y consent pas. Par exemple, si une application décentralisée construite sur Ethereum est piratée et que des fonds sont volés, il ne sera pas possible de réparer les dégâts si la communauté Ethereum ne le veut pas. (ex: piratage de Parity multisig). A l’inverse une VM est utile si vous ne voulez pas déployer un réseau de validateurs pour votre application.
Explorons maintenant plus en détail les deux principaux composants de Tendermint:
A. Tendermint Core (mécanisme de consensus)
B. ABCI (l'API de la couche réseau).
Le mécanisme de consensus de Tendermint est appelé Tendermint Core et est alimenté par le modèle de consensus Byzantine Fault Tolerant (BFT), un modèle sûr et fiable pour atteindre le consensus entre les nœuds. En termes simples, Byzantine signifie traître (ou mauvais acteur), et le modèle BFT peut tolérer qu’1/3 des validateurs byzantins parviennent à un consensus.
Le processus BFT résumé en quatre étapes principales :
Propose : un nouveau validateur propose un nouveau bloc.
Pré-voter (première étape du vote) : au moins 2/3 des validateurs pré-votent pour le bloc proposé.
Pré-valider (deuxième étape du vote) : au moins 2/3 des validateurs pré-valide le bloc proposé.
Valider: le validateur valide le bloc proposé sur la blockchain.
À chaque étape, si quelque chose ne va pas, il existe certaines règles et conditions pour faire face à la situation. Par exemple, si un validateur ne parvient pas à valider un bloc, les autres validateurs ignorent ce bloc après un certain temps d'attente et passent au tour de décision suivant (cf. “New Round” sur le schéma).
Par contre, pour atteindre le consensus et propager les transactions/blocs, les validateurs doivent communiquer entre eux à travers les différentes étapes décrites précédemment (pré-voter, pré-valider, valider). Par conséquent, le débit de l'ensemble du système dépend fortement du nombre de validateurs. Plus il y a de validateurs dans le système, plus le débit sera faible.
L'interface Application Blockchain (ABCI) est un ensemble de méthodes prêtes à l'emploi pour connecter le mécanisme de consensus (Tendermint Core) à la logique de la couche application. Par conséquent, l'ABCI est le principal composant de la couche de mise en réseau, et tous les messages et transactions doivent être acheminés par l'ABCI. Il peut y avoir plusieurs connexions de socket ABCI à une application.
Voici les plus importantes :
CheckTx : ce message peut être utilisé pour accepter ou rejeter des transactions, avant qu'elles ne soient stockées en mémoire ou communiquées aux autres pairs.
BeginBlock : un programme qui est appelé avant chaque nouveau bloc qui a été accepté par au moins 2/3 des validateurs.
DeliverTx : invoque la logique applicative pour interpréter, traiter la transaction et mettre à jour l'état.
EndBlock : un programme pour terminer le traitement de chaque bloc.
Commit : pour finaliser le traitement du bloc.
Il convient également de mentionner que ABCI est, à la base, un ensemble d'appels d'API. Par conséquent, les développeurs ont toute latitude pour utiliser différents langages de programmation (par exemple Solidity, Rust, C++) afin d'utiliser ces méthodes dans leur couche d'application.
Même si Tendermint réduit le temps de développement d'une blockchain de plusieurs années à quelques semaines, la construction d'une application blockchain sécurisée à partir de zéro reste une tâche difficile. Le Cosmos SDK (software developement kit) est un cadre modulaire qui simplifie le processus de création d'applications de blockchain sécurisées.
Il est basé sur deux principes majeurs :
Modularité : Créer un écosystème de modules qui permet aux développeurs de créer facilement des blockchains spécifiques à une application sans avoir à coder chaque élément de fonctionnalité à partir de zéro.
Sécurité basée sur les capacités : La possibilité de définir des limites de sécurité entre ces modules pour mieux les interpréter tout en limitant la portée des interactions malveillantes et/ou indésirables.
Le Cosmos SDK est livré avec un ensemble d'outils permettant de construire la couche de l'application: des interfaces de ligne de commande (CLI), des serveurs REST et une variété d'autres bibliothèques utilitaires. Comme il est conçu pour être modulaire, les développeurs peuvent l’utiliser en conjonction avec Tendermint Core et ABCI pour utiliser les fonctionnalités existantes du mécanisme de consensus et de la couche de mise réseau.
Avec l'aide de Tendermint (Tendermint Core + ABCI) et du Cosmos SDK, les développeurs ont désormais un moyen de construire rapidement des blockchains sécurisées et personnalisées. Avec l'aide du protocole Inter-Blockchain Communication (IBC) open-source, ces blockchains peuvent maintenant être connectées entre elles. C’est un protocole qui exploite la propriété de finalité instantanée* du consensus Tendermint Core pour permettre à différentes blockchains de communiquer entre elles, leur permettant de transférer des tokens et d'autres données en toute confiance.
Pensez-y de cette façon : Les dApps peuvent facilement interagir les unes avec les autres, quelles que soient les différences entre les règles et les protocoles qui existent sur des blockchains distinctes, comme des galaxies ou des systèmes stellaires uniques dans un univers où les lois de la physique s'appliquent à tous.
*La finalité est instantanée signifie qu’il n'est pas nécessaire d'attendre des confirmations (que d’autre blocs soient validés) pour s’assurer que la transaction est valide. Les forks de blocs ne sont jamais créés, tant que moins d’1/3 des validateurs sont malveillants (byzantin). Les utilisateurs peuvent être sûrs que leurs transactions sont finalisées dès qu’un bloc est créé. Au contraire, sur Bitcoin il est recommandé d’attendre un minimum de 6 blocs et sur Ethereum plusieurs dizaines de blocs, soit plusieurs minutes avant de considérer une transaction comme finalisée et valide. Cela va dépendre de la puissance de calcul (taux de hachage) consacrée à la sécurisation de la blockchain.
La plupart des bridges inter-chaînes sont construits par des tiers indépendants et leur sécurité varient considérablement en fonction des protocoles avec lesquels ils interagissent, ce qui peut compromettre leur sécurité et offrir une expérience déplorable. Mais contrairement à de nombreuses solutions de bridges inter-chaînes, le protocole de communication inter-blockchain (IBC) ne dépend pas d'un intermédiaire pour vérifier la validité des transactions inter-chaînes.
C’est un protocole qui oriente les connexions, de bout en bout, avec état, qui permet aux modules sur des systèmes distribués distincts de communiquer de manière fiable, ordonnée et authentifiée. C’est un protocole qui permet aux blockchains de se connecter les unes aux autres.
L'IBC définit la manière dont les données sont envoyées et reconnues sur les blockchains, mais ne définit pas la nature de ces données ni la manière dont elles doivent être structurées. La promesse étant de fournir une couche de base fiable, sans permission et générique (TAO), tout en permettant la composabilité et la modularité avec la séparation des préoccupations en déplaçant les conceptions d'application vers une couche de niveau supérieur (APP).
En effet, l’IBC se compose en deux couches :
La couche transport et réseau (TAO pour transport, autorisation, organisation) fournit l'infrastructure nécessaire pour établir des connexions sécurisées et authentifier les paquets de données entre les chaînes.
Cette couche est implémentée sous forme de smart-contracts appelés “TAO module” qui fonctionnent sur les deux blockchains connectées l'une à l'autre via IBC. Ils sont composés d’on-chain light client pour vérifier que les états présentés existent réellement sur la blockchain opposée sans s’appuyer sur des tiers de confiance, connection abstraction et channel abstraction pour connecter les 2 smart-contracts sur les 2 blockchains et relayer les paquets de données.
La couche application (APP) est construite par-dessus la couche transport et définit exactement comment les paquets de données doivent être conditionnés et interprétés par les chaînes émettrices et réceptrices. C’est donc la couche avec laquelle les utilisateurs finaux interagissent.
Grosso modo, la couche transport et réseau (TAO) de l'IBC peut être considérée comme le service postal et les paquets de données comme l’enveloppe. En dernier lieu, la couche d’application (APP) peut être considérée comme le récepteur chargé d'ouvrir l'enveloppe et d'interpréter le contenu de la lettre.
Exemple 1: IBC entre chaînes homogènes (chaînes existantes au sein de l'écosystème Cosmos et utilisant Tendermint)
La chaîne A verrouille les jetons et transmet la preuve à la chaîne B. Une fois la vérification effectuée, la chaîne B mint ses propres tokens représentatifs (un peu comme des justificatifs), qui peuvent ensuite être détruits pour déverrouiller les tokens originaux de la chaîne A. La valeur que les jetons représentent peut donc être transférée d'une chaîne à l'autre, mais pas le jeton lui-même.
Exemple 2: IBC et blockchains non-Tendermint/hétérogènes (Bitcoin & Ethereum dans cet exemple)
Il est important d'avoir la certitude qu'un bloc est permanent afin d'avoir la certitude qu'une modification du solde d'un compte est permanente. Une Peg-Zone peut fixer un nombre supposé de blocs (un seuil de finalité) afin de permettre de manière plus sûre un transfert de la valeur de tokens vers l'écosystème Cosmos. Si cette transaction n'est pas permanente, la chaîne B pourrait mint des tokens représentatifs (justificatifs) qui garantissent des jetons qui ne sont pas réellement verrouillés sur la chaîne A.
L'IBC permet à deux blockchains de se transférer des tokens, mais à partir de là, comment créer un réseau de blockchains ? Vous pourriez connecter chaque blockchain du réseau à toutes les autres blockchains via des connexions IBC directes, mais le problème est que le nombre de connexions dans le réseau croît de manière quadratique avec le nombre de blockchains. Ainsi, 100 blockchains dans le réseau qui doivent chacune maintenir une connexion IBC, cela donne 4950 connexions. Pour résoudre ce problème, Cosmos vise une architecture modulaire avec deux classes de blockchains : les Hubs et les Zones.
Les Zones sont des blockchains ordinaires faisant tourner une ou plusieurs services décentralisés tandis que les Hubs sont des blockchains spécialement conçues pour connecter les Zones entre elles. Une fois qu'une Zone crée une connexion IBC avec un Hub, elle a automatiquement accès à toutes les autres Zones qui lui sont connectées. Cela signifie que chaque Zone n'a besoin d'établir qu'un nombre limité de connexions avec un ensemble de Hubs.
Le premier écosystème connecté à Cosmos est Ethereum. Cela passe par le développement de peg-zone, pour connecter la chaîne Ethereum principale, et de EVMOS (anciennement Ethermint), une blockchain faisant tourner la machine virtuelle de Ethereum (EVM) et compatible avec IBC.
Au cœur de l'écosystème Cosmos se trouve le Cosmos Hub et son token ATOM natif. Le Cosmos Hub a ouvert une nouvelle ère dans l'industrie des blockchains en devenant la première blockchain publique de type PoS (Proof-of-Stake) construite sur un mécanisme de consensus BFT. Le Cosmos Hub est appelé à jouer un rôle majeur dans l'interchain en offrant une grande variété de services et fonctionnalités (Staking, Voting, Interchain Account…). Chaque nouveau service sur le Hub génère des frais, et les frais génèrent des récompenses. Plus il y a d'activité sur le Hub, plus les services versent de frais et plus les holder d'ATOM reçoivent de récompenses.
D’autre part, les développeurs se sont rendus compte que la sécurité de ces réseaux n’est pas tout à fait parfaite. Lorsque l’on utilise la preuve d’enjeu, la sécurité du réseau est indirectement liée a la valeur des actifs placés en garantie. Plus la valeur est élevée, plus le réseau est difficile à attaquer. Les validateurs malhonnête ne prennent le risque d’attaquer le réseau que dans le cas où ils peuvent faire un paris qui ne leur coûte pas grand chose s’ils sont perdants. C’est donc d’autant plus vrai sur un réseau à faible capitalisation.
La valeur de l’enjeu verrouillé sur le Cosmos Hub est utilisé pour garantir la sécurité des consumer chain ****de moindre importance qui ont choisis d’y avoir recours. Si le validateur fait un mauvais travail en produisant des blocs sur l'une ou l'autre chaîne, il risque de voir ses tokens ATOMs détruits par un mécanisme appelé "slashing". En contrepartie, les validateurs participants gèrent deux nodes, l'un pour le Cosmos Hub et l'autre pour la consumer chain, et reçoivent des droits et des récompenses sur les deux chain. A noter que l’Interchain Security est permise grâce au protocole spécifique Cross Chain Validation de l’IBC (Inter-Blockchain Communication).
Cette sécurité inter-chaînes supprime la nécessité pour les nouvelles chaînes de créer leur propre ensemble de validateurs.
Dans un cadre traditionnel, l'utilisateur final se connecte à une interface représentant la chaîne A et transmet un actif à la chaîne B via une transaction IBC. L'utilisateur doit ensuite se connecter à une autre interface, représentant cette fois la chaîne B, et effectuer le reste du flux.
Interchain Account permet d'utiliser un compte virtuel pour utiliser le smart-contract sur une autre blockchain, ce qui permet à l'utilisateur de réaliser l'ensemble du flux tout en améliorant son expérience puisque les chaînes se passent l’ensemble des d'instructions et exécutent les transactions de manière invisible - le tout sans que l'utilisateur ait à quitter la première interface.
Cela signifie que toute action telle que les transferts, le jalonnement ou le vote sur des propositions de gouvernance qui peut être effectuée sur B (appelée la "chaîne hôte"), peut être effectuée à partir de A (appelée la "chaîne contrôleur").
En d’autre terme, les ICA permettent une composabilité native dans les transactions cross-chain, ce qui permettra aux chaînes non seulement d'échanger des données, mais aussi d'écrire des états, au lieu d'obliger l'utilisateur final à se déplacer entre différentes interfaces au fur et à mesure qu'un actif se déplace.
Pour rappel, un système composable est un système dont les différents composants peuvent être découplés, remaniés et réintégrés en tant que blocs de construction dans des systèmes plus vastes. La composabilité est ce qui permet à un ensemble d'être meilleur que la somme de ses parties. L'activation de la composabilité dans l'IBC permet de déployer l'innovation dans des applications distinctes sans avoir à mettre à niveau l'ensemble de l'Interchain, ce qui fournit un modèle d'innovation plus évolutif qui préserve la compatibilité.
En conclusion, le réseau de blockchain Cosmos s’articule autour d’une suite de logiciel Tendermint (Core + ABCI), d’un ensemble d'outils Cosmos SDK et d’un protocole de réseau IBC afin de construire des blockchains spécifiques à une application.
Tendermint (Core + ABCI) permet d’avoir un temps de blocs de quelque secondes, de gérer des centaines de transactions par seconde et d’avoir une finalité instantanée à la publication du bloc sans sacrifier la sécurité. Par contre, le nombre de validateur est beaucoup plus limité à cause de la communication qui doit avoir lieu entre eux pour faire tourner le réseau. Le max théorique est de 300 validateurs mais en pratique la plupart des blockchains basées sur Tendermint ont 100 validateurs ou moins. Même le Cosmos Hub ne supporterait que 175 validateurs, sûrement pour ne pas sacrifier le débit.
le protocole de réseau (IBC) basé sur des chaines dédiées: un réseau de réseaux. Plutôt que d’avoir une seule chaîne avec toutes les applications possibles, elle est constituée d’une multitude de consumer chain spécialisées et indépendante. La solution proposée par Cosmos est de mettre en place un protocole de communication à vocation universel et qui permet de communiquer avec d’autre chaines sans passer par un bridge: le protocole IBC. On peut donc envoyer tout un tas de chose (de simple messages, des actifs fongibles ou pas, une requête pour utiliser une fonction dans un smart-contract, des flux de donnés utilisés par des oracles…). Par exemple, Avalanche pourrait implémenter le protocole IBC, ce qui rendrait tout cet écosystème directement connecté à toutes les chaines Cosmos.
Finalement, il faut une couche d’application à rajouter par dessus. Le Cosmos SDK (software developement kit) est un kit de développement dans lequel on retrouve une liste de module qui couvre la preuve d’enjeu, la gouvernance, les situation de crises, la création de nouveau jeton… en d’autre termes une base de librairie qui permet de très rapidement lancer des solutions sans avoir à re-développer. Tout est pré-développé, il suffit juste de rajouter des paramètres et des bouts de codes.
collect://
Source:
https://blogchaincafe.com/cosmos-un-bref-apercu
https://research.thetie.io/a-journey-through-the-cosmos-atom/
https://medium.com/coinmonks/tendermint-cosmos-sdk-demystified-47385cf77cf6
https://web3pills.substack.com/p/a-deep-dive-on-cosmos?sd=pf
https://blog.cosmos.network/why-application-specific-blockchains-make-sense-32f2073bfb37
<100 subscribers
<100 subscribers
No activity yet