Qu’est-ce que le Cosmos SDK et comment fonctionne-t-il pour construire des blockchains ?

Qu’est-ce que le Cosmos SDK ?

Le SDK Cosmos est un logiciel de développement open source qui permet aux développeurs de construire une blockchain propre à une application, ou un registre numérique. Il ne s’agit donc ni d’une blockchain, ni d’un réseau, ni d’un token en soi.

Une blockchain construite avec le Cosmos SDK peut fonctionner comme une blockchain Layer 1 autonome. Cela signifie que la chaîne ne s’exécute pas comme une application au-dessus d’une autre blockchain, mais qu’elle définit elle-même les règles des transactions, de l’état et des autres éléments du protocole. Associée à un logiciel comme CometBFT, une telle blockchain peut aussi disposer de son propre réseau de validateurs et de son propre processus de consensus.

Avec le Cosmos SDK, un projet définit lui-même les règles de sa chaîne. Il peut s’agir de savoir qui peut effectuer certaines actions, comment les transactions fonctionnent, quelles données sont stockées, comment la gouvernance est organisée et quelle logique applicative s’applique.

On peut le voir comme une boîte à outils pour blockchain. Au lieu de programmer tous les éléments à partir de zéro, un développeur choisit des composants existants et les assemble avec son propre code. Une chaîne peut ainsi intégrer des règles pour les tokens, la gestion des validateurs, la gouvernance on-chain ou des permissions spécifiques.

Une application Cosmos SDK est, d’un point de vue technique, une machine d’état déterministe. Cela peut sembler complexe, mais l’idée est simple : la même entrée valide doit toujours conduire exactement au même nouvel état sur chaque node. Si un utilisateur envoie par exemple des tokens, tous les nodes doivent au final voir le même solde.

Dans la configuration habituelle, cette application s’exécute sous forme de binaire Go. Go est le langage de programmation utilisé pour construire la logique de la chaîne. L’application fonctionne en parallèle avec le logiciel qui permet aux nodes de communiquer entre eux et de produire des blocs.

Le Cosmos SDK gère surtout la couche applicative : quelles transactions sont valides et ce qu’elles modifient. CometBFT gère généralement le consensus, la mise en réseau peer-to-peer et la production des blocs. ABCI assure le lien entre ces deux couches. Grâce à cette interface, le logiciel de consensus peut demander à l’application de vérifier et d’exécuter les transactions et les blocs.

À retenir

• Le Cosmos SDK est un logiciel de développement qui permet notamment de construire des blockchains Layer 1 autonomes et propres à une application.
• Une chaîne peut définir elle-même les règles des transactions, de la gouvernance, des permissions et des données stockées.
• Le SDK est modulaire : les développeurs combinent des modules existants avec leur propre logique.
• CometBFT assure généralement le consensus, la communication réseau et la production des blocs.
• Le Cosmos SDK n’est pas une blockchain distincte et ne possède pas de token propre.

Comment fonctionne le Cosmos SDK ?

Le Cosmos SDK fonctionne parce que CometBFT fait traiter les blocs et appelle l’application de la chaîne via ABCI. Le SDK détermine ce qu’une transaction peut faire, tandis que CometBFT veille à ce que les nodes se mettent d’accord sur les blocs.

La couche centrale d’une application SDK s’appelle BaseApp. BaseApp traduit les appels d’ABCI en tâches concrètes : exécuter les transactions, envoyer les messages vers le bon module et mettre à jour l’état.

Un utilisateur envoie d’abord une transaction signée. Une telle transaction contient un ou plusieurs messages. Un message est l’instruction concrète, comme l’envoi de tokens ou la délégation de tokens à un validateur.

La transaction contient aussi notamment une signature numérique, des frais et une limite de gas. La signature montre quel compte a approuvé l’instruction. Les frais correspondent au coût du traitement. La limite de gas indique la quantité maximale de calcul que l’utilisateur accepte de payer.

Avant l’exécution de la transaction, l’AnteHandler vérifie un certain nombre de règles de base. Il contrôle par exemple si la signature est correcte, si la séquence du compte est juste, s’il y a suffisamment de frais et si la limite de gas n’est pas dépassée. La séquence du compte est un numéro croissant qui aide à empêcher la réutilisation d’une même transaction.

Ensuite, BaseApp envoie chaque message au module approprié. Un transfert de tokens est par exemple envoyé au module qui gère les soldes. Ce module vérifie ses propres règles et, si tout est correct, modifie l’état.

L’état correspond à toutes les données actuelles de la chaîne, comme les comptes, les soldes et les paramètres. Ces données sont stockées sous forme de données clé-valeur dans un multistore. Il s’agit d’un ensemble d’espaces de stockage distincts, généralement un par module.

Une transaction est exécutée avec un stockage d’état temporaire. Les modifications effectuées pendant l’exécution d’un message ne sont conservées que si cette exécution réussit. Si un message échoue, ces modifications sont annulées. Certaines modifications issues de la phase précédente de l’AnteHandler, comme la perception des frais de transaction et l’incrémentation de la séquence du compte, peuvent toutefois être conservées.

Dans le flux habituel de CometBFT, BaseApp traite un bloc déterminé via FinalizeBlock. À cette étape, une logique éventuelle avant le bloc est d’abord exécutée, puis les transactions sont traitées, et enfin la logique de fin de bloc est appliquée. Ensuite, le nouvel état est enregistré avec Commit et un nouvel AppHash est créé : une empreinte cryptographique de l’état de l’application.

Exemple : Supposons que vous envoyiez 10 tokens à quelqu’un. La chaîne vérifie d’abord votre signature, la séquence, les frais et la limite de gas. Ensuite, le module des tokens vérifie que vous disposez d’au moins 10 tokens. Ce n’est que si tous les contrôles réussissent que 10 sont débités de votre solde et 10 sont ajoutés au solde du destinataire.

De quels éléments se compose le Cosmos SDK ?

Une application Cosmos SDK typique se compose de BaseApp, de modules et d’une couche dans laquelle tout est assemblé et configuré. Ensemble, ces éléments forment une seule machine d’état que les opérateurs de nodes exécutent.

BaseApp est le lien entre CometBFT et l’application. Il assure la connexion ABCI, route les messages et les requêtes, exécute les transactions et gère le multistore.

Les modules contiennent la véritable logique métier. Chaque module peut avoir son propre état, ses messages, ses fonctions de requête et ses règles. Une chaîne choisit elle-même les modules qu’elle intègre. Ceux-ci sont ensuite combinés avec d’éventuels modules personnalisés.

Cette intégration se fait normalement dans app.go. C’est là que le développeur crée BaseApp, configure les espaces de stockage, initialise les composants et détermine comment les modules interagissent entre eux. Le binaire du node démarre ensuite à la fois le node de consensus et l’application SDK.

Les modules utilisent généralement un keeper pour accéder à leur état. On peut voir un keeper comme une porte d’accès contrôlée aux données stockées. Tous les modules ne peuvent pas modifier n’importe quoi. Un module ne reçoit que les droits et les interfaces que l’application lui transmet volontairement.

Le ModuleManager suit les modules actifs et gère notamment le démarrage au genesis, les mises à niveau et l’ordre des hooks aux frontières des blocs. Le genesis est le point de départ d’une blockchain : le premier état avec lequel le réseau démarre.

Les Protocol Buffers jouent aussi un rôle important. Il s’agit d’une manière de décrire clairement les données et les services. Les messages, les services de requête, les types d’état et les types de genesis sont définis avec cet outil, puis du code Go et des stubs gRPC sont générés pour l’application.

Quels modules le Cosmos SDK propose-t-il ?

Le Cosmos SDK propose de nombreux modules qu’une chaîne peut choisir et combiner. Aucune chaîne n’est obligée d’utiliser tous les modules. C’est précisément ce choix qui détermine ce que la blockchain spécifique peut ou ne peut pas faire.

Voici quelques modules couramment utilisés :

• x/auth : gère les types de base des comptes et des transactions. Ce module aide notamment aux contrôles des signatures et des nonces de compte.
• x/bank : gère les soldes de plusieurs tokens, les transferts de tokens et l’offre totale de tokens.
• x/staking : gère les validateurs et les délégations dans une configuration proof-of-stake.
• x/gov : permet les propositions et les votes on-chain.
• x/distribution : répartit les récompenses de staking.
• x/slashing : peut appliquer des sanctions lorsque les validateurs ne respectent pas les règles.
• x/mint : prend en charge l’émission de tokens selon les règles de la chaîne.
• x/evidence : traite les preuves de mauvaise conduite des validateurs.
• x/upgrade : aide une chaîne à exécuter des mises à niveau logicielles de manière coordonnée.

Il existe aussi des modules pour des tâches spécifiques. Ainsi, x/authz peut gérer des autorisations déléguées pour les messages et x/feegrant peut permettre à un autre compte de payer les frais d’un utilisateur. x/consensus permet de gérer certains paramètres de consensus CometBFT sur la chaîne. x/circuit peut servir de disjoncteur pour suspendre temporairement certains messages.

La fonctionnalité IBC est généralement ajoutée via ibc-go. Il s’agit de l’implémentation IBC habituelle pour les chaînes Cosmos SDK, mais elle est maintenue comme projet distinct.

Un développeur peut adapter les modules standards, remplacer des composants ou créer ses propres modules. Une chaîne qui ne propose que des fonctions de base peut ainsi être très différente d’une chaîne avec gestion des validateurs, gouvernance et règles de permissions avancées.

Comment fonctionnent les applications Cosmos SDK ?

Une application Cosmos SDK fonctionne parce qu’un développeur assemble, enregistre et dote volontairement les modules des droits appropriés. Il ne suffit donc pas d’importer un package Go pour faire fonctionner un module sur une chaîne.

Dans app.go, l’application est construite. C’est là que les store keys sont enregistrées, que les keepers sont créés, que les modules sont ajoutés au ModuleManager et que les services sont reliés. Le développeur détermine aussi l’ordre dans lequel les hooks sont exécutés aux frontières des blocs. Cet ordre peut être important, car un module peut dépendre des actions d’un autre module.

Un module comprend généralement quatre éléments pratiques :

• Un keeper : pour un accès contrôlé à son propre état.
• Un service Msg : pour les actions qui modifient l’état, comme un transfert ou une délégation.
• Un service de requête : pour les questions en lecture seule, comme la consultation d’un solde.
• Une implémentation AppModule : afin que le module coopère correctement avec le ModuleManager.

Lorsqu’une transaction arrive, BaseApp route chaque message vers le MsgServer du module approprié en fonction du type. Le module vérifie ensuite si l’émetteur est autorisé et si l’action respecte les règles métier. Il utilise ensuite le keeper pour modifier l’état.

Les requêtes suivent un autre chemin. Via le gRPCQueryRouter, elles arrivent au service de requête du module approprié. Une requête lit l’état stocké et confirmé, sans rien modifier. Pensez à la différence entre consulter le solde de votre compte bancaire et effectuer un paiement.

Les modules peuvent aussi contenir une logique pour le genesis, les mises à niveau et les frontières de blocs. Lors d’une mise à niveau, des migrations d’état peuvent être nécessaires afin que les anciennes données s’adaptent correctement au nouveau code. Cela exige une planification et des tests rigoureux de la part du développeur de la chaîne.

Qu’est-ce que Cosmos EVM ?

Une blockchain Cosmos SDK peut aussi être rendue compatible avec la Ethereum Virtual Machine (EVM). Pour cela, il existe Cosmos EVM, qui permet d’intégrer la fonctionnalité EVM comme partie d’une application Cosmos SDK. Un projet peut ainsi construire une blockchain Layer 1 propre tout en pouvant exécuter des smart contracts Ethereum.

Le cœur de ce système est le module x/vm. Il ajoute un environnement d’exécution EVM à la blockchain, ce qui permet aux développeurs d’utiliser des smart contracts Solidity et de travailler avec des outils Ethereum connus comme MetaMask, Hardhat et Foundry. La blockchain reste toutefois une chaîne Cosmos SDK autonome, avec ses propres règles et sa propre configuration.

Cosmos EVM peut en outre donner accès à d’autres éléments du Cosmos SDK via des precompiles. Un smart contract peut ainsi, par exemple, communiquer avec des fonctionnalités de staking, de gouvernance ou d’IBC. Les precompiles disponibles sont configurées par les développeurs de la blockchain.

Cosmos EVM n’est pas un composant obligatoire du Cosmos SDK. Un développeur peut construire une chaîne Cosmos SDK sans EVM ou ajouter volontairement la fonctionnalité EVM lorsqu’une compatibilité avec les applications et les outils Ethereum est souhaitée.

À quoi sert le Cosmos SDK ?

Le Cosmos SDK est utilisé pour construire des blockchains propres à une application et des registres numériques lorsqu’un projet souhaite définir lui-même les règles de la chaîne. Un projet peut ainsi concevoir une blockchain Layer 1 autonome au lieu de construire seulement une application ou des smart contracts sur une blockchain existante. C’est particulièrement utile lorsque les règles standard d’une blockchain générale existante ne laissent pas suffisamment de marge.

Un projet peut par exemple définir au niveau du protocole des règles pour la tokenisation, les transferts de tokens, la gestion des validateurs en proof-of-stake, la gouvernance, les autorisations et les allowances de frais. Une logique de conformité ou de permissioning peut aussi faire partie des règles de la chaîne.

Le SDK peut être utilisé pour des réseaux publics, des réseaux privés permissionnés et des réseaux de consortium. Dans un réseau public, tout le monde peut en principe participer selon des règles ouvertes. Dans un réseau permissionné, au contraire, des participants ou des validateurs définis à l’avance peuvent recevoir des droits.

Cela rend le SDK utile dans les situations où une organisation ou un groupe ne veut pas seulement construire une dApp ou des smart contracts sur une blockchain existante, mais a besoin d’un environnement Layer 1 propre, avec ses propres transitions d’état et ses propres règles de chaîne.

Parmi les usages possibles, on peut citer les réseaux interbancaires, la tokenisation d’actifs et l’automatisation d’entreprise. Le choix d’une chaîne propre dépend toutefois des exigences concrètes. Une chaîne autonome demande, en plus du code, de la gestion, de la surveillance, des mises à niveau, de la gouvernance et un modèle de sécurité adapté.

Quel est le lien entre le Cosmos SDK, Cosmos Hub et IBC ?

Le Cosmos SDK est le framework de construction, IBC est le protocole de communication entre blockchains et Cosmos Hub est une blockchain publique proof-of-stake spécifique. Ces trois éléments sont donc liés, mais ils ne sont pas identiques.

Cosmos Hub exécute l’application Gaia. Gaia est construite comme une application Cosmos SDK et utilise ibc-go pour IBC. ATOM est le token natif de staking de Cosmos Hub.

IBC signifie Inter-Blockchain Communication. Il s’agit d’un protocole ouvert qui permet aux blockchains de s’envoyer des données vérifiées. Ces données peuvent être des tokens, des messages ou de la logique applicative.

Comment une chaîne sait-elle alors que les informations provenant d’une autre chaîne sont correctes ? IBC utilise notamment des clients, souvent appelés light clients, pour vérifier l’état de la contrepartie. Ensuite, IBC peut envoyer, confirmer ou laisser expirer des packets de manière vérifiable. Ici, un packet est un paquet de données qui passe d’une chaîne à une autre.

Le Cosmos SDK est étroitement lié à IBC via ibc-go, mais IBC doit réellement être intégré dans la chaîne. Un développeur doit notamment ajouter des keepers et du stockage IBC, configurer un routeur IBC avec des routes et enregistrer les modules pertinents.

Ensuite, pour qu’une véritable communication soit possible, il faut aussi une contrepartie compatible, ainsi qu’un canal IBC et du relaying. Les relayers sont des processus qui transmettent les messages IBC entre les chaînes. Ils ne déterminent pas eux-mêmes quelles données sont valides, car les chaînes vérifient ces données selon les règles IBC.

Cosmos Hub peut communiquer via IBC avec d’autres chaînes compatibles, mais il ne s’agit pas d’une couche intermédiaire centrale obligatoire. Deux chaînes IBC correctement configurées peuvent communiquer directement entre elles via leurs propres clients, connexions et channels.

IBC n’est pas non plus réservé aux chaînes Cosmos SDK. Le SDK rend surtout l’intégration pratique pour les chaînes construites avec lui.

Quels sont les avantages et les limites du Cosmos SDK ?

La plus grande force du Cosmos SDK est la personnalisation. Les développeurs peuvent n’utiliser que les modules nécessaires, adapter le comportement standard et ajouter leur propre logique. Les règles d’une chaîne peuvent ainsi être conçues directement au niveau du protocole.

La séparation entre logique applicative, ABCI et consensus est également utile. Qui utilise CometBFT n’a pas besoin de construire entièrement lui-même la couche habituelle de consensus et de peer-to-peer. Le développeur peut ainsi se concentrer davantage sur ce que la chaîne doit faire.

Parmi les autres avantages, on peut citer :

• Des blocs de construction réutilisables : les modules offrent des fonctions pour les comptes, les tokens, le staking, la gouvernance, les mises à niveau et l’autorisation.
• Un accès contrôlé : les keepers limitent l’état qu’un module peut lire ou modifier dans les autres modules.
• L’interopérabilité via IBC : des chaînes IBC correctement intégrées peuvent échanger des données vérifiées sans passer par un intermédiaire central.
• Des modèles de réseau flexibles : le SDK peut être utilisé pour des réseaux publics, privés et de consortium.

Cette liberté s’accompagne aussi de responsabilités. Un développeur doit concevoir correctement les modules, les keepers, les permissions, les paramètres et l’ordre des hooks. Les migrations d’état lors des mises à niveau et la gestion des dépendances demandent également de l’attention. Le SDK est largement stabilisé, mais peut encore contenir des breaking changes. Une mise à niveau doit donc être soigneusement planifiée et testée.

La connaissance de Go est importante en pratique, car les applications SDK sont des binaires Go et Go est nécessaire pour construire et faire fonctionner un node. Cela peut constituer un obstacle pour les équipes qui travaillent surtout avec d’autres langages de programmation.

IBC rend l’interopérabilité possible, mais pas automatiquement. Une chaîne doit intégrer et configurer IBC correctement. En outre, une contrepartie compatible, un canal fonctionnel et des relayers opérationnels sont nécessaires.

Enfin, le SDK ne supprime pas toute la responsabilité opérationnelle et de sécurité. Une chaîne autonome doit elle-même faire fonctionner un modèle adapté pour les validateurs et le stake, ou pour des règles de validateurs permissionnés. La sécurité dépend aussi du code des modules, de la configuration, de la gestion des clés, des mises à niveau, de l’infrastructure et de la manière dont le réseau est administré.

En résumé

Le Cosmos SDK est un framework flexible pour les équipes qui veulent construire leur propre blockchain avec leurs propres règles. Au lieu de placer seulement de la logique dans une chaîne existante, un projet peut définir lui-même comment fonctionnent les transactions, l’état, la gouvernance, les permissions et les autres processus.

Son architecture modulaire permet de combiner des composants existants pour, par exemple, les tokens, le staking et la gouvernance avec du code personnalisé. Un projet peut aussi intégrer Cosmos EVM lorsqu’il souhaite associer sa propre blockchain à la prise en charge des smart contracts et des outils Ethereum. CometBFT assure généralement le consensus et la couche réseau, tandis que BaseApp et les modules exécutent la logique applicative.

IBC peut relier une chaîne Cosmos SDK à d’autres chaînes correctement intégrées, mais cette connexion exige une configuration technique volontaire. Il en va de même pour la chaîne elle-même : la flexibilité signifie aussi que les développeurs restent responsables de la conception, des mises à niveau, de l’exploitation et de la sécurité.

En bref, le Cosmos SDK est surtout intéressant lorsqu’un projet ne veut pas seulement construire une application, mais aussi façonner les règles de la blockchain sous-jacente elle-même.