Attaque et défense de la preuve d'enjeu d'Ethereum

Les voleurs et les saboteurs cherchent constamment des opportunités pour attaquer les logiciels clients d'Ethereum. Cette page décrit les vecteurs d'attaque connus sur la couche de consensus d'Ethereum et explique comment s'en défendre. Les informations de cette page sont adaptées d'une version plus longue (opens in a new tab).

Prérequis

Une connaissance de base de la preuve d'enjeu (PoS) est requise. De plus, il sera utile d'avoir une compréhension de base de la couche d'incitation d'Ethereum et de l'algorithme de choix de fourche, LMD-GHOST.

Que veulent les attaquants ?

Une idée fausse courante est qu'un attaquant qui réussit peut générer de nouveaux ethers ou vider l'ether de comptes arbitraires. Aucune de ces actions n'est possible car toutes les transactions sont exécutées par tous les clients d'exécution sur le réseau. Elles doivent satisfaire aux conditions de base de validité (par exemple, les transactions sont signées par la clé privée de l'expéditeur, l'expéditeur a un solde suffisant, etc.) sinon elles sont simplement annulées. Il y a trois types de résultats qu'un attaquant pourrait cibler de manière réaliste : les réorganisations, la double finalité ou le retard de finalité.

Une « réorganisation » est un remaniement des blocs dans un nouvel ordre, peut-être avec quelques ajouts ou soustractions de blocs dans la chaîne canonique. Une réorganisation malveillante pourrait garantir que des blocs spécifiques soient inclus ou exclus, permettant une double dépense ou l'extraction de valeur par des transactions de front-running et de back-running (MEV). Les réorganisations pourraient également être utilisées pour empêcher certaines transactions d'être incluses dans la chaîne canonique - une forme de censure. La forme la plus extrême de réorganisation est la « réversion de finalité » qui supprime ou remplace des blocs qui ont été précédemment finalisés. Cela n'est possible que si plus d'un tiers de l'ether total mis en jeu est détruit par l'attaquant - cette garantie est connue sous le nom de « finalité économique » - nous y reviendrons plus tard.

La double finalité est la condition improbable mais grave où deux forks sont capables de se finaliser simultanément, créant un schisme permanent dans la chaîne. C'est théoriquement possible pour un attaquant prêt à risquer 34 % de l'ether total mis en jeu. La communauté serait obligée de se coordonner hors chaîne et de parvenir à un accord sur la chaîne à suivre, ce qui nécessiterait de la force au niveau de la couche sociale.

Une attaque par retard de finalité empêche le réseau d'atteindre les conditions nécessaires à la finalisation de sections de la chaîne. Sans finalité, il est difficile de faire confiance aux applications financières construites sur Ethereum. Le but d'une attaque par retard de finalité est probablement simplement de perturber Ethereum plutôt que d'en tirer un profit direct, à moins que l'attaquant n'ait une ou plusieurs positions courtes stratégiques.

Une attaque sur la couche sociale pourrait viser à saper la confiance du public dans Ethereum, à dévaluer l'ether, à réduire l'adoption ou à affaiblir la communauté Ethereum pour rendre la coordination hors bande plus difficile.

Ayant établi pourquoi un adversaire pourrait attaquer Ethereum, les sections suivantes examinent comment il pourrait s'y prendre.

Méthodes d'attaque

Attaques de la couche 0

Tout d'abord, les individus qui ne participent pas activement à Ethereum (en exécutant un logiciel client) peuvent attaquer en ciblant la couche sociale (Couche 0). La couche 0 est la fondation sur laquelle Ethereum est construit, et en tant que telle, elle représente une surface potentielle pour des attaques dont les conséquences se répercutent sur le reste de la pile. Quelques exemples pourraient inclure :

Une campagne de désinformation pourrait éroder la confiance que la communauté a dans la feuille de route d'Ethereum, les équipes de développeurs, les applications, etc. Cela pourrait alors diminuer le nombre d'individus prêts à participer à la sécurisation du réseau, dégradant à la fois la décentralisation et la sécurité crypto-économique.
Des attaques ciblées et/ou des intimidations dirigées contre la communauté des développeurs. Cela pourrait conduire à la sortie volontaire de développeurs et ralentir les progrès d'Ethereum.
Une réglementation excessive pourrait également être considérée comme une attaque sur la couche 0, car elle pourrait rapidement décourager la participation et l'adoption.
L'infiltration d'acteurs compétents mais malveillants dans la communauté des développeurs dont le but est de ralentir les progrès en s'attardant sur des détails futiles (bike-shedding), en retardant les décisions clés, en créant du spam, etc.
Des pots-de-vin versés à des acteurs clés de l'écosystème Ethereum pour influencer la prise de décision.

Ce qui rend ces attaques particulièrement dangereuses, c'est que dans de nombreux cas, très peu de capital ou de savoir-faire technique est requis. Une attaque de la couche 0 pourrait être un multiplicateur d'une attaque crypto-économique. Par exemple, si la censure ou la réversion de finalité étaient réalisées par un staker majoritaire malveillant, saper la couche sociale pourrait rendre plus difficile la coordination d'une réponse communautaire hors bande.

Se défendre contre les attaques de la couche 0 n'est probablement pas simple, mais quelques principes de base peuvent être établis. L'un d'eux consiste à maintenir un rapport signal/bruit globalement élevé pour les informations publiques sur Ethereum, créées et propagées par des membres honnêtes de la communauté via des blogs, des serveurs Discord, des spécifications annotées, des livres, des podcasts et YouTube. Ici, sur ethereum.org, nous nous efforçons de maintenir des informations précises et de les traduire dans autant de langues que possible. Inonder un espace d'informations et de mèmes de haute qualité est une défense efficace contre la désinformation.

Une autre fortification importante contre les attaques de la couche sociale est une déclaration de mission claire et un protocole de gouvernance. Ethereum s'est positionné comme le champion de la décentralisation et de la sécurité parmi les couches 1 (l1) de contrats intelligents, tout en valorisant fortement la scalabilité et la durabilité. Quels que soient les désaccords qui surviennent dans la communauté Ethereum, ces principes fondamentaux sont très peu compromis. Évaluer un récit par rapport à ces principes fondamentaux, et les examiner à travers des cycles successifs d'examen dans le processus EIP (Proposition d'amélioration d'Ethereum), pourrait aider la communauté à distinguer les bons des mauvais acteurs et limiter la portée des acteurs malveillants pour influencer la direction future d'Ethereum.

Enfin, il est essentiel que la communauté Ethereum reste ouverte et accueillante pour tous les participants. Une communauté avec des gardiens et de l'exclusivité est particulièrement vulnérable aux attaques sociales car il est facile de construire des récits du type « nous contre eux ». Le tribalisme et le maximalisme toxique nuisent à la communauté et érodent la sécurité de la couche 0. Les Ethereans ayant un intérêt direct dans la sécurité du réseau devraient considérer leur conduite en ligne et dans le monde réel comme une contribution directe à la sécurité de la couche 0 d'Ethereum.

Attaquer le protocole

N'importe qui peut exécuter le logiciel client d'Ethereum. Pour ajouter un validateur à un client, un utilisateur doit mettre en jeu 32 ethers dans le contrat de dépôt. Un validateur permet à un utilisateur de participer activement à la sécurité du réseau d'Ethereum en proposant et en attestant de nouveaux blocs. Le validateur a maintenant une voix qu'il peut utiliser pour influencer le contenu futur de la chaîne de blocs - il peut le faire honnêtement et faire croître sa réserve d'ether via des récompenses ou il peut essayer de manipuler le processus à son propre avantage, en risquant sa mise. Une façon de monter une attaque est d'accumuler une plus grande proportion de la mise totale et de l'utiliser ensuite pour surpasser les votes des validateurs honnêtes. Plus la proportion de la mise contrôlée par l'attaquant est grande, plus son pouvoir de vote est important, en particulier à certaines étapes économiques que nous explorerons plus tard. Cependant, la plupart des attaquants ne pourront pas accumuler suffisamment d'ether pour attaquer de cette manière, ils doivent donc utiliser des techniques subtiles pour manipuler la majorité honnête afin qu'elle agisse d'une certaine manière.

Fondamentalement, toutes les attaques à petite mise sont des variations subtiles de deux types de mauvais comportement des validateurs : la sous-activité (ne pas attester/proposer ou le faire en retard) ou la suractivité (proposer/attester trop de fois dans un créneau). Dans leurs formes les plus classiques, ces actions sont facilement gérées par l'algorithme de choix de fourche et la couche d'incitation, mais il existe des moyens astucieux de contourner le système à l'avantage d'un attaquant.

Attaques utilisant de petites quantités d'ETH

réorganisations

Plusieurs articles ont expliqué des attaques sur Ethereum qui parviennent à des réorganisations ou à un retard de finalité avec seulement une petite proportion de l'ether total mis en jeu. Ces attaques reposent généralement sur le fait que l'attaquant retient certaines informations aux autres validateurs, puis les publie de manière nuancée et/ou à un moment opportun. Elles visent généralement à déplacer un ou plusieurs blocs honnêtes de la chaîne canonique. Neuder et al 2020 (opens in a new tab) ont montré comment un validateur attaquant peut créer et attester un bloc (B) pour un créneau particulier n+1 mais s'abstenir de le propager aux autres nœuds du réseau. Au lieu de cela, ils conservent ce bloc attesté jusqu'au créneau suivant n+2. Un validateur honnête propose un bloc (C) pour le créneau n+2. Presque simultanément, l'attaquant peut publier son bloc retenu (B) et ses attestations retenues pour celui-ci, et également attester que B est la tête de la chaîne avec ses votes pour le créneau n+2, niant ainsi l'existence du bloc honnête C. Lorsque le bloc honnête D est publié, l'algorithme de choix de fourche voit que D construit sur B est plus lourd que D construit sur C. L'attaquant a donc réussi à retirer le bloc honnête C du créneau n+2 de la chaîne canonique en utilisant une réorganisation ex ante d'un bloc. Un attaquant avec 34 % (opens in a new tab) de la mise a de très bonnes chances de réussir cette attaque, comme expliqué dans cette note (opens in a new tab). En théorie, cependant, cette attaque pourrait être tentée avec des mises plus petites. Neuder et al 2020 (opens in a new tab) ont décrit cette attaque fonctionnant avec une mise de 30 %, mais il a été démontré plus tard qu'elle était viable avec 2 % de la mise totale (opens in a new tab) et ensuite pour un seul validateur (opens in a new tab) en utilisant des techniques d'équilibrage que nous examinerons dans la section suivante.

Un diagramme conceptuel de l'attaque par réorganisation d'un bloc décrite ci-dessus (adapté de https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair (opens in a new tab))

Une attaque plus sophistiquée peut diviser l'ensemble des validateurs honnêtes en groupes distincts qui ont des vues différentes de la tête de la chaîne. C'est ce qu'on appelle une attaque par équilibrage. L'attaquant attend sa chance de proposer un bloc, et quand elle arrive, il fait preuve d'équivoque et en propose deux. Il envoie un bloc à la moitié de l'ensemble des validateurs honnêtes et l'autre bloc à l'autre moitié. L'équivoque serait détectée par l'algorithme de choix de fourche et le proposeur de bloc subirait une réduction et serait éjecté du réseau, mais les deux blocs existeraient toujours et auraient environ la moitié de l'ensemble des validateurs attestant pour chaque fork. Pendant ce temps, les validateurs malveillants restants retiennent leurs attestations. Ensuite, en publiant sélectivement les attestations favorisant l'un ou l'autre fork à juste assez de validateurs au moment où l'algorithme de choix de fourche s'exécute, ils font pencher le poids accumulé des attestations en faveur de l'un ou l'autre fork. Cela peut continuer indéfiniment, les validateurs attaquants maintenant une répartition égale des validateurs sur les deux forks. Puisqu'aucun des forks ne peut attirer une supermajorité des 2/3, le réseau ne se finaliserait pas.

Les attaques par rebond sont similaires. Les votes sont à nouveau retenus par les validateurs attaquants. Au lieu de publier les votes pour maintenir une répartition égale entre deux forks, ils utilisent leurs votes à des moments opportuns pour justifier des points de contrôle qui alternent entre le fork A et le fork B. Ce basculement de justification entre deux forks empêche qu'il y ait des paires de points de contrôle source et cible justifiés qui peuvent être finalisés sur l'une ou l'autre chaîne, arrêtant la finalité.

The game of reorgs in proof of stake Ethereum

Caspar Schwarz-Schilling presents research on block reorganization attacks in proof of stake Ethereum, covering attack vectors, defense mechanisms, and the protocol-level mitigations in place.

Regarder avec la transcription

Les attaques par rebond et par équilibrage reposent toutes deux sur le fait que l'attaquant a un contrôle très fin sur la synchronisation des messages à travers le réseau, ce qui est peu probable. Néanmoins, des défenses sont intégrées au protocole sous la forme d'une pondération supplémentaire accordée aux messages rapides par rapport aux messages lents. C'est ce qu'on appelle le renforcement du poids du proposant (opens in a new tab). Pour se défendre contre les attaques par rebond, l'algorithme de choix de fourche a été mis à jour afin que le dernier point de contrôle justifié ne puisse basculer vers celui d'une chaîne alternative que pendant le premier tiers des créneaux de chaque époque (opens in a new tab). Cette condition empêche l'attaquant d'économiser des votes pour les déployer plus tard - l'algorithme de choix de fourche reste simplement fidèle au point de contrôle qu'il a choisi dans le premier tiers de l'époque, période pendant laquelle la plupart des validateurs honnêtes auraient voté.

Combinées, ces mesures créent un scénario dans lequel un proposeur de bloc honnête émet son bloc très rapidement après le début du créneau, puis il y a une période d'environ 1/3 de créneau (4 secondes) où ce nouveau bloc pourrait amener l'algorithme de choix de fourche à basculer vers une autre chaîne. Après ce même délai, les attestations qui arrivent de validateurs lents sont sous-pondérées par rapport à celles qui sont arrivées plus tôt. Cela favorise fortement les proposants et les validateurs rapides dans la détermination de la tête de la chaîne et réduit considérablement la probabilité d'une attaque par équilibrage ou par rebond réussie.

Il convient de noter que le renforcement du proposant seul ne défend que contre les « réorganisations bon marché », c'est-à-dire celles tentées par un attaquant avec une petite mise. En fait, le renforcement du proposant lui-même peut être manipulé par des stakers plus importants. Les auteurs de cet article (opens in a new tab) décrivent comment un attaquant avec 7 % de la mise peut déployer ses votes de manière stratégique pour tromper les validateurs honnêtes afin qu'ils construisent sur son fork, réorganisant ainsi un bloc honnête. Cette attaque a été conçue en supposant des conditions de latence idéales qui sont très improbables. Les chances sont encore très minces pour l'attaquant, et la mise plus importante signifie également plus de capital à risque et une dissuasion économique plus forte.

Une attaque par équilibrage ciblant spécifiquement la règle LMD (opens in a new tab) a également été proposée, qui a été suggérée comme étant viable malgré le renforcement du proposant. Un attaquant met en place deux chaînes concurrentes en faisant preuve d'équivoque dans sa proposition de bloc et en propageant chaque bloc à environ la moitié du réseau chacun, établissant un équilibre approximatif entre les forks. Ensuite, les validateurs complices font preuve d'équivoque dans leurs votes, en les synchronisant de sorte que la moitié du réseau reçoive leurs votes pour le Fork A en premier et l'autre moitié reçoive leurs votes pour le Fork B en premier. Puisque la règle LMD rejette la deuxième attestation et ne conserve que la première pour chaque validateur, la moitié du réseau voit des votes pour A et aucun pour B, l'autre moitié voit des votes pour B et aucun pour A. Les auteurs décrivent la règle LMD comme donnant à l'adversaire un « pouvoir remarquable » pour monter une attaque par équilibrage.

Ce vecteur d'attaque LMD a été fermé en mettant à jour l'algorithme de choix de fourche (opens in a new tab) afin qu'il rejette complètement les validateurs équivoques de la considération du choix de fourche. Les validateurs équivoques voient également leur influence future réduite par l'algorithme de choix de fourche. Cela empêche l'attaque par équilibrage décrite ci-dessus tout en maintenant la résilience contre les attaques par avalanche.

Une autre classe d'attaque, appelée attaques par avalanche (opens in a new tab), a été décrite dans un article de mars 2022 (opens in a new tab). Pour monter une attaque par avalanche, l'attaquant doit contrôler plusieurs proposeurs de blocs consécutifs. Dans chacun des créneaux de proposition de bloc, l'attaquant retient son bloc, les collectant jusqu'à ce que la chaîne honnête atteigne un poids de sous-arbre égal avec les blocs retenus. Ensuite, les blocs retenus sont publiés de manière à ce qu'ils fassent preuve d'une équivoque maximale. Les auteurs suggèrent que le renforcement du proposant - la principale défense contre les attaques par équilibrage et par rebond - ne protège pas contre certaines variantes d'attaque par avalanche. Cependant, les auteurs n'ont également démontré l'attaque que sur une version hautement idéalisée de l'algorithme de choix de fourche d'Ethereum (ils ont utilisé GHOST sans LMD).

L'attaque par avalanche est atténuée par la partie LMD de l'algorithme de choix de fourche LMD-GHOST. LMD signifie « latest-message-driven » (piloté par le dernier message) et fait référence à une table conservée par chaque validateur contenant le dernier message reçu des autres validateurs. Ce champ n'est mis à jour que si le nouveau message provient d'un créneau ultérieur à celui déjà présent dans la table pour un validateur particulier. En pratique, cela signifie que dans chaque créneau, le premier message reçu est celui qui est accepté et tout message supplémentaire est une équivoque à ignorer. Autrement dit, les clients de consensus ne comptent pas les équivoques - ils utilisent le premier message arrivant de chaque validateur et les équivoques sont simplement rejetées, empêchant les attaques par avalanche.

Il existe plusieurs autres mises à niveau futures potentielles de la règle de choix de fourche qui pourraient s'ajouter à la sécurité fournie par le renforcement du proposant. L'une d'elles est la fusion de vues (view-merge) (opens in a new tab), où les attestateurs gèlent leur vue du choix de fourche n secondes avant le début d'un créneau et le proposant aide ensuite à synchroniser la vue de la chaîne à travers le réseau. Une autre mise à niveau potentielle est la finalité à créneau unique (single-slot finality) (opens in a new tab), qui protège contre les attaques basées sur la synchronisation des messages en finalisant la chaîne après un seul créneau.

Retard de finalité

Le même article (opens in a new tab) qui a décrit pour la première fois l'attaque par réorganisation d'un seul bloc à faible coût a également décrit une attaque par retard de finalité (également appelée « échec de vivacité ») qui repose sur le fait que l'attaquant est le proposeur de bloc pour un bloc de limite d'époque. Ceci est critique car ces blocs de limite d'époque deviennent les points de contrôle que Casper FFG utilise pour finaliser des portions de la chaîne. L'attaquant retient simplement son bloc jusqu'à ce que suffisamment de validateurs honnêtes utilisent leurs votes FFG en faveur du bloc de limite d'époque précédent comme cible de finalisation actuelle. Ensuite, ils publient leur bloc retenu. Ils attestent de leur bloc et les validateurs honnêtes restants font de même, créant des forks avec des points de contrôle cibles différents. S'ils l'ont bien synchronisé, ils empêcheront la finalité car il n'y aura pas de supermajorité des 2/3 attestant pour l'un ou l'autre fork. Plus la mise est petite, plus la synchronisation doit être précise car l'attaquant contrôle moins d'attestations directement, et plus les chances que l'attaquant contrôle le validateur proposant un bloc de limite d'époque donné sont faibles.

Attaques à longue portée

Il existe également une classe d'attaque spécifique aux chaînes de blocs à preuve d'enjeu qui implique qu'un validateur ayant participé au bloc genèse maintienne un fork séparé de la chaîne de blocs aux côtés de la chaîne honnête, convainquant finalement l'ensemble des validateurs honnêtes de basculer vers celui-ci à un moment opportun bien plus tard. Ce type d'attaque n'est pas possible sur Ethereum en raison du gadget de finalité qui garantit que tous les validateurs s'accordent sur l'état de la chaîne honnête à des intervalles réguliers (« points de contrôle »). Ce mécanisme simple neutralise les attaquants à longue portée car les clients Ethereum ne réorganiseront tout simplement pas les blocs finalisés. Les nouveaux nœuds rejoignant le réseau le font en trouvant un hash d'état récent de confiance (un point de contrôle de « subjectivité faible (opens in a new tab) ») et en l'utilisant comme un pseudo-bloc genèse sur lequel construire. Cela crée une « passerelle de confiance » pour un nouveau nœud entrant dans le réseau avant qu'il ne puisse commencer à vérifier les informations par lui-même.

Déni de service

Le mécanisme PoS d'Ethereum choisit un seul validateur parmi l'ensemble total des validateurs pour être un proposeur de bloc dans chaque créneau. Cela peut être calculé à l'aide d'une fonction publiquement connue et il est possible pour un adversaire d'identifier le prochain proposeur de bloc légèrement avant sa proposition de bloc. Ensuite, l'attaquant peut spammer le proposeur de bloc pour l'empêcher d'échanger des informations avec ses pairs. Pour le reste du réseau, il semblerait que le proposeur de bloc soit hors ligne et le créneau resterait simplement vide. Cela pourrait être une forme de censure contre des validateurs spécifiques, les empêchant d'ajouter des informations à la chaîne de blocs. La mise en œuvre d'élections de leader secret unique (SSLE) ou d'élections de leader secret non unique atténuera les risques de DoS car seul le proposeur de bloc sait qu'il a été sélectionné et la sélection n'est pas connaissable à l'avance. Ce n'est pas encore implémenté, mais c'est un domaine actif de recherche et développement (opens in a new tab).

Tout cela indique qu'il est très difficile d'attaquer avec succès Ethereum avec une petite mise. Les attaques viables qui ont été décrites ici nécessitent un algorithme de choix de fourche idéalisé, des conditions de réseau improbables, ou les vecteurs d'attaque ont déjà été fermés avec des correctifs relativement mineurs au logiciel client. Cela n'exclut bien sûr pas la possibilité que des vulnérabilités zero-day existent dans la nature, mais cela démontre le niveau extrêmement élevé d'aptitude technique, de connaissance de la couche de consensus et de chance requis pour qu'un attaquant avec une mise minoritaire soit efficace. Du point de vue d'un attaquant, son meilleur pari pourrait être d'accumuler autant d'ether que possible et de revenir armé d'une plus grande proportion de la mise totale.

Attaquants utilisant >= 33 % de la mise totale

Toutes les attaques mentionnées précédemment dans cet article ont plus de chances de réussir lorsque l'attaquant a plus d'ether mis en jeu pour voter, et plus de validateurs qui pourraient être choisis pour proposer des blocs dans chaque créneau. Un validateur malveillant pourrait donc viser à contrôler autant d'ether mis en jeu que possible.

33 % de l'ether mis en jeu est une référence pour un attaquant car avec une quantité supérieure à ce montant, il a la capacité d'empêcher la chaîne de se finaliser sans avoir à contrôler finement les actions des autres validateurs. Ils peuvent simplement tous disparaître ensemble. Si 1/3 ou plus de l'ether mis en jeu atteste de manière malveillante ou n'atteste pas, alors une supermajorité des 2/3 ne peut pas exister et la chaîne ne peut pas se finaliser. La défense contre cela est la fuite d'inactivité. La fuite d'inactivité identifie les validateurs qui n'attestent pas ou qui attestent contrairement à la majorité. L'ether mis en jeu possédé par ces validateurs n'attestant pas est progressivement saigné jusqu'à ce qu'ils représentent collectivement moins d'un tiers du total afin que la chaîne puisse à nouveau se finaliser.

Le but de la fuite d'inactivité est de faire en sorte que la chaîne se finalise à nouveau. Cependant, l'attaquant perd également une partie de son ether mis en jeu. Une inactivité persistante parmi les validateurs représentant 33 % de l'ether total mis en jeu est très coûteuse même si les validateurs ne subissent pas de réduction.

En supposant que le réseau Ethereum est asynchrone (c'est-à-dire qu'il y a des délais entre l'envoi et la réception des messages), un attaquant contrôlant 34 % de la mise totale pourrait provoquer une double finalité. C'est parce que l'attaquant peut faire preuve d'équivoque lorsqu'il est choisi pour être un producteur de bloc, puis voter double avec tous ses validateurs. Cela crée une situation où un fork de la chaîne de blocs existe, chacun avec 34 % de l'ether mis en jeu votant pour lui. Chaque fork ne nécessite que 50 % des validateurs restants pour voter en sa faveur pour que les deux forks soient soutenus par une supermajorité, auquel cas les deux chaînes peuvent se finaliser (car 34 % des validateurs attaquants + la moitié des 66 % restants = 67 % sur chaque fork). Les blocs concurrents devraient chacun être reçus par environ 50 % des validateurs honnêtes, cette attaque n'est donc viable que lorsque l'attaquant a un certain degré de contrôle sur la synchronisation des messages se propageant sur le réseau afin de pouvoir pousser la moitié des validateurs honnêtes sur chaque chaîne. L'attaquant détruirait nécessairement toute sa mise (34 % d'environ 10 millions d'ethers avec l'ensemble de validateurs d'aujourd'hui) pour atteindre cette double finalité car 34 % de ses validateurs voteraient double simultanément - une infraction passible de réduction avec la pénalité de corrélation maximale. La défense contre cette attaque est le coût très élevé de la destruction de 34 % de l'ether total mis en jeu. Se remettre de cette attaque nécessiterait que la communauté Ethereum se coordonne « hors bande » et accepte de suivre l'un ou l'autre des forks et d'ignorer l'autre.

Attaquants utilisant ~50 % de la mise totale

À 50 % de l'ether mis en jeu, un groupe malicieux de validateurs pourrait théoriquement diviser la chaîne en deux forks de taille égale, puis utiliser simplement l'intégralité de sa mise de 50 % pour voter contrairement à l'ensemble des validateurs honnêtes, maintenant ainsi les deux forks et empêchant la finalité. La fuite d'inactivité sur les deux forks conduirait finalement les deux chaînes à se finaliser. À ce stade, la seule option est de se rabattre sur une récupération sociale.

Il est très peu probable qu'un groupe de validateurs adverses puisse contrôler de manière cohérente précisément 50 % de la mise totale étant donné un certain degré de fluctuation du nombre de validateurs honnêtes, de la latence du réseau, etc. - le coût énorme du montage d'une telle attaque combiné à la faible probabilité de succès semble être une forte dissuasion pour un attaquant rationnel, en particulier lorsqu'un petit investissement supplémentaire pour obtenir plus de 50 % débloque beaucoup plus de pouvoir.

À >50 % de la mise totale, l'attaquant pourrait dominer l'algorithme de choix de fourche. Dans ce cas, l'attaquant serait en mesure d'attester avec le vote majoritaire, lui donnant un contrôle suffisant pour effectuer de courtes réorganisations sans avoir besoin de tromper les clients honnêtes. Les validateurs honnêtes suivraient le mouvement car leur algorithme de choix de fourche verrait également la chaîne favorisée par l'attaquant comme la plus lourde, de sorte que la chaîne pourrait se finaliser. Cela permet à l'attaquant de censurer certaines transactions, d'effectuer des réorganisations à courte portée et d'extraire un maximum de MEV en réorganisant les blocs en sa faveur. La défense contre cela est le coût énorme d'une mise majoritaire (actuellement un peu moins de 19 milliards de dollars américains) qui est mis en péril par un attaquant car la couche sociale est susceptible d'intervenir et d'adopter un fork minoritaire honnête, dévaluant considérablement la mise de l'attaquant.

Attaquants utilisant >=66 % de la mise totale

Un attaquant avec 66 % ou plus de l'ether total mis en jeu peut finaliser sa chaîne préférée sans avoir à contraindre aucun validateur honnête. L'attaquant peut simplement voter pour son fork préféré puis le finaliser, simplement parce qu'il peut voter avec une supermajorité malhonnête. En tant que staker supermajoritaire, l'attaquant contrôlerait toujours le contenu des blocs finalisés, avec le pouvoir de dépenser, de rembobiner et de dépenser à nouveau, de censurer certaines transactions et de réorganiser la chaîne à volonté. En achetant de l'ether supplémentaire pour contrôler 66 % plutôt que 51 %, l'attaquant achète effectivement la capacité de faire des réorganisations ex post et des réversions de finalité (c'est-à-dire changer le passé ainsi que contrôler l'avenir). Les seules véritables défenses ici sont le coût énorme de 66 % de l'ether total mis en jeu, et l'option de se rabattre sur la couche sociale pour coordonner l'adoption d'un fork alternatif. Nous pouvons explorer cela plus en détail dans la section suivante.

Les personnes : la dernière ligne de défense

Si les validateurs malhonnêtes parviennent à finaliser leur version préférée de la chaîne, la communauté Ethereum est mise dans une situation difficile. La chaîne canonique inclut une section malhonnête intégrée dans son histoire, tandis que les validateurs honnêtes peuvent finir par être punis pour avoir attesté d'une chaîne alternative (honnête). Notez qu'une chaîne finalisée mais incorrecte pourrait également provenir d'un bug dans un client majoritaire. En fin de compte, le recours ultime est de s'appuyer sur la couche sociale - la Couche 0 - pour résoudre la situation.

L'une des forces du consensus PoS d'Ethereum est qu'il existe une gamme de stratégies défensives (opens in a new tab) que la communauté peut employer face à une attaque. Une réponse minimale pourrait être de forcer la sortie des validateurs des attaquants du réseau sans aucune pénalité supplémentaire. Pour réintégrer le réseau, l'attaquant devrait rejoindre une file d'attente d'activation qui garantit que l'ensemble des validateurs croît progressivement. Par exemple, ajouter suffisamment de validateurs pour doubler la quantité d'ether mis en jeu prend environ 200 jours, achetant effectivement aux validateurs honnêtes 200 jours avant que l'attaquant ne puisse tenter une autre attaque des 51 %. Cependant, la communauté pourrait également décider de pénaliser l'attaquant plus sévèrement, en révoquant les récompenses passées ou en brûlant une partie (jusqu'à 100 %) de son capital mis en jeu.

Quelle que soit la pénalité imposée à l'attaquant, la communauté doit également décider ensemble si la chaîne malhonnête, bien qu'elle soit celle favorisée par l'algorithme de choix de fourche codé dans les clients Ethereum, est en fait invalide et que la communauté devrait plutôt construire sur la chaîne honnête. Les validateurs honnêtes pourraient collectivement accepter de construire sur un fork accepté par la communauté de la chaîne de blocs Ethereum qui pourrait, par exemple, s'être séparé de la chaîne canonique avant le début de l'attaque ou avoir vu les validateurs des attaquants retirés de force. Les validateurs honnêtes seraient incités à construire sur cette chaîne car ils éviteraient les pénalités qui leur sont appliquées pour ne pas avoir (à juste titre) attesté de la chaîne de l'attaquant. Les plateformes d'échange, les passerelles d'accès et les applications construites sur Ethereum préféreraient vraisemblablement être sur la chaîne honnête et suivraient les validateurs honnêtes vers la chaîne de blocs honnête.

Cependant, ce serait un défi de gouvernance substantiel. Certains utilisateurs et validateurs seraient sans aucun doute perdants à la suite du retour à la chaîne honnête, les transactions dans les blocs validés après l'attaque pourraient potentiellement être annulées, perturbant la couche d'application, et cela sape tout simplement l'éthique de certains utilisateurs qui ont tendance à croire que « le code fait loi » (code is law). Les plateformes d'échange et les applications auront très probablement lié des actions hors chaîne à des transactions onchain qui peuvent maintenant être annulées, déclenchant une cascade de rétractations et de révisions qu'il serait difficile de démêler équitablement, en particulier si des gains mal acquis ont été mélangés, déposés dans la DeFi ou d'autres dérivés avec des effets secondaires pour les utilisateurs honnêtes. Sans aucun doute, certains utilisateurs, peut-être même institutionnels, auraient déjà bénéficié de la chaîne malhonnête soit en étant astucieux soit par hasard, et pourraient s'opposer à un fork pour protéger leurs gains. Il y a eu des appels à répéter la réponse de la communauté aux attaques de >51 % afin qu'une atténuation coordonnée et sensée puisse être exécutée rapidement. Il y a une discussion utile de Vitalik sur ethresear.ch ici (opens in a new tab) et ici (opens in a new tab) et sur Twitter ici (opens in a new tab). Le but d'une réponse sociale coordonnée devrait être d'être très ciblé et spécifique sur la punition de l'attaquant et la minimisation des effets pour les autres utilisateurs.

La gouvernance est déjà un sujet compliqué. Gérer une réponse d'urgence de la Couche 0 à une chaîne de finalisation malhonnête serait sans aucun doute un défi pour la communauté Ethereum, mais cela s'est produit - deux fois - dans l'histoire d'Ethereum).

Néanmoins, il y a quelque chose d'assez satisfaisant dans le fait que le recours final se trouve dans le monde réel (meatspace). En fin de compte, même avec cette pile phénoménale de technologie au-dessus de nous, si le pire devait arriver, de vraies personnes devraient se coordonner pour s'en sortir.

Résumé

Cette page a exploré certaines des façons dont les attaquants pourraient tenter d'exploiter le protocole de consensus à preuve d'enjeu d'Ethereum. Les réorganisations et les retards de finalité ont été explorés pour des attaquants avec des proportions croissantes de l'ether total mis en jeu. Dans l'ensemble, un attaquant plus riche a plus de chances de succès car sa mise se traduit par un pouvoir de vote qu'il peut utiliser pour influencer le contenu des blocs futurs. À certains montants seuils d'ether mis en jeu, le pouvoir de l'attaquant augmente :

33 % : retard de finalité

34 % : retard de finalité, double finalité

51 % : retard de finalité, double finalité, censure, contrôle sur l'avenir de la chaîne de blocs

66 % : retard de finalité, double finalité, censure, contrôle sur l'avenir et le passé de la chaîne de blocs

Il existe également une gamme d'attaques plus sophistiquées qui nécessitent de petites quantités d'ether mis en jeu mais reposent sur un attaquant très sophistiqué ayant un contrôle fin sur la synchronisation des messages pour faire basculer l'ensemble des validateurs honnêtes en sa faveur.

Dans l'ensemble, malgré ces vecteurs d'attaque potentiels, le risque d'une attaque réussie est faible, certainement inférieur aux équivalents de la preuve de travail (PoW). Cela est dû au coût énorme de l'ether mis en jeu mis en péril par un attaquant visant à submerger les validateurs honnêtes avec son pouvoir de vote. La couche d'incitation intégrée de « la carotte et le bâton » protège contre la plupart des malversations, en particulier pour les attaquants à faible mise. Les attaques plus subtiles par rebond et par équilibrage ont également peu de chances de réussir car les conditions réelles du réseau rendent le contrôle fin de la livraison des messages à des sous-ensembles spécifiques de validateurs très difficile à réaliser, et les équipes clientes ont rapidement fermé les vecteurs d'attaque connus par rebond, par équilibrage et par avalanche avec de simples correctifs.

Les attaques à 34 %, 51 % ou 66 % nécessiteraient probablement une coordination sociale hors bande pour être résolues. Bien que cela serait probablement douloureux pour la communauté, la capacité d'une communauté à répondre hors bande est une forte dissuasion pour un attaquant. La couche sociale d'Ethereum est l'ultime filet de sécurité - une attaque techniquement réussie pourrait toujours être neutralisée par la communauté acceptant d'adopter un fork honnête. Il y aurait une course entre l'attaquant et la communauté Ethereum - les milliards de dollars dépensés pour une attaque à 66 % seraient probablement anéantis par une attaque de coordination sociale réussie si elle était lancée assez rapidement, laissant l'attaquant avec de lourds sacs d'ether mis en jeu illiquides sur une chaîne malhonnête connue ignorée par la communauté Ethereum. La probabilité que cela finisse par être rentable pour l'attaquant est suffisamment faible pour être un moyen de dissuasion efficace. C'est pourquoi l'investissement dans le maintien d'une couche sociale cohésive avec des valeurs étroitement alignées est si important.