Qu’est-ce que CometBFT et comment fonctionne-t-il ?

Qu’est-ce que CometBFT ?

CometBFT est un logiciel open source qui permet à plusieurs ordinateurs de se mettre d’accord sur les mêmes données de blockchain. En termes simples, il aide les nodes à ordonner les transactions dans le même ordre et à conserver tous la même version mise à jour de la blockchain.

Ce processus s’appelle Byzantine Fault Tolerant, ou BFT. Le système part du principe que certains participants peuvent commettre des erreurs, se déconnecter ou même agir volontairement de manière incorrecte. Tant que moins d’un tiers du pouvoir de vote total se comporte ainsi, CometBFT empêche que deux blocks différents soient définitivement validés au même endroit de la blockchain.

CometBFT est le successeur de Tendermint Core et utilise l’algorithme de consensus Tendermint. Ce n’est ni une blockchain prête à l’emploi ni un projet crypto complet avec ses propres règles fixes. Le logiciel gère surtout le consensus, la communication entre nodes et la production des blocks. Les règles de la blockchain elle-même, comme les transactions valides, se trouvent dans une application distincte.

La connexion entre CometBFT et cette application s’appelle ABCI, abréviation de Application Blockchain Interface. On peut voir ABCI comme une couche de communication fixe : CometBFT demande par exemple si une transaction est valide, et l’application répond. Les développeurs peuvent ainsi construire leur propre logique blockchain sans devoir créer eux-mêmes un moteur de consensus complet.

À retenir

• CometBFT est un logiciel open source destiné au consensus et à la synchronisation des données de blockchain entre nodes.
• Il utilise un consensus BFT, ce qui permet de gérer les erreurs ou le comportement malveillant d’une partie des validateurs.
• CometBFT est un fork et le successeur de Tendermint Core.
• Le logiciel ne détermine pas lui-même quelles transactions sont valides sur le fond ; c’est l’application connectée qui le fait.
• ABCI constitue la connexion entre CometBFT et l’application blockchain.

Comment fonctionne le consensus de CometBFT ?

CometBFT permet aux validateurs de collaborer pour chaque block selon trois étapes fixes : propose, prevote et precommit. Dans ce contexte, un validateur est un participant autorisé à signer des blocks et des votes. Tous les nodes ne sont donc pas automatiquement des validateurs.

Chaque nouvelle position dans la blockchain s’appelle une block height. À chaque height, le réseau tente de décider d’un nouveau block. D’abord, le protocole désigne un proposer. Il s’agit du validateur qui, pour ce tour, peut diffuser une proposition de nouveau block.

Ensuite, les autres validateurs examinent la proposition. Le block est-il valide et reçu à temps ? Ils émettent alors un prevote : un premier vote en faveur de ce block. S’il y a suffisamment d’accord, un precommit suit : le deuxième vote, décisif.

Un block est committé dès que plus de deux tiers de tout le pouvoir de vote ont émis un precommit pour exactement le même block. Le pouvoir de vote ne dépend pas nécessairement du nombre de validateurs. Un validateur peut par exemple avoir plus de pouvoir de vote qu’un autre, selon les règles de l’application blockchain.

Exemple : supposons que le pouvoir de vote total soit de 100. Il faut alors plus de 66 votes pour committer un block. Peu importe que ce pouvoir de vote provienne d’un grand nombre de petits validateurs ou d’un nombre plus réduit de validateurs plus importants.

Aucune proposition valide n’arrive, le proposer est hors ligne ou les votes arrivent trop tard ? La même block height recommence alors dans un tour suivant. Les délais peuvent augmenter d’un tour à l’autre, afin que les nodes plus lents puissent encore rattraper leur retard. Cela n’empêche pas les ralentissements, mais donne au réseau un moyen de continuer lorsqu’un tour échoue.

Quel rôle jouent les validateurs dans CometBFT ?

Les validateurs prennent les décisions dans CometBFT. Ils signent les propositions de blocks et les votes, vérifient les propositions et contribuent ainsi à déterminer quel block sera ajouté. Un node ordinaire peut transmettre des informations à d’autres nodes, mais sans clé privée de validateur, il ne peut pas voter lui-même dans le consensus.

Le proposer est choisi automatiquement et de manière prévisible selon un schéma round-robin. Les validateurs disposant d’un pouvoir de vote plus élevé y reviennent proportionnellement plus souvent pour faire une proposition.

En pratique, un validateur fait ce qui suit :

• le validateur reçoit une proposition de block ;
• le validateur vérifie si la proposition est valide selon les règles de l’application ;
• si la proposition est valide et reçue à temps, il émet un prevote ;
• si suffisamment de prevotes sont réunis, un precommit peut suivre ;
• après assez de precommits, le block est committé.

Si aucune proposition valide n’a été reçue, un validateur peut voter nil. Cela signifie simplement : aucun vote pour un block précis durant ce tour. Le réseau peut ainsi passer au tour suivant sans accepter une proposition incorrecte.

L’ensemble des validateurs et la répartition du pouvoir de vote proviennent en entrée de l’application blockchain. Cette application peut donc aussi définir des règles pour ajuster l’ensemble des validateurs. Le staking, la délégation et le slashing ne sont pas des fonctions autonomes fixes de CometBFT lui-même. C’est l’application qui détermine si de telles règles existent et comment elles fonctionnent.

Autre point important : les clés de signature des validateurs doivent être correctement sécurisées. Si un même validateur signe des messages contradictoires, cela peut constituer une preuve de comportement byzantin. CometBFT peut traiter ce type de preuve, mais une éventuelle sanction financière est déterminée par l’application.

Comment se déroule la communication entre validateurs ?

Les validateurs communiquent via un réseau peer-to-peer, souvent abrégé en P2P. Les nodes transmettent des informations à d’autres nodes via le gossip. Cela peut sembler informel, mais cela signifie simplement que les messages se propagent de node en node à travers le réseau.

Grâce à ce gossip, on diffuse notamment les transactions, des parties de blocks, des propositions, des prevotes et des precommits. Les nodes partagent aussi leur état actuel : la block height à laquelle ils se trouvent, le tour dans lequel ils sont et l’étape du consensus qu’ils exécutent. Un node en retard peut ainsi voir ce qui se passe et se reconnecter au processus.

Les nodes qui ne valident pas peuvent aussi être utiles à ce niveau. Ils peuvent relayer des propositions, des blocks et des votes, même s’ils n’émettent pas eux-mêmes de vote de consensus. Cela aide à diffuser largement l’information dans le réseau.

Les transactions que l’application juge suffisamment valides via CheckTx peuvent entrer dans la mempool. La mempool est en réalité une zone d’attente pour les transactions susceptibles d’entrer dans un prochain block. Grâce au gossip, ces transactions peuvent continuer à se propager. Cela ne garantit toutefois pas qu’une transaction sera effectivement incluse : le proposer, les limites de block et les règles de l’application jouent tous un rôle.

Il ne faut pas confondre la communication entre nodes avec ABCI. Le P2P et le gossip concernent les messages échangés entre nodes dans le réseau. ABCI concerne au contraire la communication locale entre CometBFT et l’application blockchain, par exemple dans le même processus, via un socket ou via gRPC.

Comment CometBFT est-il structuré ?

CometBFT se compose globalement d’une partie consensus et d’une partie application, avec ABCI comme lien entre les deux. Cette séparation est utile : d’un côté, elle règle la manière dont les nodes se mettent d’accord ; de l’autre, elle détermine ce que la blockchain fait réellement.

Le moteur CometBFT comprend notamment des composants pour le consensus, la communication P2P, la mempool, la diffusion des blocks, le stockage de l’état et un serveur RPC. Grâce à ce serveur RPC, les applications clientes peuvent demander des données sur le consensus et la blockchain.

L’application, elle, gère ses propres règles et données. Il s’agit par exemple de savoir si une transaction est valide, comment les soldes évoluent ou quelles autres opérations la blockchain prend en charge. Dans de nombreux nodes de la Cosmos SDK, CometBFT et l’application fonctionnent ensemble dans un même daemon, mais ils peuvent aussi coopérer comme processus distincts via ABCI.

Point important à retenir : CometBFT appelle l’application via ABCI. L’application ne pilote donc pas CometBFT ; elle fournit des réponses lorsque CometBFT les demande au cours du cycle de vie d’une transaction ou d’un block.

Que fait la couche de consensus ?

La couche de consensus de CometBFT détermine quand et comment de nouveaux blocks sont décidés. Cette couche assure le consensus BFT, le réseau P2P, la production des blocks et leur diffusion vers les nodes.

À chaque nouveau block, le protocole choisit un proposer et orchestre les tours de propose, prevote et precommit. Dès que plus de deux tiers du pouvoir de vote ont précommitté pour le même block, ce block est committé.

La couche de consensus gère aussi la mempool. Lorsqu’un node reçoit une transaction, CometBFT demande via ABCI à l’application si cette transaction peut être placée dans la mempool. Cette vérification s’appelle CheckTx. Un CheckTx réussi ne signifie pas encore que la transaction a été exécutée définitivement. Cela signifie seulement que la transaction peut entrer en ligne de compte pour une proposition de block ultérieure.

Après le consensus sur un block, CometBFT veille à ce que l’application exécute le block et enregistre le nouvel état. La couche de consensus ne décide donc pas elle-même si une transaction est correcte sur le fond. Cela reste le rôle de l’application.

Que fait la couche applicative ?

La couche applicative définit les règles de la blockchain. Elle précise par exemple quelles données sont conservées, quelles transactions sont valides et comment une transaction valide modifie l’état.

Cette couche est la machine d’état déterministe de la blockchain. C’est un terme technique pour quelque chose de simple : si deux nodes reçoivent la même entrée, ils doivent calculer exactement le même résultat. Sinon, les nodes peuvent obtenir différentes versions de la blockchain, ce qui ne fonctionne évidemment pas.

Dans une application Cosmos SDK, cette couche comprend notamment des modules, le traitement des transactions et des state stores. L’état actuel reçoit aussi un résumé cryptographique, l’AppHash. Si des nodes calculent des valeurs AppHash différentes après le même block, cela indique un problème d’exécution.

Via ABCI, l’application traite différents moments du processus :

• CheckTx : vérifie si une transaction reçue peut entrer dans la mempool.
• PrepareProposal : permet à l’application du proposer de choisir, trier, retirer ou ajouter des transactions pour une proposition de block, dans les limites applicables.
• ProcessProposal : permet aux autres validateurs d’évaluer s’ils acceptent la proposition.
• FinalizeBlock : exécute un block après l’obtention du consensus.
• Commit : enregistre durablement le nouvel état.

Tous les appels ABCI n’ont pas exactement les mêmes exigences. PrepareProposal peut par exemple varier, car seul le proposer l’exécute. ProcessProposal et l’exécution des blocks doivent en revanche être déterministes, afin que tous les validateurs aboutissent au même résultat.

À quoi sert CometBFT ?

CometBFT sert de moteur général de consensus et de réplication pour des blockchains dotées de leurs propres règles. Les développeurs peuvent donc placer derrière lui une application déterministe, au lieu de construire de zéro un système dans lequel les nodes doivent se mettre d’accord sur les blocks.

Les usages possibles sont variés. Une application blockchain peut par exemple porter sur des currencies, le vote électronique ou l’orchestration d’infrastructure. CometBFT ne fixe pas la nature de l’application. Il fournit la base technique pour répliquer de manière fiable les mêmes transactions et le même état sur plusieurs nodes.

Dans la Cosmos Stack, CometBFT a un rôle clair : il gère le consensus, la communication réseau et la production des blocks. La Cosmos SDK fournit ensuite les briques nécessaires à la logique applicative. Les développeurs n’ont donc pas à créer eux-mêmes ces deux éléments de A à Z.

CometBFT dispose également de son propre serveur RPC. Un wallet, une dApp ou un autre client peut l’utiliser pour demander des données sur les blocks et le consensus, en plus des API d’une application Cosmos SDK.

Comment CometBFT fonctionne-t-il avec la Cosmos SDK ?

CometBFT et la Cosmos SDK se complètent : CometBFT gère le consensus et la Cosmos SDK gère l’application blockchain. Il s’agit donc de deux composants différents qui peuvent ensemble former un nœud blockchain fonctionnel.

La Cosmos SDK fournit des modules, le traitement des transactions, la gestion de l’état et d’autres règles applicatives. CometBFT gère pendant ce temps la communication P2P, la mempool, le choix d’un proposer et l’obtention du consensus sur de nouveaux blocks.

Le lien entre les deux est ABCI. Dans une application Cosmos SDK, BaseApp implémente cette interface. CometBFT envoie ensuite des requêtes telles que CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock et Commit. BaseApp traite ces requêtes et renvoie une réponse.

Lors d’une nouvelle proposition, CometBFT choisit d’abord un proposer en fonction du pouvoir de vote des validateurs. Ensuite, l’application de ce proposer peut, via PrepareProposal, déterminer quelles transactions entrent dans la proposition et dans quel ordre, dans les limites du block. Les autres validateurs évaluent la proposition via ProcessProposal avant de voter.

Cette répartition est pratique. Les développeurs peuvent travailler sur leur propre application blockchain, tandis que le moteur de consensus éprouvé reste séparé. Ainsi, le même moteur CometBFT peut aussi être utilisé avec différentes applications SDK.

Quels sont les avantages de CometBFT ?

Un avantage important de CometBFT est sa sécurité BFT claire. Tant que moins d’un tiers du pouvoir de vote des validateurs concernés adopte un comportement byzantin, aucun block conflictuel ne sera committé au même block height.

En outre, la séparation entre consensus et logique applicative est très utile. Grâce à ABCI, un développeur peut créer ses propres règles blockchain sans devoir construire lui-même un moteur complet de consensus BFT. Les tâches techniques deviennent ainsi plus lisibles : CometBFT gère l’accord, l’application gère le contenu.

Parmi les autres avantages :

• Processus de vote clair : un block n’est décidé qu’après plus de deux tiers de precommits pour ce même block.
• Technologie réutilisable : le même moteur peut prendre en charge différentes applications blockchain.
• Connexion flexible : ABCI peut fonctionner dans le processus en Go, mais aussi via socket ou gRPC.
• Séparation des responsabilités : le code de consensus et le code applicatif peuvent être développés indépendamment.

Attention toutefois : ces avantages ne signifient pas automatiquement que toute blockchain utilisant CometBFT est rapide, sûre ou fortement décentralisée. Cela dépend aussi de l’ensemble des validateurs, des connexions réseau, du matériel, de la configuration et du code de l’application.

Quelles sont les limites et les risques de CometBFT ?

CometBFT présente des conditions de sécurité et des risques opérationnels bien définis. La condition principale est que moins d’un tiers du pouvoir de vote des validateurs puisse adopter un comportement byzantin. Ici, byzantin signifie que les validateurs se comportent de manière erronée ou malveillante, par exemple en envoyant des informations contradictoires, en ne respectant pas les règles ou en coopérant pour manipuler le réseau. Si ce seuil est dépassé, la garantie de sécurité contre les commits conflictuels ne s’applique plus.

Pour assurer la progression, il faut aussi suffisamment de pouvoir de vote actif. Si des validateurs disposant d’un pouvoir de vote suffisant sont hors ligne, ou s’ils ne peuvent pas communiquer à cause d’une partition du réseau, le réseau ne peut pas atteindre le quorum. De nouveaux tours s’ensuivent et la production des blocks peut ralentir ou s’arrêter temporairement.

La latence réseau joue ici un rôle majeur. Si les propositions, les parties de blocks ou les votes n’arrivent pas à temps, le tour expire et le protocole recommence. Les délais peuvent ensuite augmenter. Cela aide les participants lents, mais signifie aussi que les confirmations peuvent prendre plus de temps.

L’application derrière ABCI constitue un autre point d’attention important. Là où le déterminisme est requis, chaque node doit produire le même résultat à partir de la même entrée. Une erreur qui conduit les nodes à calculer des résultats différents peut provoquer des divergences d’AppHash et des problèmes de consensus. La séparation entre CometBFT et l’application n’empêche donc pas tous les effets d’un mauvais code applicatif.

Les clés des validateurs et l’infrastructure des nodes sont également sensibles. Des clés de signature mal protégées peuvent être exploitées, et les validateurs peuvent être la cible d’attaques par déni de service. Une architecture de sentry nodes peut aider à exposer moins directement les nodes validateurs à ce type d’attaques.

Par ailleurs, une transaction présente dans la mempool n’est pas encore intégrée de manière sûre dans un block. Les nodes peuvent tomber en panne avant qu’une transaction n’entre dans une proposition, ce qui peut faire disparaître la transaction de la mempool. Quiconque envoie une transaction doit donc attendre qu’elle figure réellement dans un block committé.

Enfin, les mises à jour de version peuvent entraîner des problèmes de compatibilité. Des breaking changes dans une version mineure peuvent nécessiter une nouvelle chaîne ou une migration de données spécifique. La mise à niveau demande donc une bonne préparation, tant pour l’application que pour les nodes qui font fonctionner la blockchain.

En résumé

CometBFT est le moteur technique qui aide les nodes blockchain à se mettre d’accord sur de nouveaux blocks et à conserver le même état. Il fonctionne avec un processus de consensus BFT dans lequel les validateurs font des propositions, votent et ne committent un block que lorsque plus de deux tiers du pouvoir de vote approuvent le même block.

Sa force réside surtout dans la répartition des tâches. CometBFT gère le consensus, la communication P2P et la production des blocks, tandis que l’application derrière ABCI définit les règles de la blockchain. En combinaison avec la Cosmos SDK, les développeurs peuvent ainsi construire leur propre application blockchain sans devoir créer eux-mêmes toute la couche de consensus.

En même temps, la pratique reste essentielle. La sécurité dépend du pouvoir de vote des validateurs, de réseaux fiables, de clés bien protégées et d’une application qui calcule toujours le même résultat. CometBFT offre donc une base technique solide, mais le fonctionnement final d’une chaîne dépend toujours aussi de la manière dont cette base est utilisée.