Je suis allé voir les barèmes de primes pour les vulnérabilités récemment mis à jour par Babylon le 27 juillet, et j’en suis ressorti encore moins rassuré.
La récompense maximale atteint 500 000 dollars, et 16 types d’actifs sont inclus. À première vue, cela montre que l’investissement en sécurité n’est pas faible. Mais en regardant plus loin, certains risques qui pourraient vraiment entraîner le système dans un gros incident ont au contraire été explicitement exclus : risques centralisés, relai temporairement à l’arrêt entre Bitcoin et Babylon, plus d’un tiers de Finality Provider malveillants, le Covenant atteignant une majorité malveillante ou l’impossibilité de réunir les signatures, ainsi que des paramètres de configuration de la profondeur de confirmation trop faibles.
Il faut aussi noter que les règles de la prime interdisent les tests d’oracles et de contrats intelligents tiers.
Cela entre en contradiction très nette avec l’orientation récemment poursuivie par @BabylonLabs_io . Babylon a déjà annoncé vouloir connecter les Trustless Bitcoin Vaults à Aave V4 et Aegis, avec le lancement au quatrième trimestre d’un prêt à taux fixe adossé au BTC natif.
La chaîne produit deviendra la suivante : Babylon gère l’infrastructure de dépôt BTC, Aave gère le marché des prêts, Aegis gère le produit à taux fixe, et à l’extérieur il faudra peut-être encore intégrer un wallet, un front-end, des oracles et des mécanismes de règlement.
Pour les utilisateurs, c’est « BTC natif, auto-hébergement, sans pont ». Pour les attaquants, ce sont en revanche les raccords de responsabilité entre plusieurs systèmes.
Les problèmes de sécurité de Babylon divulgués cette année par OpenZeppelin se concentrent précisément sur ce genre de jonctions : un dépôt de garantie expiré conserve encore le droit de vote, Finality Provider contourne la mise sous séquestre, des écritures anormales de Co-Staking entraînent un gel des fonds, voire le crash de validateurs. L’équipe a bien corrigé rapidement, mais cela ne fait que confirmer que les problèmes de frontière ne sont pas un risque purement théorique.
Je ne remets pas en cause le fait que Babylon ait audité : je m’interroge plutôt sur la question suivante — quand les activités s’empilent et s’appuient de plus en plus sur des composants tiers, qui est responsable des incidents « entre composants » ?
La sécurité ne peut pas se limiter à vérifier si un dépôt isolé contient ou non des vulnérabilités. Quand un incident survient réellement, souvent chaque partie peut prouver que son code ne pose pas problème, mais au final personne ne peut garantir que l’argent des utilisateurs est en sécurité.
#baby $BABY @BabylonLabs_io
La récompense maximale atteint 500 000 dollars, et 16 types d’actifs sont inclus. À première vue, cela montre que l’investissement en sécurité n’est pas faible. Mais en regardant plus loin, certains risques qui pourraient vraiment entraîner le système dans un gros incident ont au contraire été explicitement exclus : risques centralisés, relai temporairement à l’arrêt entre Bitcoin et Babylon, plus d’un tiers de Finality Provider malveillants, le Covenant atteignant une majorité malveillante ou l’impossibilité de réunir les signatures, ainsi que des paramètres de configuration de la profondeur de confirmation trop faibles.
Il faut aussi noter que les règles de la prime interdisent les tests d’oracles et de contrats intelligents tiers.
Cela entre en contradiction très nette avec l’orientation récemment poursuivie par @BabylonLabs_io . Babylon a déjà annoncé vouloir connecter les Trustless Bitcoin Vaults à Aave V4 et Aegis, avec le lancement au quatrième trimestre d’un prêt à taux fixe adossé au BTC natif.
La chaîne produit deviendra la suivante : Babylon gère l’infrastructure de dépôt BTC, Aave gère le marché des prêts, Aegis gère le produit à taux fixe, et à l’extérieur il faudra peut-être encore intégrer un wallet, un front-end, des oracles et des mécanismes de règlement.
Pour les utilisateurs, c’est « BTC natif, auto-hébergement, sans pont ». Pour les attaquants, ce sont en revanche les raccords de responsabilité entre plusieurs systèmes.
Les problèmes de sécurité de Babylon divulgués cette année par OpenZeppelin se concentrent précisément sur ce genre de jonctions : un dépôt de garantie expiré conserve encore le droit de vote, Finality Provider contourne la mise sous séquestre, des écritures anormales de Co-Staking entraînent un gel des fonds, voire le crash de validateurs. L’équipe a bien corrigé rapidement, mais cela ne fait que confirmer que les problèmes de frontière ne sont pas un risque purement théorique.
Je ne remets pas en cause le fait que Babylon ait audité : je m’interroge plutôt sur la question suivante — quand les activités s’empilent et s’appuient de plus en plus sur des composants tiers, qui est responsable des incidents « entre composants » ?
La sécurité ne peut pas se limiter à vérifier si un dépôt isolé contient ou non des vulnérabilités. Quand un incident survient réellement, souvent chaque partie peut prouver que son code ne pose pas problème, mais au final personne ne peut garantir que l’argent des utilisateurs est en sécurité.
#baby $BABY @BabylonLabs_io