- Un bug dans l’extension de vote de Babylon a permis aux validateurs d’omettre des données, provoquant des plantages chez leurs pairs aux frontières d’époque.
- La faille a mis à rude épreuve la logique de consensus hors chaîne, ralentissant les blocs sans compromettre la cryptographie.
- Babylon a corrigé le bug dans la version v4.2.0 alors que la croissance de BTCFi augmente les enjeux de fiabilité du réseau.
Une faille logicielle révélée dans le protocole de staking Bitcoin de Babylon a montré comment le comportement des validateurs pouvait perturber le consensus et ralentir la production des blocs. Le problème a été signalé via un post GitHub le 8 décembre 2025, par le contributeur GrumpyLaurie55348. Le bug affecte l’extension de vote BLS de Babylon et montre comment l’omission de données lors du vote peut faire planter les validateurs aux frontières d’époque.
Fonctionnement de la faille de l’extension de vote de Babylon
La vulnérabilité se trouve dans le système de signature de blocs de Babylon, connu sous le nom d’extension de vote BLS. Ce mécanisme prouve que les validateurs se sont mis d’accord sur un bloc proposé lors du consensus. Dans des conditions normales, les validateurs incluent un champ de hachage de bloc identifiant précisément le bloc qu’ils soutiennent.
Cependant, le bug permet aux validateurs d’omettre ce champ de hachage lors de la soumission des extensions de vote. Comme les champs protobuf restent optionnels, le réseau accepte ces messages incomplets. Lorsque Babylon traite ensuite le vote, il tente d’accéder à des données manquantes et rencontre un pointeur nul.
Cette déréférence déclenche une panique d’exécution lors des vérifications de consensus. Notamment, les chemins de code affectés incluent VerifyVoteExtension et la vérification des votes au moment de la proposition. En conséquence, les validateurs peuvent planter à des points de contrôle spécifiques au lieu de simplement rejeter le vote défectueux.
Le moment de ces plantages est important. Les frontières d’époque nécessitent un accord coordonné entre validateurs. Ainsi, des plantages lors de ces transitions retardent la création des blocs frontières d’époque et ralentissent la production des blocs.
Perturbation des validateurs et points de stress du consensus
La faille crée une voie pour que des validateurs malveillants perturbent leurs pairs sans compromettre la cryptographie. Au lieu de cela, ils exploitent la gestion des entrées. En soumettant des extensions de vote sans hachage de bloc, un seul acteur peut provoquer des échecs ailleurs.
Selon GrumpyLaurie55348, des plantages intermittents apparaissent aux frontières d’époque. Ces moments ancrent les transitions d’état des validateurs. Par conséquent, toute instabilité lors de ces vérifications affecte le flux global du consensus.
Les développeurs ont confirmé qu’aucune exploitation active n’a eu lieu. Cependant, ils ont averti qu’une mauvaise utilisation restait possible si les opérateurs retardaient les mises à jour. L’avis classe le problème comme très sévère en raison de son impact sur le consensus.
Babylon a corrigé la faille dans la version 4.2.0. Le correctif introduit une validation plus stricte des extensions de vote. Toutefois, à la date de publication, Babylon n’a pas publié de déclaration publique sur le calendrier de mise à niveau des validateurs.
Cet épisode montre comment la logique de consensus va au-delà de la couche de base de Bitcoin dans les cadres de staking. Babylon repose sur une coordination hors chaîne vérifiable pour prouver l’accord des validateurs. Ainsi, des failles dans cette couche peuvent influencer les résultats on-chain sans toucher directement à Bitcoin.
À lire aussi : Le Cambodge extrade Chen Zhi vers la Chine dans une affaire d’escroquerie en cryptomonnaies
Contexte dans l’expansion du rôle BTCFi de Babylon
La divulgation est intervenue alors que Babylon élargissait son rôle dans la finance décentralisée basée sur Bitcoin, connue sous le nom de BTCFi. Babylon a introduit le staking natif Bitcoin, permettant la génération de rendement sans déplacer les actifs hors de Bitcoin. Ce modèle repose sur des vérifications de consensus hors chaîne vérifiables.
Le 7 janvier, Babylon a annoncé un investissement de 15 millions de dollars de la part de a16z Crypto. Ce financement a suivi une vente de jetons BABY à la branche actifs numériques d’Andreessen Horowitz. A16z a déclaré que ce capital soutenait l’infrastructure DeFi native à Bitcoin.
Les tours de financement antérieurs ont porté le total déclaré de Babylon à 103 millions de dollars. Ces levées comprenaient une série A de 18 millions de dollars et un tour stratégique de 70 millions de dollars mené par Paradigm. Le protocole s’est également associé à Aave Labs en décembre 2025.
Ce partenariat vise à permettre le prêt adossé à Bitcoin sur Aave v4 sans wrappers ni dépositaires. Les tests sont prévus pour le premier trimestre 2026, avec un lancement ciblé en avril 2026. L’intégration repose sur la conception du Bitcoin Vault de Babylon.
Pendant ce temps, Babylon contrôle plus de 80 % de la valeur totale verrouillée dans BTCFi. La fiabilité du réseau a donc des conséquences à l’échelle de tout l’écosystème. En 2024, la TVL DeFi de Bitcoin est passée de 307 millions à plus de 6,5 milliards de dollars.
Le bug de Babylon illustre la façon dont les cadres de staking étendent la logique de consensus au-delà de la couche de base de Bitcoin. À mesure que l’adoption progresse, les développeurs sont de plus en plus confrontés à des conditions de test adverses. L’incident montre comment des champs optionnels et des cas limites peuvent influencer les chemins critiques du consensus.
La correction de Babylon comble la vulnérabilité immédiate. Toutefois, la divulgation attire l’attention sur la façon dont les extensions de consensus hors chaîne interagissent avec le modèle de sécurité de Bitcoin.
Par ailleurs, la vulnérabilité de Babylon a mis en évidence une faille dans la gestion des extensions de vote qui pouvait faire planter les validateurs lors des transitions d’époque. Le problème a affecté le calendrier de production des blocs mais n’a montré aucune exploitation active. Les développeurs ont corrigé le bug dans la version 4.2.0, tandis que le protocole continue de se développer dans la finance décentralisée basée sur Bitcoin.
