Réponses>Découvrez les principes fondamentaux de la sécurité de la blockchain>Causes courantes de défaillance de la blockchain
Modes de défaillance courants des chaînes de blocs
// Tags
défaillance de la blockchainattaques de la blockchain
En bref : les modes de défaillance de la blockchain couvrent trois couches distinctes : les défaillances de la couche de consensus (bogues des validateurs, partitions du réseau, attaques à 51 %), les défaillances de la couche applicative (vulnérabilités des contrats intelligents, manipulation des oracles, exploits de gouvernance) et les défaillances de la couche d’infrastructure (pannes de nœuds, interruptions de service des fournisseurs, incidents liés au cloud). Chaque couche possède ses propres vecteurs d’attaque, profils de risque et stratégies d’atténuation. Il est essentiel de comprendre ces modes de défaillance pour développer des applications blockchain résilientes, car les conséquences d’une défaillance dans un système gérant de véritables valeurs financières sont bien plus graves que dans le cas des logiciels traditionnels.
L'explication simple
Les blockchains sont souvent décrites comme « sans tiers de confiance » et immutable, mais cela ne signifie pas pour autant qu’elles soient infaillibles. À l’instar de tout système distribué complexe, les blockchains peuvent présenter des défaillances de multiples façons et à différents niveaux. Ce qu’il est essentiel de comprendre pour les développeurs, c’est que les défaillances des blockchains se produisent à plusieurs niveaux : un contrat intelligent parfaitement sécurisé peut tout de même entraîner la perte des fonds d’un utilisateur si l’oracle qui lui fournit des données est manipulé, et une application parfaitement écrite peut tout de même cesser de fonctionner si l’infrastructure des nœuds sous-jacente tombe en panne.
Imaginez cela comme un immeuble. Les fondations (couche de consensus) pourraient se fissurer. La plomberie et l'électricité (couche applicative) pourraient présenter des fuites ou des courts-circuits. La société de gestion immobilière (couche d'infrastructure) pourrait faire faillite. Chaque mode de défaillance mode un type de protection différent, et une résilience concrète implique de se prémunir simultanément contre ces trois risques.
Défaillances de la couche de consensus
La couche de consensus constitue le fondement de toute blockchain. Il s'agit du mécanisme par lequel les validateurs s'accordent sur les transactions valides et sur les blocs à ajouter à la chaîne. En cas d'échec du consensus, les conséquences sont très graves : la chaîne peut s'arrêter, se réorganiser ou produire des blocs contradictoires.
Les bogues des validateurs comptent parmi les modes de défaillance les plus courants au niveau de la couche de consensus. Les logiciels clients de blockchain sont complexes, et des bogues dans la production de blocs, la logique d’attestation ou le calcul des transitions d’état peuvent amener les validateurs à produire des blocs invalides, à planter pendant les cycles de consensus ou à être en désaccord avec d’autres validateurs quant à l’état correct. Ce risque est amplifié lorsqu’une seule implémentation de client domine le réseau. Si 70 % des validateurs utilisent le même client et que celui-ci comporte un bogue, 70 % du réseau est affecté simultanément. C’est pourquoi la diversité des clients, c’est-à-dire l’utilisation de plusieurs implémentations d’un même protocole, est un thème récurrent en matière de sécurité des blockchains.
Des partitions de réseau se produisent lorsque des groupes de validateurs perdent la capacité de communiquer entre eux, généralement en raison de problèmes d’infrastructure Internet, d’attaques DDoS ciblées ou de défaillances de routage géographiques. Si une partition sépare suffisamment de validateurs pour empêcher l’un ou l’autre camp d’atteindre le seuil de consensus (généralement les deux tiers du poids mis en jeu), la production de blocs s’arrête. Si la partition est partielle (les deux camps pouvant encore atteindre le seuil indépendamment l’un de l’autre), la chaîne peut temporairement se diviser en deux branches, chaque partition produisant ses propres blocs. Lorsque la partition est résolue, une réorganisation (reorg) résout la bifurcation, mais les transactions effectuées sur la branche la plus courte sont annulées.
Les attaques à 51 % (ou attaques à 34 % sur les chaînes basées sur le BFT) permettent à un attaquant disposant d’une puissance de consensus majoritaire de réécrire l’historique récent de la chaîne. L’attaquant génère une chaîne privée qui diverge de la chaîne publique, accumule davantage de preuves de travail ou d’attestations de validateurs, puis la diffuse sur le réseau. La chaîne de l’attaquant ayant un poids cumulé supérieur, le réseau l’adopte comme chaîne canonique, rendant ainsi orphelins les blocs récents de la chaîne publique. Cela permet une double dépense : l’attaquant envoie des fonds sur la chaîne publique, attend la confirmation, puis publie sa chaîne privée qui n’inclut pas la transaction, obtenant ainsi les biens tout en conservant les fonds.
Défaillances au niveau de la couche application
La couche applicative englobe les contrats intelligents, les protocoles DeFi, les oracles et la logique on-chain qui gère des milliards de dollars de fonds appartenant aux utilisateurs. Les défaillances de la couche applicative constituent la source la plus fréquente et la plus coûteuse de pertes liées à la blockchain.
Les attaques par réentrée exploitent une vulnérabilité dans laquelle un contrat intelligent effectue un appel externe vers un autre contrat avant de mettre à jour son propre état. Le contrat appelé peut « réentrer » dans le contrat d’origine et réexécuter la même fonction avant que la mise à jour de l’état n’ait lieu, ce qui peut entraîner un détournement de fonds. Le piratage du DAO en 2016, qui a conduit à la scissionEthereum et entraîné environ 60 millions de dollars de pertes, était une attaque par réentrée. Bien qu’elles soient connues depuis des années, les vulnérabilités de réentrée continuent d’apparaître dans de nouveaux contrats qui ne respectent pas le modèle « vérifications-effets-interactions ».
Les vulnérabilités de débordement et de sous-débordement d'entiers surviennent lorsque des opérations arithmétiques produisent des résultats hors de la plage du type de données, provoquant ainsi un bouclage des valeurs. Une soustraction qui devrait donner un nombre négatif peut au contraire produire un nombre positif astronomiquement élevé, permettant ainsi à un attaquant de réclamer plus de jetons qu’il n’y a droit. La version 0.8.0 de Solidity a ajouté des contrôles de débordement intégrés qui annulent l'opération en cas de débordement, mais les contrats compilés avec des versions plus anciennes ou ceux utilisant des blocs arithmétiques non vérifiés restent vulnérables.
Les failles de contrôle d'accès surviennent lorsque les fonctions administratives ne font pas l'objet de vérifications d'autorisation adéquates, ce qui permet à des utilisateurs non autorisés d'appeler des fonctions réservées aux titulaires du contrat ou à des rôles spécifiques. Cela inclut notamment les fonctions de mise à jour non protégées (permettant à n'importe qui de remplacer la logique du contrat), l'absence de vérifications de propriété sur les fonctions de retrait, ainsi qu'un accès basé sur les rôles mal configuré.
La manipulation d’oracles constitue un vecteur d’attaque particulièrement insidieux, car elle exploite l’interface entre les données « on-chain » et « off-chain ». Les contrats intelligents qui s’appuient sur des oracles de prix pour les opérations de prêt, de liquidation ou de produits dérivés peuvent être amenés à agir sur la base de prix manipulés. Les attaques par « flash loan » constituent le moyen le plus courant : un attaquant emprunte une grande quantité de tokens, les utilise pour manipuler le cours sur un DEX auquel l’oracle fait référence, déclenche une action lucrative sur le protocole cible au cours manipulé, puis rembourse le « flash loan », le tout en une seule transaction atomique. Le contrat intelligent du protocole cible a fonctionné exactement comme prévu. La faille résidait dans la conception de l’oracle, qui ne tenait pas compte des manipulations à court terme.
Les failles de gouvernance ciblent les mécanismes de gouvernance décentralisés des DAO et des protocoles DeFi. Un attaquant acquiert suffisamment de jetons de gouvernance (souvent via des prêts éclair) pour faire adopter une proposition malveillante visant à prélever des fonds sur la trésorerie, à modifier les paramètres du protocole afin de créer des conditions propices à une exploitation, ou à modifier les contrôles d'accès pour s'octroyer des pouvoirs administratifs.
Pannes au niveau de l'infrastructure
Les défaillances au niveau de l'infrastructure ne compromettent pas la blockchain elle-même, mais empêchent les applications et les utilisateurs d'interagir avec celle-ci. Pour les utilisateurs finaux et les développeurs, une défaillance de l'infrastructure peut être impossible à distinguer d'une défaillance au niveau de la chaîne, car le résultat concret est le même : l'application ne fonctionne pas.
Les pannes de nœuds et les échecs de synchronisation mettent les nœuds hors ligne ou les amènent à fournir des données obsolètes. Un nœud qui a pris plusieurs blocs de retard par rapport à la pointe de la chaîne renvoie des soldes obsolètes, passe à côté des transactions récentes et peut rejeter des transactions valides qui dépendent de changements d'état récents. Les applications qui reposent sur un seul nœud (sans basculement) cessent complètement de fonctionner lorsque ce nœud tombe en panne.
Les pannes des fournisseurs affectent simultanément tous les clients d'un fournisseur d'infrastructure donné. Si un fournisseur RPC majeur subit une panne, toutes les applications utilisant les points de terminaison de ce fournisseur perdent l'accès à la blockchain. Il s'agit là d'un risque de centralisation au sein d'un écosystème censé être décentralisé : le fait que des milliers d'applications partagent le même fournisseur d'infrastructure crée un point de défaillance unique.
Les incidents chez les fournisseurs de services cloud affectent l'infrastructure blockchain au même titre que n'importe quel autre service hébergé dans le cloud. Lorsqu'AWS, GCP ou un autre fournisseur de services cloud subit une panne régionale, tous les nœuds de blockchain fonctionnant dans cette région se retrouvent hors ligne. Étant donné qu'un nombre disproportionné de nœuds de blockchain s'appuie sur un petit nombre de fournisseurs de services cloud, les pannes de cloud peuvent avoir un impact considérable sur la santé du réseau et la disponibilité des applications.
Les défaillances du DNS et du réseau peuvent empêcher les applications d'accéder à leurs points de terminaison RPC, même lorsque ceux-ci fonctionnent normalement. Le détournement du DNS, les problèmes de routage BGP et les dysfonctionnements liés aux certificats TLS peuvent tous perturber la connexion entre une application et son infrastructure blockchain.
Stratégies d'atténuation
Pour se prémunir contre les modes de défaillance de la blockchain, il faut adopter une approche par couches qui tienne compte de ces trois niveaux.
Au niveau de la couche de consensus, la diversité des clients constitue la défense la plus efficace. Le fait d’utiliser plusieurs implémentations de clients garantit qu’un bug dans un client n’affecte pas l’ensemble du réseau. La répartition des enjeux joue également un rôle important : favoriser un ensemble de validateurs large et décentralisé réduit le risque de défaillances coordonnées et d’attaques à 51 %. Au niveau de la couche applicative, les audits de sécurité, la vérification formelle et les programmes de prime aux bugs constituent les principales défenses.
Les contrats intelligents doivent être audités par plusieurs cabinets indépendants avant leur déploiement. La vérification formelle prouve mathématiquement que le code du contrat correspond à sa spécification, permettant ainsi de détecter des bogues qui pourraient échapper à une révision manuelle. Les programmes de prime aux bogues incitent les hackers « white hat » à trouver et à divulguer de manière responsable les vulnérabilités. Les mises à jour à délai de déclenchement donnent à la communauté le temps d’examiner les modifications proposées avant leur entrée en vigueur, empêchant ainsi le déploiement immédiat de mises à jour malveillantes ou comportant des bogues. Les exigences de signatures multiples pour les fonctions administratives garantissent qu’aucune clé compromise ne puisse à elle seule exécuter des opérations privilégiées.
Au niveau de l’infrastructure, la redondance entre les fournisseurs, les régions et les plateformes cloud constitue le fondement de la résilience. Les applications ne doivent jamais dépendre d’un seul fournisseur RPC, d’un seul centre de données ou d’un seul fournisseur de cloud. Les disjoncteurs de circuit empêchent les défaillances en cascade en déconnectant automatiquement les composants défaillants avant qu’ils ne provoquent la panne des systèmes en amont. Les conceptions permettant une dégradation en douceur permettent aux applications de continuer à fournir leurs fonctionnalités essentielles (comme l’affichage des soldes) même lorsque certains composants de l’infrastructure sont indisponibles.
Comment Quicknode sa résilience
L'infrastructure Quicknode est conçue pour atténuer les défaillances au niveau de l'infrastructure grâce à une répartition géographique couvrant plus de 14 régions et plus de 5 fournisseurs de services cloud et de serveurs physiques, à la diversité des clients lorsque cela est possible, à un basculement automatique qui redirige les requêtes hors des nœuds défaillants, ainsi qu'à une surveillance 24 h/24 et 7 j/7 assurée par une équipe dédiée aux opérations blockchain.
Quicknode Streams la résilience des pipelines de données grâce à une livraison garantie, un traitement par ordre de finalité et une gestion automatique des réorganisations. Lorsque des événements au niveau de la couche de consensus, tels que des réorganisations, se produisent, Streams et corrige automatiquement les données concernées. En ce qui concerne la surveillance au niveau de la couche applicative, Streams aux développeurs de surveiller des événements de contrat spécifiques, des schémas de transactions inhabituels et des changements d'état susceptibles d'indiquer une attaque en cours.
Pour les équipes soumises aux exigences de fiabilité les plus strictes, Clusters dédiés Quicknode Clusters une infrastructure isolée assortie de contrats de niveau de service (SLA) garantissant une disponibilité optimale, indépendamment du trafic partagé. Cela élimine le risque lié au « voisin bruyant », où un pic de trafic provenant d’un autre client pourrait nuire à vos performances, et fournit l’isolation nécessaire aux applications blockchain critiques.
Quels sont les types de défaillances les plus courants liés à la blockchain ?
Les modes de défaillance évoqués ci-dessus peuvent être classés en fonction de la couche dont ils proviennent, ce qui permet également d'identifier les responsables de la protection contre chacun d'entre eux. Le tableau ci-dessous récapitule les défaillances les plus courantes, donne un exemple représentatif et indique à quel niveau les mesures d'atténuation s'appliquent.
Couche
Panne courante
Exemple
Là où s'incarne l'atténuation
Consensus
Attaque à 51 % ou réorganisation
La majorité réécrit l'histoire récente
Protocole et ensemble de validateurs
Consensus
Partition du réseau ou arrêt
Les validateurs ne parviennent pas à atteindre le seuil
Protocole et diversité des clients
Demande
Réentrance ou manipulation d'oracle
Un « flash loan » épuise un pool de prêts
Contrats intelligents et audits
Demande
Exploitation d'une faille de contrôle d'accès ou de gouvernance
Fonction d'administration non protégée
Contrat intelligent et signature multiple
Infrastructures
Panne d'un nœud ou interruption de service du fournisseur
endpoint RPC endpoint des données obsolètes
Infrastructure redondante
Comment détecter les défaillances de la blockchain avant qu'elles n'entraînent des pertes ?
La détection fait toute la différence entre un incident maîtrisé et un incident catastrophique. La surveillance continue de l'infrastructure blockchain met en évidence en temps réel les retards des nœuds, les pics d'erreurs et les décalages de synchronisation, tandis qu'une observabilité plus large relie ces signaux au comportement des applications, ce qui vous permet de détecter l'apparition d'une faille de sécurité ou d'une panne avant même que les utilisateurs ne s'en rendent compte.
Quelle est la différence entre un « chain halt » et une « chain reorg » ?
Ces deux types de défaillances au niveau de la couche de consensus sont souvent confondus. Un « arrêt de la chaîne » met complètement fin à la production de blocs, car les validateurs ne parviennent pas à atteindre le seuil de consensus ; aucune nouvelle transaction n’est donc confirmée. Une « réorganisation de la blockchain » continue de produire des blocs, mais remplace ceux qui ont été récemment acceptés par une chaîne concurrente, ce qui peut annuler des transactions qui semblaient confirmées.
En quoi la redondance des infrastructures permet-elle de réduire le risque de panne ?
La plupart des pannes au niveau de l'infrastructure sont dues à un point de défaillance unique. Comprendre l'importance de la redondance de l'infrastructure conduit naturellement à des architectures faisant appel à plusieurs fournisseurs et plusieurs zones géographiques, ainsi qu'à un basculement automatique qui contourne un nœud défaillant avant même que les requêtes ne génèrent des erreurs.
Foire aux questions
Quels sont les trois niveaux de défaillance d'une blockchain ?
Les défaillances peuvent provenir de la couche de consensus (bogues des validateurs, partitions, attaques à 51 %), de la couche applicative (bogues des contrats intelligents, manipulation des oracles, failles de gouvernance) ou de la couche d'infrastructure (plantages de nœuds, pannes de fournisseurs et de services cloud). Les systèmes résilients offrent une protection contre ces trois types de défaillances.
Quelle est la cause la plus fréquente des pertes liées à la blockchain ?
Les défaillances au niveau de la couche applicative, notamment les vulnérabilités des contrats intelligents et la manipulation des oracles, sont les plus fréquentes et les plus coûteuses. La chaîne sous-jacente fonctionne souvent exactement comme prévu, tandis que la logique défaillante d’un contrat ou d’un oracle est exploitée.
Une simple panne d'un fournisseur RPC peut-elle entraîner la mise hors service de mon application ?
Oui. Si votre application dépend d'un seul fournisseur, d'un seul centre de données ou d'une seule région cloud, toute panne survenant à ce niveau vous met hors ligne. La répartition du trafic entre des fournisseurs et des régions redondants, associée à un basculement automatique, permet d'éliminer ce point de défaillance unique.
Une attaque à 51 % est-elle identique à une partition du réseau ?
Non. Une attaque à 51 % consiste en une tentative délibérée, menée par une majorité des participants au consensus, de réécrire l'historique, tandis qu'une partition du réseau correspond à une perte accidentelle de communication entre les validateurs. Ces deux phénomènes peuvent entraîner des réorganisations, mais leurs causes et les moyens de s'en prémunir diffèrent.
Comment se prémunir contre la manipulation d'oracle ?
Utilisez des oracles qui agrègent les prix provenant de différentes sources et sur plusieurs périodes, évitez de vous fier à un seul cours au comptant d'un DEX, et mettez en place des contrôles de cohérence et des disjoncteurs. Ces mesures permettent d'atténuer les attaques par « flash loan » qui faussent brièvement un flux de prix.
