Présentation des défis de sécurité

L'une des caractéristiques déterminantes des chaînes de blocs est la nature atomique des transactions : une fois qu'une mise à jour est enregistrée dans la chaîne de blocs, il n'y a aucune possibilité d'intervention ou d'annulation. Cela offre de solides garanties de cohérence et de sécurité au niveau du protocole, mais expose les utilisateurs à un risque opérationnel accru : une simple erreur, une clé compromise ou une approbation précipitée peut entraîner une perte irréversible.

Par conséquent, une charge importante de la sécurité incombe à l'utilisateur. Pour utiliser Ethereum en toute sécurité, les individus et les organisations doivent détenir et gérer des clés en toute sécurité, interagir avec des applications onchain 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 tels que la compromission ou la perte de clés, des approbations précipitées ou non éclairées, ou la compromission du logiciel de portefeuille sur lequel les utilisateurs s'appuient 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 en toute sécurité des clés cryptographiques.

La plupart des portefeuilles logiciels largement utilisés reposent sur le fait que les utilisateurs stockent en toute sécurité des phrases de récupération représentant leur clé privée cryptographique sous-jacente, ce qui les amène souvent à utiliser des solutions de contournement non sécurisées comme le stockage des phrases de récupération en texte clair, sur des services cloud, ou en les écrivant sur papier.

Les portefeuilles matériels sont une alternative, qui permet aux utilisateurs de gérer une clé cryptographique stockée dans un appareil physique spécialisé. Cependant, les portefeuilles matériels ont leurs propres failles 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 appareils compromis sont vendus sur le marché.

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

Les utilisateurs d'entreprises et institutionnels sont confrontés à des défis supplémentaires dans la 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 être en mesure de les remplacer et d'en créer de nouvelles en raison des changements de personnel au fil du temps. Les exigences de conformité dans différents secteurs 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 d'entreprise se tournent vers des dépositaires tiers pour les actifs numériques, ce qui peut introduire une autre couche de risques de sécurité à prendre en compte.

1.2 Signature aveugle et incertitude des transactions

Les utilisateurs approuvent régulièrement des transactions « à l'aveugle » sans comprendre ce qu'ils font. Les portefeuilles présentent souvent des données hexadécimales brutes, une adresse de contrat tronquée ou d'autres informations qui ne sont pas suffisantes pour que l'utilisateur comprenne les conséquences d'une transaction donnée. Cela laisse les utilisateurs de toutes sortes vulnérables aux contrats intelligents malveillants, à l'hameçonnage, aux escroqueries, aux interfaces usurpées, aux compromissions front-end et aux erreurs d'utilisateur 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 peut accorder à un échange décentralisé comme Uniswap la permission de déplacer ses jetons afin de les échanger contre des 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'y a aucun moyen pour les utilisateurs de gérer ou d'examiner leurs approbations en cours depuis la plupart des portefeuilles.

Cela peut exposer les utilisateurs à des applications malveillantes ou à des frontends compromis, 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 était par la suite compromis alors que l'approbation reste en place, alors le contrat compromis pourrait vider les fonds de l'utilisateur.

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

1.4 Interfaces web compromises

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

Ces frontends peuvent être vulnérables aux attaques par des moyens familiers comme le détournement de DNS, l'injection de JavaScript malveillant, l'hébergement non sécurisé ou diverses dépendances tierces. Une UX 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 l'hameçonnage, l'exploitation, les escroqueries ou les attaques physiques. De nombreux modèles d'UX courants exposent les utilisateurs, par exemple, la réutilisation d'adresse, 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 certains cas d'utilisation. En plus de ces problèmes, elle 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 solides 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 façon dont les 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é de l'utilisateur à apprendre comment utiliser les portefeuilles en toute sécurité, et augmente les risques.

Par exemple, les utilisateurs ne peuvent pas se fier à des indices d'UX cohérents pour se protéger de l'hameçonnage et de l'usurpation, car ils diffèrent d'un portefeuille à l'autre. Les utilisateurs ne peuvent pas se forger des attentes 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 garanties tout au long du cycle de vie logiciel qui conduit au code déployé onchain. Les principales avancées comprennent :

• L'audit de sécurité est devenu une pratique courante, avec plusieurs sociétés de sécurité entrant dans l'écosystème et développant une expertise.
• Les outils, les tests et les systèmes d'analyse statique ont mûri et sont devenus une pratique courante.
• Les bibliothèques de composants communs pré-audités ont fourni aux développeurs des blocs de construction sécurisés par défaut.
• Des 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 d'importants programmes de primes aux bugs qui ont renforcé la couche applicative.

Cependant, il reste des faiblesses et des axes d'amélioration dans ce domaine.

2.1 Vulnérabilités des contrats

Malgré les avancées 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 à niveau du contrat. Certains contrats sont conçus pour être modifiables après le 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 à niveau pourraient entraîner de nouvelles vulnérabilités, ou la perte totale des fonds des utilisateurs dans le cas d'une mise à niveau malveillante.
• Réentrance, où le contrat A appelle un contrat externe B avant de mettre à jour son propre état interne, et le contrat B rappelle le contrat original A avant que le premier appel ne se termine.
• Utilisation non sécurisée de bibliothèques externes, où un contrat appelle une bibliothèque externe qui peut être non auditée, malveillante ou modifiable.
• 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.
• Défaillances du contrôle d'accès, où les permissions sont mal configurées ou définies de manière trop large, permettant aux attaquants de mener des actions malveillantes.
• Accès non autorisé, où 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 façon dont les messages inter-chaînes sont transmis ou validés.
• Délégation de compte externe (EOA) ou utilisation abusive de signature. Des applications malveillantes peuvent inciter les utilisateurs à signer la délégation complète de leur compte à une autre partie, permettant ainsi le 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 bugs introduits par la génération de code par l'IA ou les outils de refactorisation automatisés.

2.2 Expérience développeur, outils et langages de programmation

Les vulnérabilités se retrouvent dans le code déployé à la suite d'une erreur du développeur. L'amélioration des outils de développement a considérablement facilité le déploiement de contrats intelligents sûrs. Cependant, des problèmes subsistent.

• Manque de paramètres par défaut sécurisés dans les frameworks populaires. Certains outils privilégient la flexibilité ou la vitesse par rapport à la sécurité, en définissant des paramètres par défaut 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 créer les fonctionnalités requises à partir de zéro, ce qui augmente le risque de vulnérabilités. Il y a un manque de composants ou de 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 de domaine 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 de la spécification.
• 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 qu'il existe des solutions à 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'homme comme Solidity en bytecode utilisé par l'EVM elle-même) peuvent présenter des failles qui introduisent des erreurs dans les contrats intelligents avant qu'ils ne soient déployés. L'écosystème Ethereum dépend aujourd'hui principalement du compilateur solc, ce qui signifie qu'un bug pourrait avoir des effets à grande échelle.
• Diversité et profondeur des langages de programmation. Bien que Solidity dispose d'un écosystème d'outils très riche, certains développeurs recherchent des fonctionnalités de sécurité plus modernes présentes dans d'autres langages de programmation, comme la sécurité de la mémoire.

2.3 Évaluation des risques du code onchain

Les institutions et les entreprises disposent de processus, de normes et d'exigences existants pour évaluer la sécurité des technologies et des systèmes dont elles dépendent. Cependant, les cadres existants ne s'adaptent souvent pas parfaitement aux contrats intelligents, supposant généralement un code mutable, un contrôle centralisé des modifications et des lignes claires de responsabilité ou d'obligation légale. Les systèmes construits sur des contrats intelligents peuvent parfois remettre en cause ces hypothèses, ce qui rend 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 du portefeuille et de l'application (par ex., les points de terminaison RPC pour les portefeuilles) et pour le protocole Ethereum lui-même (par ex., de nombreux validateurs sont hébergés sur une infrastructure cloud). La compromission d'une clé privée, l'hameçonnage 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 de la chaîne de blocs sous-jacent reste sécurisé.

3.1 Chaînes de couche 2 (l2)

Les chaînes de couche 2 (l2) servent d'extensions pour Ethereum, offrant des environnements plus rapides et avec des frais réduits tout en conservant certaines des garanties de sécurité caractéristiques du réseau principal Ethereum (selon leur conception spécifique). Cependant, elles possèdent également leurs propres surfaces d'attaque distinctes, notamment :

• Complexité des actifs pontés à sauts multiples. Lorsque les actifs voyagent entre la couche 1 (l1) et plusieurs l2, ils sont exposés à de multiples ensembles de contrats qui doivent tous être sécurisés. Des incohérences comptables ou des pannes dans les chaînes l2 peuvent introduire des vulnérabilités susceptibles d'être exploitées par des attaquants.
• Les l2 de type rollup s'appuient sur des systèmes de preuve pour garantir l'exactitude des mises à jour d'état. Des bugs ou des erreurs de configuration dans ces systèmes peuvent bloquer ou empêcher la finalisation, ou permettre la finalisation de fausses mises à jour d'état entraînant la perte des fonds des utilisateurs.
• Les conseils de sécurité sont des groupes de détenteurs de clés qui servent de mécanisme de « secours » pour mettre à niveau les logiciels l2 ou répondre à certaines urgences. Les conseils de sécurité eux-mêmes présentent des risques, car la compromission ou la collusion entre les membres pourrait mettre en péril les fonds des utilisateurs ou geler les actifs.

Consultez L2BEAT (opens 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 de 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 crypto, ainsi que les services cloud traditionnels qui sont couramment utilisés pour héberger des nœuds (par ex., AWS, Cloudflare, Hetzner).

Si ces fournisseurs d'infrastructure se mettaient 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 leur application, jusqu'à ce qu'ils puissent migrer vers un nouveau RPC ou un autre fournisseur d'infrastructure. Certains de ces fournisseurs ont déjà suspendu ou fermé des comptes associés à l'activité de la chaîne de blocs, soulevant des inquiétudes 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 vulnérables à :

• Le détournement de DNS, où un attaquant insère une fausse interface malveillante.
• La saisie de domaine, où un gouvernement ou un bureau d'enregistrement peut saisir des domaines.
• L'hameçonnage via des domaines sosies, 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 extraites directement de services comme npm, crates.io ou GitHub. Si ces bibliothèques sont compromises, elles peuvent constituer un vecteur d'attaques telles que :

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

3.5 Services de diffusion d'interfaces et risques associés

De nombreuses applications Ethereum diffusent leurs interfaces via un réseau de diffusion de contenu (CDN) ou une plateforme d'hébergement cloud (par ex., Vercel, Netlify, Cloudflare). Si ces services sont compromis, ils peuvent constituer un vecteur d'attaques comme l'injection de JavaScript malveillant, où les attaquants diffusent une interface altérée aux utilisateurs.

3.6 Censure au niveau des fournisseurs d'accès à Internet

Les fournisseurs d'accès à Internet (FAI) 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 :

• Le blocage ou la limitation du trafic vers les ports Ethereum courants
• Le filtrage des requêtes DNS qui se résolvent vers des services liés à Ethereum
• Le géoblocage ou les bannissements d'IP contre les nœuds Ethereum connus
• L'inspection approfondie des paquets pour identifier et censurer le trafic lié au protocole Ethereum

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

Le protocole de consensus d'Ethereum s'est avéré robuste dans la pratique, sans aucune interruption depuis son premier lancement en 2015 et à travers plusieurs mises à niveau. Cependant, il reste des domaines d'amélioration à 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 fork et de finalité d'Ethereum sont résilientes, mais elles ne sont pas invulnérables. Dans certaines conditions extrêmes (comme un désaccord prolongé entre les validateurs, des bugs de clients ou des partitions du réseau), le consensus pourrait se bloquer ou diverger temporairement. Dans des conditions extrêmes, cela pourrait entraîner des pénalités en cascade pour les validateurs par le biais de fuites d'inactivité ou de réductions, ce qui pourrait en outre conduire à une fuite des capitaux des validateurs.

4.2 Diversité des clients

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

4.3 Centralisation du staking et domination des pools

Une part importante 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 :

• La capture ou l'influence de la gouvernance. Si des entités contrôlant de grandes quantités de mises (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 qui sont proposés et attestés, censurant potentiellement les utilisateurs ou influençant les mises à niveau du protocole.
• L'homogénéité dans le choix des clients et la configuration de l'infrastructure, ce qui peut augmenter les risques de défaillances corrélées.

4.4 Pénalité sociale non définie et lacunes de coordination

Dans certains modes de défaillance extrêmes, Ethereum s'appuierait sur la « pénalité sociale » pour sanctionner les validateurs qui ont agi de manière malveillante pour attaquer le réseau (voir section 6.1). Cependant, l'infrastructure, les normes et les processus attendus pour ce type de pénalité sont sous-développés. Il n'existe aucun mécanisme établi que la communauté utiliserait pour s'engager dans ce processus.

4.5 Vecteurs d'attaque économiques et liés à la théorie des jeux

De nombreux vecteurs d'attaque économiques potentiels restent sous-étudiés, notamment :

• Les attaques de type griefing ou le griefing par réduction. Les validateurs peuvent encourir des coûts ou des pénalités de réduction non pas en raison de leurs propres fautes, mais en raison d'un comportement hostile destiné uniquement à nuire à autrui à un coût net pour l'attaquant.
• Les sorties stratégiques ou l'inactivité chronométrée. Les validateurs pourraient intentionnellement se mettre hors ligne ou sortir à des moments critiques pour maximiser leurs profits ou perturber le consensus avec des pénalités minimales.
• La collusion entre les validateurs ou les relais. Un comportement coordonné entre les validateurs ou entre les relais et les validateurs pourrait réduire la décentralisation ou extraire de la MEV.
• L'exploitation des incitations dans les cas limites de la MEV, de la séparation proposant-constructeur (PBS) ou de la conception du staking liquide. Les acteurs peuvent manipuler des conditions rares du protocole pour obtenir des récompenses démesurées.

4.6 Risque quantique

La cryptographie de base d'Ethereum (par ex., les signatures à courbe elliptique comme secp256k1) pourrait un jour être brisée par des ordinateurs quantiques. Bien qu'il ne s'agisse pas d'un risque imminent, une menace crédible pourrait instantanément rendre vulnérables les portefeuilles, les contrats et les clés de staking existants. Ce défi futur affaiblit les garanties à long terme d'Ethereum envers les utilisateurs.

Des voies de migration vers une cryptographie résistante aux quantiques (par ex., via des schémas de signature post-quantique) doivent être conçues, testées et éventuellement intégrées au protocole des années avant qu'elles ne soient nécessaires. 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 de chaîne de blocs idéalisé comportera des risques, des attaques et des vulnérabilités. Lorsque les choses tournent mal, il doit y avoir des systèmes efficaces pour atténuer, détecter et réagir. Les défis ici incluent :

• Contacter l'équipe concernée. Il peut être difficile d'entrer en contact avec 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 aux organisations liées. Lorsque le problème implique une plateforme (comme un réseau social ou une plateforme d'échange centralisée), il peut être difficile pour les intervenants de faire remonter le problème s'ils n'ont pas de contact préexistant.
• Coordination de la réponse. Il est souvent difficile de savoir combien d'équipes de réponse aux incidents aident l'application concernée, ce qui entraîne des problèmes de communication ou des efforts inutiles alors qu'un effort de groupe aurait pu être plus efficace.
• Manque de capacités de surveillance. Il peut être difficile de surveiller les problèmes onchain et hors chaîne, ce qui fournirait une alerte précoce et garantirait une réponse rapide aux menaces.
• Accès à l'assurance. L'assurance est un outil essentiel pour atténuer les pertes dans la plupart des systèmes traditionnels qui traitent de l'argent, des systèmes financiers, de l'identité et d'autres informations précieuses. Cependant, il existe aujourd'hui peu d'options d'assurance proposées par les services financiers traditionnels pour l'écosystème crypto.

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

6.1 Centralisation des mises

La centralisation de grandes quantités de mises peut poser des risques pour Ethereum dans son ensemble si les entités contrôlant ces mises décident de s'entendre.
Cette centralisation économique crée le potentiel d'une capture de la gouvernance sociale. Si un petit groupe de validateurs contrôle une supermajorité des mises, ils pourraient :

• Se coordonner sur des forks ou y résister.
• Censurer certaines transactions ou contrats.
• Saper le consensus de la communauté en menaçant de sortie ou d'opposition.

Si ce scénario extrême venait à se produire, la communauté Ethereum a suggéré que la « pénalité sociale » pourrait être la réponse. La pénalité sociale est l'utilisation du consensus social hors chaîne pour décider d'appliquer une réduction aux validateurs qui se comportent mal, afin de limiter leur pouvoir. Mais il n'existe aucune norme, procédure ou outil clair pour promulguer de telles mesures (voir section 4.4).

6.2 Centralisation des actifs hors chaîne

Ethereum héberge des quantités importantes d'actifs du monde réel (RWA), où les actifs sont détenus hors chaîne dans des comptes bancaires ou d'autres dépôts, qui sont ensuite échangés onchain via des jetons qui représentent une réclamation sur les 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 avoir une influence sur l'écosystème Ethereum. Par exemple, lors d'un scénario extrême où il y a un fork litigieux ou une mise à niveau du réseau, les grands déposants peuvent influencer quelle chaîne devient largement acceptée en choisissant de ne reconnaître les jetons que sur une chaîne ou sur l'autre.

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 importants de la pile Ethereum pour censurer ou interférer d'une autre manière avec le protocole Ethereum. Les utilisateurs institutionnels d'Ethereum pourraient également être touchés par ces pressions, ce qui aurait d'autres conséquences pour leurs utilisateurs (par ex., une banque qui ne peut plus proposer certains produits crypto en raison d'interdictions réglementaires).

6.4 Capture organisationnelle de la gouvernance

Les processus de gouvernance et de développement open source d'Ethereum sont dirigés par un ensemble diversifié et mondial d'équipes et d'entreprises qui maintiennent les logiciels clients de base, l'infrastructure et les outils.

Diverses formes d'influence (acquisitions d'entreprises, dépendances de 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 conduire à un alignement sur des intérêts commerciaux ou externes spécifiques qui divergent de l'éthique communautaire et de la feuille de route établie, affaiblissant potentiellement la neutralité et la résilience d'Ethereum au fil du temps.