Aperçu des défis de sécurité

Une caractéristique déterminante des blockchains est la nature atomique des transactions : une fois qu'une mise à jour est enregistrée dans la blockchain, il n'y a aucune possibilité d'intervention ou de retour en arrière. Cela offre de fortes garanties de cohérence et de sécurité au niveau du protocole, mais expose les utilisateurs à un risque opérationnel accru : une seule erreur, une clé compromise ou une approbation précipitée peut entraîner une perte irréversible.

En conséquence, une part importante de la sécurité repose sur l'utilisateur. Pour utiliser Ethereum en toute sécurité, les individus et les organisations doivent détenir et gérer des clés de manière sécurisée, interagir avec des applications en chaîne et utiliser leurs clés pour signer des transactions afin de transférer des actifs ou de mettre à jour l'état d'Ethereum.

Chacune de ces exigences introduit des risques comme la compromission ou la perte de clés, des approbations précipitées ou mal informées, ou la compromission du logiciel de portefeuille sur lequel les utilisateurs comptent pour les informer et les guider dans leurs interactions avec Ethereum.

1.1 Gestion des clés

De nombreux utilisateurs ne sont pas équipés pour gérer les clés cryptographiques en toute sécurité.

La plupart des portefeuilles logiciels largement utilisés reposent sur le stockage sécurisé par les utilisateurs de phrases de récupération représentant leur clé privée cryptographique sous-jacente, ce qui les conduit souvent à utiliser des solutions de contournement non sécurisées comme stocker les phrases de récupération en texte brut, sur des services cloud, ou les écrire sur papier.

Les portefeuilles matériels sont une alternative, permettant aux utilisateurs de gérer une clé cryptographique stockée dans un dispositif physique dédié. Cependant, les portefeuilles matériels ont leurs propres défauts et surfaces d'attaque. Les portefeuilles matériels peuvent être perdus, endommagés ou volés. De nombreux portefeuilles matériels ne sont pas open source et peuvent avoir des chaînes d'approvisionnement opaques, augmentant le risque d'une attaque de la chaîne d'approvisionnement où des dispositifs compromis sont vendus sur le marché.

Que les clés soient gérées dans un portefeuille logiciel ou matériel, de nombreux utilisateurs sont, à juste titre, nerveux à l'idée de l'auto-garde lorsqu'elle peut être compromise par un vol physique ou une agression.

Les utilisateurs professionnels et institutionnels font face à des défis supplémentaires en matière de gestion des clés. Si des employés individuels détiennent des clés (par exemple, dans le cadre d'un portefeuille multisig), l'organisation doit pouvoir les remplacer et en créer de nouvelles en raison des changements de personnel au fil du temps. Les exigences de conformité dans différentes industries et juridictions peuvent nécessiter des flux de travail personnalisés ou des pistes d'audit non pris en charge par les logiciels de portefeuille existants. Dans certains cas, les utilisateurs professionnels se tournent vers des dépositaires tiers pour les actifs numériques, ce qui peut introduire une autre couche de risques de sécurité à considérer.

1.2 Signature aveugle et incertitude des transactions

Les utilisateurs approuvent régulièrement les transactions « à l’aveugle » sans comprendre ce qu’ils font. Les portefeuilles présentent souvent des données hexadécimales brutes, des adresses de contrat tronquées ou d'autres informations insuffisantes pour que l'utilisateur comprenne les conséquences d'une transaction donnée. Cela rend les utilisateurs de toutes sortes vulnérables aux contrats intelligents malveillants, au phishing, aux escroqueries, aux interfaces usurpées, aux compromissions de l'interface utilisateur et aux erreurs humaines de base.

1.3 Gestion des approbations et des permissions

Dans de nombreuses applications Ethereum, il est courant que les utilisateurs accordent certaines permissions à l'application sous-jacente dans le cadre d'une utilisation normale. Par exemple, un utilisateur pourrait accorder à un échange décentralisé comme Uniswap la permission de déplacer ses jetons pour les échanger contre de l'ETH.

Ces approbations peuvent avoir des limites sur le montant, mais de nombreux portefeuilles accordent par défaut des approbations illimitées sans date d'expiration. Il n'existe aucun moyen pour les utilisateurs de gérer ou de réviser leurs approbations en cours depuis la plupart des portefeuilles.

Cela peut exposer les utilisateurs à des applications malveillantes ou à des interfaces compromises, car le modèle par défaut pour de nombreux utilisateurs est d'accorder des approbations illimitées qui peuvent être utilisées pour vider leurs fonds. Même si un utilisateur accorde une approbation à un contrat intelligent légitime, si ce contrat est ultérieurement compromis alors que l'approbation reste en place, le contrat compromis pourrait vider les fonds de l'utilisateur.

Cela représente également un risque pour les utilisateurs organisationnels. Par exemple, une organisation pourrait choisir d'accorder à un routeur DEX une allocation illimitée en USDC pour des raisons de commodité opérationnelle, ce qui les expose à des risques si le contrat du routeur est mis à jour.

1.4 Interfaces web compromises

La plupart des utilisateurs n'interagissent pas directement avec un contrat intelligent, mais via une interface web sur leur appareil mobile ou leur navigateur web.

Ces interfaces peuvent être vulnérables aux attaques par des moyens connus tels que le détournement de DNS, l'injection de JavaScript malveillant, l'hébergement non sécurisé ou diverses dépendances tierces. Une interface utilisateur d'application compromise peut rediriger les utilisateurs de toutes sortes vers des contrats intelligents malveillants ou les amener à signer des transactions trompeuses.

1.5 Confidentialité

La confidentialité peut atténuer ou amplifier les risques de sécurité pour les utilisateurs de toutes sortes.

Des protections de confidentialité plus faibles exposent les utilisateurs individuels à une variété de menaces ciblées comme le phishing, l'exploitation, les escroqueries ou les attaques physiques. De nombreux modèles d'interfaces utilisateurs courants exposent les utilisateurs, par exemple, la réutilisation d'adresses, les données KYC et d'autres fuites de métadonnées.

Pour les institutions et les entreprises, la confidentialité est souvent une exigence commerciale fondamentale pour des raisons de conformité ou pour certains cas d'utilisation. En plus de ces problèmes, cela peut créer une exposition à des risques de sécurité spécifiques. Par exemple, un utilisateur d'un système de chaîne d'approvisionnement construit sur Ethereum peut exiger de fortes garanties de confidentialité pour protéger les actifs de propriété intellectuelle qui pourraient être compromis si le système était transparent.

1.6 Fragmentation

Il y a un manque de cohérence dans la manière dont différents portefeuilles gèrent les comportements de base comme l'affichage des transactions, la gestion des approbations ou l'étiquetage des contrats. Cette fragmentation de l'expérience utilisateur ajoute des frictions à la capacité des utilisateurs à apprendre à utiliser les portefeuilles en toute sécurité et augmente les risques.

Par exemple, les utilisateurs ne peuvent pas compter sur des indicateurs d'expérience utilisateur cohérents pour se protéger du phishing et de l'usurpation d'identité, car ils diffèrent selon les portefeuilles. Ils ne peuvent pas se faire d'idées fiables sur le fonctionnement d'Ethereum si chaque outil fonctionne différemment.

La sécurité des contrats intelligents s'est radicalement améliorée au cours de l'histoire d'Ethereum. Les premiers incidents de sécurité, comme le piratage de la DAO, ont motivé l'écosystème à se professionnaliser et à améliorer les garde-fous tout au long du cycle de vie du logiciel qui mène au déploiement du code en chaîne. Parmi les principales avancées, on peut citer :

• L'audit de sécurité est devenu une pratique standard, avec plusieurs entreprises de sécurité entrant dans l'écosystème et développant leur expertise.
• Les outils, les tests et les systèmes d'analyse statique ont mûri et sont devenus une pratique standard.
• Les bibliothèques de composants communs pré-audités ont fourni aux développeurs des blocs de construction sécurisés par défaut.
• Les techniques de vérification formelle ont été adoptées, en particulier pour les ponts, les systèmes de staking et les contrats de grande valeur.
• La culture de sécurité et les meilleures pratiques de l'écosystème se sont améliorées.
• La création de programmes de primes significatifs qui ont renforcé la couche applicative.

Cependant, il reste des faiblesses et des domaines à améliorer dans ce domaine.

2.1 Vulnérabilités des contrats

Malgré les progrès dans la sécurité des contrats intelligents, il existe encore des vulnérabilités qui peuvent entraîner des problèmes de sécurité importants, notamment :

• Risque de mise à jour des contrats. Certains contrats sont conçus pour être modifiables après leur déploiement, afin de permettre à une équipe de développement de continuer à mettre à jour et à améliorer une application. Cependant, cela introduit des risques. Les mises à jour pourraient entraîner de nouvelles vulnérabilités ou la perte totale des fonds des utilisateurs en cas de mise à niveau malveillante.
• Réentrance, lorsqu'un contrat A appelle un contrat externe B avant de mettre à jour son propre état interne, et que le contrat B rappelle le contrat A d'origine avant que le premier appel ne soit terminé.
• Utilisation non sécurisée de bibliothèques externes, lorsqu'un contrat appelle une bibliothèque externe qui peut être non auditée, malveillante ou susceptible de mise à jour.
• Composants non audités. Bien que l'audit et l'utilisation de bibliothèques standard se soient améliorés, les développeurs s'appuient parfois sur des composants non audités dans leurs applications.
• Échecs de contrôle d'accès, lorsque les permissions sont mal configurées ou définies de manière trop large, permettant à des attaquants de réaliser des actions malveillantes.
• Accès non autorisé, lorsqu'une clé privée capable de contrôler le contrat est obtenue par un acteur malveillant.
• Ponts et interactions inter-chaînes. Les ponts et les protocoles inter-chaînes introduisent une complexité supplémentaire, et les attaquants peuvent exploiter les faiblesses dans la manière dont les messages inter-chaînes sont transmis ou validés.
• Délégation ou mauvaise utilisation de signatures de comptes externes (EOA). Des applications malveillantes peuvent inciter les utilisateurs à signer une délégation complète de leur compte à une autre partie, permettant un vol. Les applications malveillantes peuvent également utiliser les messages signés par l'utilisateur de manière inattendue, par exemple dans une attaque par rejeu.
• Risque émergent de bogues introduits par la génération de code par IA ou les outils de refactorisation automatisée.

2.2 Expérience des développeurs, outils et langages de programmation

Les vulnérabilités finissent dans le code déployé en raison d'erreurs des développeurs. Les outils pour développeurs améliorés ont rendu beaucoup plus facile le déploiement de contrats intelligents sécurisés. Cependant, des problèmes subsistent.

• Manque de paramètres sécurisés par défaut dans les frameworks populaires. Certains outils privilégient la flexibilité ou la rapidité à la sécurité, en définissant des paramètres non sécurisés comme des approbations de jetons illimitées dans la fonction approve(), ou en omettant d'inclure des modèles de contrôle d'accès par défaut.
• Code personnalisé pour des contrôles opérationnels avancés. Les utilisateurs institutionnels ayant des exigences opérationnelles complexes doivent souvent construire des fonctionnalités requises de toutes pièces, augmentant le risque de vulnérabilités. Il manque des composants ou frameworks sécurisés standardisés pour les flux de travail de sécurité avancés.
• Couverture de test incohérente à travers les piles d'outils, ainsi qu'un manque de normes autour de l'utilisation de techniques éprouvées comme le fuzzing ou la vérification d'invariants.
• Faible adoption des méthodes de vérification formelle. Les techniques de vérification formelle sont puissantes, mais elles sont complexes, coûteuses, nécessitent une expertise spécialisée et ne sont pas bien intégrées dans les flux de travail standard des développeurs, où elles pourraient être utilisées beaucoup plus tôt dans la production de logiciels pour vérifier la sécurité au stade des spécifications.
• Problèmes liés à la vérification des contrats. Les utilisateurs et les développeurs ne peuvent pas facilement évaluer la fiabilité des contrats déployés, l'étendue de leur validation de sécurité (par exemple, les audits de code) ou la présence de risques latents. Bien que des solutions existent à cet effet, de nombreux problèmes subsistent. Les outils qui traitent ces problèmes ne sont pas largement adoptés, les normes qui unifieraient les approches restent fragmentées, et certains des services existants sont eux-mêmes des dépendances centralisées.
• Risques liés aux compilateurs. Les compilateurs (les logiciels qui convertissent le code lisible par l'humain, comme Solidity, en bytecode utilisé par l'EVM) peuvent avoir des défauts qui introduisent des erreurs dans les contrats intelligents avant leur déploiement. L'écosystème Ethereum dépend aujourd'hui principalement du compilateur solc, ce qui signifie qu'un bogue pourrait avoir des effets généralisés.
• Diversité et profondeur des langages de programmation. Bien que Solidity dispose d'un écosystème d'outils approfondi, certains développeurs souhaitent des fonctionnalités de sécurité plus modernes, comme celles présentes dans d'autres langages de programmation, telles que la sécurité de la mémoire.

2.3 Évaluation des risques du code en chaîne

Les institutions et les entreprises disposent de processus, normes et exigences existants pour évaluer la sécurité des technologies et systèmes dont elles dépendent. Cependant, les cadres existants ne s'appliquent souvent pas directement aux contrats intelligents, supposant généralement un code mutable, un contrôle centralisé des modifications et des lignes claires de reddition ou de responsabilité juridique. Les systèmes construits sur des contrats intelligents peuvent parfois briser ces hypothèses, rendant difficile pour les organisations d'adopter Ethereum et de gérer les risques de manière appropriée.

Ces systèmes constituent une surface d'attaque à la fois pour la couche des portefeuilles et des applications (par exemple, les points d'accès RPC pour les portefeuilles) et pour le protocole Ethereum lui-même (par exemple, de nombreux validateurs sont hébergés sur une infrastructure cloud). La compromission de clés privées, le phishing et le manque de contrôles d'accès granulaires peuvent entraîner des pannes à grande échelle, des vols ou des modifications non autorisées, même si le protocole blockchain sous-jacent reste sécurisé.

3.1 Chaînes de couche 2

Les chaînes de couche 2 (L2) servent d'extensions pour Ethereum, permettant des environnements plus rapides et à moindre coût tout en conservant certaines des garanties de sécurité caractéristiques du réseau principal d'Ethereum (selon leur conception spécifique). Cependant, elles présentent également leurs propres surfaces d'attaque distinctes, notamment :

• Complexité des actifs pontés multi-sauts. Lorsque des actifs transitent entre la L1 et plusieurs L2, ils sont exposés à plusieurs ensembles de contrats qui doivent tous être sécurisés. Des erreurs de comptabilité ou des pannes dans les chaînes L2 peuvent introduire des vulnérabilités exploitables par des attaquants.
• Les L2 de type rollup dépendent de systèmes de preuve pour garantir la correction des mises à jour d'état. Des bogues ou des mauvaises configurations dans ces systèmes peuvent bloquer ou empêcher la finalisation, ou permettre la finalisation de mises à jour d'état erronées, entraînant une perte de fonds pour les utilisateurs.
• Les conseils de sécurité sont des groupes de détenteurs de clés qui servent de mécanisme de secours pour mettre à jour le logiciel L2 ou répondre à certaines urgences. Les conseils de sécurité eux-mêmes posent des risques, car une compromission ou une collusion entre les membres pourrait mettre en danger les fonds des utilisateurs ou geler les actifs.

Consultez L2Beatopens in a new tab pour un cadre détaillé et un tableau de bord de surveillance qui évalue et compare les performances et la sécurité des L2.

3.2 Infrastructure RPC et nœuds

Les applications Ethereum dépendent d'un petit nombre de fournisseurs d'infrastructure pour l'accès RPC, les API et les services de nœuds. Cela inclut les fournisseurs d'infrastructure spécifiques à la cryptographie, ainsi que les services cloud traditionnels couramment utilisés pour héberger des nœuds (par exemple, AWS, Cloudflare, Hetzner).

Si ces fournisseurs d'infrastructure étaient hors ligne ou tentaient de censurer ou de limiter l'accès, de nombreux utilisateurs pourraient être empêchés d'accéder à Ethereum via leur portefeuille ou application, jusqu'à ce qu'ils puissent migrer vers un nouveau fournisseur RPC ou autre infrastructure. Certains de ces fournisseurs ont déjà suspendu ou fermé des comptes associés à des activités blockchain, soulevant des préoccupations quant à leur fiabilité à long terme pour les applications décentralisées.

3.3 Vulnérabilités au niveau du DNS

Le système de noms de domaine (DNS) est une couche fondamentale d'internet, mais il est également centralisé et peut être compromis. De nombreux utilisateurs accèdent aux applications via des domaines web, qui sont susceptibles de :

• Détournement de DNS, où un attaquant insère une fausse interface malveillante.
• Saisie de domaine, où un gouvernement ou un registraire peut saisir des domaines.
• Phishing via des domaines similaires, où les attaquants enregistrent des noms presque identiques pour tromper les utilisateurs.

3.4 Chaîne d'approvisionnement logicielle et bibliothèques

Les développeurs Ethereum s'appuient sur des bibliothèques open-source, souvent téléchargées directement depuis des services comme npm, crates.io ou GitHub. Si ces bibliothèques sont compromises, elles peuvent servir de vecteur pour des attaques telles que :

• Injection de paquets malveillants, où des attaquants compromettent un paquet largement utilisé ou en publient un sous un nom similaire
• Dépendances détournées, où les mainteneurs perdent le contrôle d'un projet et un acteur malveillant introduit du code nuisible
• Compromission des développeurs, où les paquets installés contiennent du code qui donne à l'attaquant le contrôle sur l'ordinateur du développeur.

3.5 Services de livraison de frontend et risques associés

De nombreuses applications Ethereum servent leurs interfaces via un réseau de distribution de contenu (CDN) ou une plateforme d'hébergement basée sur le cloud (par exemple, Vercel, Netlify, Cloudflare). Si ces services sont compromis, ils peuvent servir de vecteur pour des attaques comme l'injection de JavaScript malveillant, où les attaquants servent une interface modifiée aux utilisateurs.

3.6 Censure au niveau des fournisseurs de services Internet

Les fournisseurs de services Internet (ISP) ou les États-nations peuvent utiliser le contrôle de l'infrastructure internet sous-jacente pour censurer l'accès à Ethereum. Par exemple, ces attaques pourraient inclure :

• Blocage ou limitation du trafic vers les ports Ethereum courants
• Filtrage des requêtes DNS qui renvoient vers des services liés à Ethereum
• Géorestriction ou interdictions d'IP contre les nœuds Ethereum connus
• Inspection approfondie des paquets pour identifier et censurer le trafic lié au protocole Ethereum

De nombreuses techniques de base sont déjà utilisées par des gouvernements autoritaires à travers le monde pour supprimer l'accès à l'information, aux outils de protestation ou aux cryptomonnaies aujourd'hui.

Le protocole de consensus d'Ethereum s'est révélé robuste en pratique, avec zéro temps d'arrêt depuis son lancement en 2015 et à travers plusieurs mises à jour. Cependant, il reste des domaines à améliorer à long terme pour rendre le système plus résilient et sécurisé.

4.1 Fragilité du consensus et risques de récupération

Les règles de choix de fourche et de finalité d'Ethereum sont résilientes, mais elles ne sont pas invulnérables. Dans certaines conditions limites (comme un désaccord prolongé des validateurs, des bogues clients ou des partitions réseau), le consensus pourrait s'arrêter ou diverger temporairement. Dans des conditions extrêmes, cela pourrait entraîner des pénalités en cascade pour les validateurs par des fuites d'inactivité ou des slashings, ce qui pourrait à son tour provoquer une fuite de capital des validateurs.

4.2 Diversité des clients

La diversité des clients, leader dans l'industrie d'Ethereum, protège le réseau contre les bogues dans un seul client. Cependant, la diversité des clients pourrait encore être améliorée avec une adoption accrue des clients minoritaires pour réduire encore plus ces risques.

4.3 Centralisation du staking et dominance des pools

Une quantité significative du poids des validateurs est concentrée dans les protocoles de staking liquide, les services de garde et les grands opérateurs de nœuds. Cette concentration peut entraîner des risques tels que :

• Capture ou influence de la gouvernance. Si des entités contrôlant de grandes quantités de mise (ou des entités ayant le pouvoir légal d'influencer ces entités) se coordonnaient, elles pourraient avoir une influence démesurée sur les blocs proposés et attestés, pouvant censurer les utilisateurs ou influencer les mises à jour du protocole.
• Homogénéité dans le choix des clients et la configuration de l'infrastructure, ce qui peut augmenter les risques d'échecs corrélés.

4.4 Sanctions sociales non définies et lacunes de coordination

Dans certains cas de défaillance extrême, Ethereum compterait sur le « slashing social » pour pénaliser les validateurs ayant agi de manière malveillante afin d’attaquer le réseau (voir section 6.1). Cependant, l’infrastructure, les normes et les processus attendus pour ce type de sanction sont peu développés. Il n’existe pas de mécanisme établi que la communauté pourrait utiliser pour mener ce processus.

4.5 Vecteurs d’attaque économiques et de théorie des jeux

De nombreux vecteurs d’attaque économiques potentiels restent peu étudiés, notamment :

• Attaques de type griefing ou slash griefing. Les validateurs peuvent subir des coûts ou des pénalités de slashing non pas à cause de leurs propres erreurs, mais en raison d’un comportement hostile visant uniquement à nuire aux autres, au détriment de l'attaquant.
• Sorties stratégiques ou inactivité programmée. Les validateurs pourraient délibérément se déconnecter ou sortir à des moments critiques afin de maximiser leurs profits ou perturber le consensus avec des pénalités minimales.
• Collusion entre validateurs ou relais. Un comportement coordonné entre validateurs, ou entre relais et validateurs, pourrait réduire la décentralisation ou extraire la MEV (Miner Extractable Value).
• Exploitation des incitations dans des cas limites liés au MEV, à la séparation proposeur-constructeur ou à la conception du staking liquide. Certains acteurs peuvent manipuler des conditions rares du protocole pour obtenir des récompenses disproportionnées.

4.6 Risque quantique

La cryptographie centrale d’Ethereum (par exemple les signatures sur courbes elliptiques comme secp256k1) pourrait un jour être déchiffrée par des ordinateurs quantiques. Bien que ce risque ne soit pas imminent, une menace crédible pourrait instantanément rendre vulnérables les portefeuilles, contrats et clés de staking existants. Ce défi futur affaiblit les garanties à long terme d’Ethereum envers ses utilisateurs.

Les trajectoires de migration vers une cryptographie résistante aux ordinateurs quantiques (par exemple, via des schémas de signature post-quantiques) doivent être conçues, testées et éventuellement intégrées au protocole des années avant leur nécessité. Les organisations de l’écosystème Ethereum, y compris la Fondation Ethereum, explorent activement ces options et surveillent les risques.

Même un écosystème blockchain idéal comportera des risques, des attaques et des vulnérabilités. Lorsque des problèmes surviennent, il doit exister des systèmes efficaces pour atténuer, détecter et répondre. Parmi les défis à relever, on trouve :

• Contacter l’équipe concernée. Il peut être difficile de contacter l’équipe dont l’application a été compromise. Cela peut entraîner des heures de retard, limitant la capacité des intervenants à récupérer les fonds.
• Faire remonter les problèmes auprès des organisations concernées. Lorsque le problème concerne une plateforme (comme un réseau social ou une bourse centralisée), il peut être difficile pour les intervenants de faire remonter l’incident s’ils ne disposent pas d’un contact préalable.
• Coordination de la réponse. Il est souvent difficile de savoir combien d’équipes d’intervention en cas d’incident assistent l’application concernée, ce qui peut entraîner des problèmes de communication ou des efforts inutiles, alors qu’une action coordonnée aurait pu être plus efficace.
• Manque de capacités de surveillance. Il peut être difficile de surveiller les problèmes onchain et offchain, ce qui permettrait d’alerter tôt et d’assurer une réponse rapide aux menaces.
• Accès à l’assurance. L’assurance est un outil essentiel pour limiter les pertes dans la plupart des systèmes traditionnels liés à l’argent, aux systèmes financiers, à l’identité et à d’autres informations précieuses. Cependant, aujourd’hui, peu d’options d’assurance sont disponibles auprès des services financiers traditionnels pour l’écosystème crypto.

Ces risques ont tendance à être plus orientés sur le long terme et concernent Ethereum dans son ensemble, plutôt que la sécurité des utilisateurs ou applications individuels.

6.1 Centralisation des stakes

La centralisation de grandes quantités de mise peut représenter un risque pour Ethereum dans son ensemble si les entités contrôlant cette mise décident de se livrer à des pratiques collusoires.
Cette centralisation économique crée un potentiel de capture de la gouvernance sociale. Si un petit groupe de validateurs contrôle une supermajorité dde la mise, ils pourraient :

• Se coordonner sur des forks ou y résister.
• Censurer certaines transactions ou certains contrats.
• Saper le consensus de la communauté en menaçant de se retirer ou de s’y opposer.

Si un tel scénario extrême devait se produire, la communauté Ethereum a suggéré que le « slashing social » pourrait être la solution. Le slashing social consiste à utiliser un consensus social hors chaîne pour décider de pénaliser les validateurs qui se comportent mal, afin de limiter leur pouvoir. Toutefois, il n’existe pas de normes, de procédures ni d’outils clairs pour mettre en œuvre de telles mesures (voir section 4.4).

6.2 Centralisation des actifs hors chaîne

Ethereum héberge une quantité importante d’actifs du monde réel, lesquels sont détenus hors chaîne dans des comptes bancaires ou d’autres dépôts, puis échangés sur la chaîne via des jetons représentant une créance sur ces actifs hors chaîne. Par exemple, de nombreux grands stablecoins fonctionnent de cette manière.

Les institutions qui détiennent les dépôts hors chaîne peuvent exercer une influence sur l’écosystème Ethereum. Par exemple, dans un scénario extrême où il existe un fork conflictuel ou une mise à niveau du réseau, les gros dépositaires peuvent influencer la chaîne qui sera largement acceptée en choisissant de ne reconnaître les jetons que sur une seule des deux chaînes.

6.3 Attaque ou pression réglementaire

Les gouvernements et les régulateurs pourraient faire pression sur diverses entités qui contrôlent des composants essentiels de la pile Ethereum afin de censurer ou d’interférer d’une autre manière avec le protocole Ethereum. Les utilisateurs institutionnels d’Ethereum pourraient également être affectés par ces pressions, ce qui entraînerait d’autres conséquences pour leurs propres utilisateurs (par exemple, une banque qui ne peut plus proposer certains produits cryptographiques en raison d’interdictions réglementaires).

6.4 Capture organisationnelle de la gouvernance

La gouvernance open source et les processus de développement d’Ethereum sont portés par un ensemble diversifié et mondial d’équipes et d’entreprises qui maintiennent les logiciels clients principaux, l’infrastructure et les outils.

Diverses formes d’influence (acquisitions d’entreprises, dépendances au financement, emploi de contributeurs clés, conflits d’intérêts au sein d’organisations existantes) pourraient progressivement modifier la culture et les priorités de la gouvernance d’Ethereum. Cela pourrait mener à un alignement sur des intérêts commerciaux ou externes spécifiques, divergents de l’esprit communautaire et de la feuille de route établie, affaiblissant potentiellement la neutralité et la résilience d’Ethereum au fil du temps.