Attaque et défense de preuve d'enjeu Ethereum

Les voleurs et les saboteurs sont constamment à la recherche d'opportunités pour attaquer le logiciel client d'Ethereum. Cette page met en lumière les vecteurs d'attaques connus sur la couche de consensus d'Ethereum. Elle montre aussi comment ces attaques peuvent être défendues. Les informations de cette page sont une adaptation d'une version de longue forme(opens in a new tab).

Les prérequis

Quelques notions de bases de la preuve d'enjeu sont requises. Aussi, cela serait utile d'avoir les notions de compréhension de base des la couche d'incitation d'Ethereum et de l'algorithme de choix de fourche , LMD-GHOST.

Que veulent les attaquants ?

Une idée erronée courante est qu'un attaquant couronné de succès peut générer de nouveaux éthers ou absorber des éthers depuis des comptes arbitraires. Ni l'une, ni l'autre situation 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 à des conditions élémentaires de validité (par exemple, les transactions sont signées par la clé privée de l'expéditeur, l'expéditeur dispose d'un solde suffisant, etc.) sinon elles sont simplement annulées. Il y a trois types de résultats qu'un attaquant pourrait viser : les reorgs, la double finalité ou le délai de finalité.

Un "reorg" est un mélange de blocs dans un nouvel ordre, avec éventuellement une addition ou soustraction de blocs dans la chaîne canonique. Une reorg malveillante pourrait garantir que des blocs spécifiques soient inclus ou exclus, permettant une double dépense ou une extraction de valeur en anticipant ou retardant les transactions (MEV). Les re-orgs pourraient également être utilisés pour empêcher certaines transactions d'être incluses dans la chaîne canonique - une forme de censure. La forme la plus extrême de reorg est la « réversion de finalité » qui supprime ou remplace les 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 situation peu probable mais grave où deux fourches sont capables de finaliser simultanément, créant un schisme permanent dans la chaîne. Cela est théoriquement possible pour un attaquant prêt à risquer 34 % de l'éther total mis en jeu. La communauté serait alors forcée de coordonner hors chaîne et de se mettre d'accord sur la chaîne à suivre, ce qui nécessiterait une solidité dans la couche sociale.

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

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

Après avoir établi les raisons pour lesquelles un adversaire pourrait attaquer Ethereum, les sections suivantes examinent comment il pourrait s'y prendre.

Méthodes d'attaque

Attaques de couche 0

Premièrement, les individus qui ne participent pas activement à Ethereum (en exécutant le logiciel client) peuvent attaquer en ciblant la couche sociale (Couche 0). La couche 0 est la fondation sur laquelle repose l'Ethereum, et, en tant que telle, représente une potentielle surface pour les attaques avec des conséquences se répercutant sur le reste de la pile. Voici quelques exemples :

Une campagne de désinformation pourrait éroder la confiance de la communauté dans la feuille de route d'Ethereum, les équipes de développeurs, les applications, etc. Cela pourrait alors réduire le nombre de personnes désireuses de participer à la sécurisation du réseau, dégradant ainsi la décentralisation et la sécurité crypto-économique.
Attaques ciblées et/ou intimidation à l'encontre de la communauté de développeurs. Cela pourrait entraîner le départ volontaire de développeurs et ralentir la progression d'Ethereum.
Une réglementation trop zélée pourrait également être considérée comme une attaque de la couche 0, car elle pourrait rapidement décourager la participation et l'adoption.
Infiltration dans la communauté de développeurs d'acteurs bien informés mais malveillants dont l'objectif est de ralentir les progrès en court-circuitant les discussions, en retardant les décisions clés, en créant des spams, etc.
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 nécessaire. Une attaque de la couche 0 pourrait multiplier les effets d'une attaque crypto-économique. Par exemple, si une censure ou une réversion de finalité était réalisée par un actionnaire majoritaire malveillant, miner la couche sociale pourrait rendre plus difficile la coordination d'une réponse de la communauté hors ligne.

Défendre les attaques sur la couche 0 n'est probablement pas simple, mais quelques principes basiques peuvent être établis. L'un d'eux est de maintenir un rapport signal/bruit élevé pour l'information publique sur Ethereum, créée et diffusée 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 le plus grand nombre de langues possible. Inonder un espace avec des informations de haute qualité et des mèmes 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 blockchains de contrats intelligents en couche 1, tout en valorisant fortement la scalabilité et la durabilité. Quels que soient les désaccords au sein de la communauté Ethereum, ces principes fondamentaux sont compromis au minimum. Évaluer un récit par rapport à ces principes fondamentaux, et les examiner à travers des tours successifs d'examen dans le processus EIP (Ethereum Improvement Proposal), pourrait aider la communauté à distinguer les bons acteurs des mauvais et limite la portée pour les acteurs malveillants d'influencer la direction future d'Ethereum.

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

Attaquer le protocole

Tout le monde peut utiliser le logiciel client d'Ethereum. Pour ajouter un validateur à un client, l'utilisateur doit mettre en jeu 32 ether dans le contrat de dépôt. Un validateur permet à un utilisateur de participer activement à la sécurité du réseau Ethereum en proposant et en attestant de nouveaux blocs. Le validateur dispose désormais d'une voix qu'il peut utiliser pour influencer le contenu futur de la blockchain - il peut le faire honnêtement et augmenter sa réserve d'ether via des récompenses ou il peut essayer de manipuler le processus à son propre avantage, en risquant sa mise. L'une des façons de monter une attaque consiste à accumuler une plus grande proportion de l'enjeu total et à l'utiliser pour mettre en minorité les validateurs honnêtes. Plus la part de la participation contrôlée par l'attaquant est importante, plus son pouvoir de vote est élevé, en particulier à certaines étapes économiques que nous examinerons plus tard. Cependant, la plupart des attaquants ne seront pas en mesure d'accumuler suffisamment d'ether pour attaquer de cette manière, et devront donc utiliser des techniques subtiles pour manipuler la majorité honnête afin qu'elle agisse d'une certaine manière.

Fondamentalement, toutes les attaques à faible enjeu sont des variations subtiles de deux types de comportement erroné du validateur : la sous-activité (ne pas proposer ou le faire en retard) ou la suractivité (proposer/attester trop de fois dans un créneau). Dans leurs formes les plus basiques, 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 tromper le système à l'avantage de l'attaquant.

Attaques utilisant de faibles quantités d'ETH

reorgs

Plusieurs documents ont expliqué des attaques sur Ethereum qui réalisent des reorgs ou des retards 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 dissimule certaines informations aux autres validateurs, puis les divulgue d'une manière subtile et/ou à un moment opportun. Ils 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 d'un bloc (B) pour un créneau particulier n+1 mais s'abstenir de le propager à d'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 envoyer leur bloc retenu (B) et leurs attestations retenues pour lui, et dans le même attester que B est la tête de la chaîne avec leurs votes pour le créneau n+2, niant effectivement l'existence du bloc honnête C. Lorsque le bloc honnête D est créé, l'algorithme de choix de fourche voit D se construire sur B étant plus lourd que D se construisant 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 un reorg ex ante d'1 bloc. Un attaquant avec 34 %(opens in a new tab) des enjeux 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 enjeux plus petits. Neuder et al 2020(opens in a new tab) décrit cette attaque fonctionnant avec une participation 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 puis à nouveau pour un seul validateur(opens in a new tab) en utilisant des techniques d'équilibrage que nous examinerons dans la section suivante.

Un schéma conceptuel de l'attaque de reorg 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 d'équilibrage. L'attaquant attend sa chance de proposer un bloc, et lorsqu'elle arrive, il équivaut et propose deux. Ils envoient un bloc à la moitié de l'ensemble des validateurs honnêtes et l'autre bloc à l'autre moitié. L'équivocation serait détectée par l'algorithme de choix de fourche et le proposeur de bloc serait puni et expulsé du réseau, mais les deux blocs existeraient toujours et auraient environ la moitié de l'ensemble des validateurs attestant de chaque fourche. Pendant ce temps, les validateurs malveillants restants retiennent leurs attestations. Ensuite, en libérant sélectivement les attestations en faveur de l'une ou l'autre fourche à suffisamment de validateurs juste au moment où l'algorithme de choix de fork s'exécute, ils inclinent le poids accumulé des attestations en faveur de l'une ou l'autre fourche. Cela peut continuer indéfiniment, les validateurs attaquants maintenant une division égale des validateurs entre les deux fourches. Comme aucune des deux fourches ne peut attirer une super-majorité de 2/3, le réseau ne finaliserait pas.

Les attaques de rebond sont similaires. Les votes sont à nouveau retenus par les validateurs attaquants. Au lieu de libérer les votes pour maintenir une répartition égale entre deux fourches, ils utilisent leurs votes à des moments opportuns pour justifier des points de contrôle qui alternent entre le choix A et le choix B. Cette alternance de justification entre deux fourches 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, bloquant ainsi la finalité.

Les attaques de rebond et d'équilibrage dépendent de la capacité de l'attaquant à contrôler très précisément 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'un poids supplémentaire accordé aux messages rapides par rapport aux messages lents. Ceci est connu sous le nom de renforcement du poids du proposeur(opens in a new tab). Pour se défendre contre les attaques de rebond, l'algorithme de choix de fourche a été mis à jour afin que le dernier point de contrôle justifié ne puisse passer à celui d'une chaîne alternative que pendant le premier tiers des créneaux de chaque période(opens in a new tab). Cette condition empêche l'attaquant de cumuler 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 lors du 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 un tiers de créneau (4 secondes) où ce nouveau bloc pourrait amener l'algorithme de choix de fourchette à basculer vers une autre chaîne. Après cette même échéance, les attestations provenant de validateurs lents sont sous-pondérées par rapport à celles qui sont arrivées plus tôt. Cela favorise fortement les proposeurs et validateurs rapides dans la détermination de la tête de la chaîne et réduit considérablement la probabilité d'une attaque réussie d'équilibrage ou de rebond.

Il convient de noter que le renforcement du proposeur à lui seul ne défend que contre les « reorgs bon marché », c'est-à-dire celles tentées par un attaquant avec une petite mise. En fait, le renforcement du proposeur lui-même peut être manipulé par des détenteurs de parts plus importantes. Les auteurs de cet article(opens in a new tab) décrivent comment un attaquant détenant 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 leur fourche, éliminant ainsi un bloc honnête. Cette attaque a été conçue en supposant des conditions de latence idéales qui sont très peu probables. Les chances sont encore très faibles pour l'attaquant, et une mise plus importante signifie également plus de capital en jeu et un moyen de dissuasion économique plus fort.

Une attaque d'équilibrage ciblant spécifiquement la règle LMD(opens in a new tab) a également été proposée, qui serait viable malgré le renforcement du proposeur. Un attaquant met en place deux chaînes concurrentes en rendant équivoque sa proposition de bloc et en propageant chaque bloc à environ la moitié du réseau, établissant un équilibre approximatif entre les fourches. Ensuite, les validateurs complices tergiversent leurs votes, en les chronométrant de sorte que la moitié du réseau reçoive leurs votes pour la Fourche A en premier et l'autre moitié reçoive leurs votes pour la Fourche B en premier. Comme la règle LMD élimine la deuxième attestation et ne garde 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 donnant à l'adversaire un « pouvoir remarquable » pour monter une attaque d'é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 écarte totalement les validateurs problématiques de la considération du choix de fourche. Les validateurs problématiques voient également leur influence future réduite par l'algorithme de choix de fourche. Cela empêche l'attaque d'équilibrage décrite ci-dessus tout en conservant la résilience contre les attaques d'avalanche.

Un autre type d'attaque, appelé attaques avalanche(opens in a new tab), a été décrit dans un article de mars 2022(opens in a new tab). Pour mettre en place une attaque en 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 accumulant jusqu'à ce que la chaîne honnête atteigne un poids de sous-arbre égal avec les blocs retenus. Ensuite, les blocs retenus sont libérés afin qu'ils s'équivoquent au maximum. Les auteurs suggèrent que le renforcement du proposeur - la principale défense contre les attaques d'équilibrage et de rebond - ne protège pas contre certaines variantes d'attaque en avalanche. Cependant, les auteurs ont également démontré l'attaque uniquement sur une version hautement idéalisée du protocole de choix de fourche d'Ethereum (ils ont utilisé GHOST sans LMD).

L'attaque en avalanche est atténuée par la partie LMD de l'algorithme de choix de fourche LMD-GHOST. LMD signifie « dirigé par le dernier message » et cela fait référence à un tableau conservé 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 plus tardif que celui déjà dans le tableau pour un validateur particulier. En pratique, cela signifie que dans chaque créneau, le premier message reçu est celui qui est accepté et tous les messages supplémentaires sont des équivoques à ignorer. Autrement dit, les clients du consensus ne comptent pas les équivoques - ils utilisent le premier message arrivant de chaque validateur et les équivoques sont simplement écartées, empêchant les attaques en avalanche.

Il existe plusieurs autres mises à niveau potentielles de la règle de choix de fourche qui pourraient ajouter à la sécurité fournie par le renforcement du proposeur. L'une est la fusion des vues(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 proposeur aide ensuite à synchroniser la vue de la chaîne à travers le réseau. Une autre mise à niveau potentielle est la finalité en un seul créneau(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 document(opens in a new tab) qui a d'abord décrit l'attaque de réorganisation d'un bloc à faible coût a également décrit une attaque de retard de finalité (également connue sous le nom de « défaillance de disponibilité ») qui repose sur le fait que l'attaquant soit le proposeur de bloc pour un bloc à la limite d'une période. C'est crucial car ces blocs à la limite d'une période 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 précédent à la limite d'une période comme cible de finalisation actuelle. Ensuite, ils publient leur bloc retenu. Ils attestent de leur bloc et les autres validateurs honnêtes en font autant, créant des fourches avec différents points de contrôle cibles. S'ils l'ont chronométré parfaitement, ils empêcheront la finalité car il n'y aura pas de super-majorité de deux tiers attestant de l'une ou l'autre fourche. Plus la mise est petite, plus le chronométrage doit être précis car l'attaquant contrôle directement moins d'attestations, et plus les chances que l'attaquant contrôle le validateur proposant un bloc à la limite d'une période donnée sont faibles.

Attaques à longue portée

Il existe également une classe d'attaques spécifique aux blockchains preuve d'enjeu qui implique un validateur ayant participé au bloc d'origine en maintenant une fourche séparée de la blockchain à côté de la fourche honnête, convaincant éventuellement l'ensemble des validateurs honnêtes de basculer dessus à 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 sont d'accord sur l'état de la chaîne honnête à intervalles réguliers (les « 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 hachage d'état récent de confiance (un « point de contrôle de la faible subjectivité »(opens in a new tab)") et en l'utilisant comme un pseudo bloc d'origine pour construire par-dessus. Cela crée une « passerelle de confiance » pour un nouveau nœud entrant dans le réseau avant qu'il puisse commencer à vérifier l'information par lui-même.

Déni de service

Le mécanisme PoS d'Ethereum sélectionne à chaque créneau un unique validateur parmi l'ensemble des validateurs pour proposer un bloc. Cela peut être calculé en utilisant une fonction publiquement connue et il est possible pour un adversaire d'identifier le prochain proposeur de bloc légèrement à l'avance. L'attaquant peut alors inonder de requêtes 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 était 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 blockchain. La mise en œuvre des élections secrètes de leader unique (SSLE) ou des élections non secrètes de leader unique atténuera les risques de DoS car seul le proposeur de bloc saura qu'il a été sélectionné et la sélection n'est pas connue à l'avance. Ceci n'est pas encore implémenté, mais est un domaine actif de recherche et développement(opens in a new tab).

Tout cela montre à quel point il est très difficile d'attaquer avec succès Ethereum avec une petite mise. Les attaques viables décrites ici nécessitent un algorithme de choix de fourche idéalisé, des conditions réseau improbables, ou les vecteurs d'attaque ont déjà été corrigés avec des mises à jour mineures du logiciel client. Cela n'exclut pas la possibilité d'attaques zero-day existantes, mais cela montre le niveau très élevé d'aptitude technique, de connaissance de la couche de consensus et de chance nécessaire pour qu'un attaquant avec une mise minoritaire soit efficace. Du point de vue d'un attaquant, le mieux serait 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 deviennent plus susceptibles de réussir lorsque l'attaquant dispose de plus d'ether misé pour voter, et de plus de validateurs qui pourraient être choisis pour proposer des blocs à chaque créneau. Un validateur malveillant pourrait donc viser à contrôler autant d'ether misé que possible.

33 % de l'ether misé est un seuil de référence pour un attaquant car avec plus que cela, ils ont la capacité d'empêcher la chaîne de 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é atteste malicieusement ou n'atteste pas, alors une super-majorité de 2/3 ne peut exister et la chaîne ne peut finaliser. La défense contre cela est la fuite d'inactivité. Cette fuite identifie les validateurs qui n'attestent pas ou attestent contrairement à la majorité. L'ether misé par ces validateurs qui n'attestent pas est progressivement réduit jusqu'à ce qu'ils représentent collectivement moins de 1/3 du total afin que la chaîne puisse à nouveau finaliser.

Le but de la fuite d'inactivité est de faire finaliser à nouveau la chaîne. Cependant, l'attaquant perd aussi une partie de son ether misé. Une inactivité persistante parmi les validateurs représentant 33% de l'ether misé total est très coûteuse même si les validateurs ne sont pas sanctionnés.

En supposant que le réseau Ethereum soit asynchrone (c'est-à-dire qu'il y ait des retards 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 équivoquer lorsqu'il est choisi comme producteur de bloc, puis voter deux fois avec tous ses validateurs. Cela crée une situation où une fourche de la blockchain existe, chacune avec 34 % de l'ether misé votant pour elle. Chaque fourche nécessite seulement 50 % des validateurs restants pour voter en sa faveur pour que les deux fourches soient soutenues par une super-majorité, auquel cas les deux chaînes peuvent finaliser (car 34 % des validateurs attaquants + la moitié des 66 % restants = 67 % sur chaque fourche). Les blocs concurrents devraient chacun être reçus par environ 50 % des validateurs honnêtes, donc cette attaque est viable seulement lorsque l'attaquant a un certain degré de contrôle sur la synchronisation des messages se propageant sur le réseau afin qu'ils puissent pousser la moitié des validateurs honnêtes sur chaque chaîne. L'attaquant détruirait nécessairement toute sa mise (34 % des ~10 millions d'ethers avec l'ensemble des validateurs actuels) pour réaliser cette double finalité car 34 % de leurs validateurs voteraient deux fois simultanément - une offense sanctionnable avec la pénalité de corrélation maximale. La défense contre cette attaque est le coût très élevé de destruction de 34 % de l'ether misé total. Se remettre de cette attaque nécessiterait que la communauté Ethereum se coordonne « hors chaine » et accepte de suivre l'une ou l'autre des fourches et d'ignorer l'autre.

Attaquants utilisant ~50% de la mise totale

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

Il est très improbable qu'un groupe de validateurs malveillants puisse contrôler constamment précisément 50 % du total de la mise compte tenu d'un certain degré de fluctuation dans les nombres de validateurs honnêtes, de la latence du réseau, etc. - le coût énorme d'une telle attaque combiné à la faible probabilité de succès semble être un fort effet dissuasif pour un attaquant rationnel, d'autant plus qu'un petit investissement supplémentaire pour obtenir plus de 50 % débloque beaucoup un pouvoir bien plus grand.

Avec >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 suffisamment de contrôle pour effectuer de courts réarrangements sans avoir besoin de tromper les clients honnêtes. Les validateurs honnêtes suivraient car leur algorithme de choix de fourche verrait également la chaîne préférée de l'attaquant comme la plus lourde, donc la chaîne pourrait finaliser. Cela permet à l'attaquant de censurer certaines transactions, d'effectuer de courts réarrangements et d'extraire la valeur MEV maximale en réorganisant les blocs à leur avantage. La défense contre cela est l'énorme coût d'une mise majoritaire (actuellement un peu moins de 19 milliards de dollars USD) qui est mis en danger par un attaquant car la couche sociale est susceptible d'intervenir et d'adopter une fourche minoritaire honnête, dévalorisant considérablement la mise de l'attaquant.

Attaquants utilisant >=66 % de la mise totale

Un attaquant disposant de 66 % ou plus de l'ether total misé peut finaliser sa chaîne préférée sans avoir à contraindre aucun validateur honnête. L'attaquant peut simplement voter pour sa fourche préférée puis la finaliser, simplement parce qu'il peut voter avec une super-majorité malhonnête. En tant que détenteur de la super-majorité des enjeux, l'attaquant contrôlerait toujours le contenu des blocs finalisés, avec le pouvoir de dépenser, rembobiner et dépenser à nouveau, censurer certaines transactions et 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é d'effectuer des réarrangements ex post et des réversions de finalité (c'est-à-dire de changer le passé ainsi que de contrôler l'avenir). Les seules véritables défenses ici sont l'énorme coût de 66 % de l'ether total misé, et la possibilité de se replier sur la couche sociale pour coordonner l'adoption d'une fourche alternative. Nous pouvons explorer cela plus en détail dans la section suivante.

Les Gens : 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 se retrouve dans une situation difficile. La chaîne canonique intègre une section malhonnête gravée dans son histoire, tandis que les validateurs honnêtes peuvent finir par être sanctionnés pour avoir attesté d'une chaîne alternative (honnête). Notez qu'une chaîne finalisée mais incorrecte pourrait également résulter 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 toute une gamme de stratégies défensives(opens in a new tab) que la communauté peut utiliser face à une attaque. Une réponse minimale pourrait être d'exclure de force les validateurs 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 garantissant que l'ensemble des validateurs croît progressivement. Par exemple, l'ajout de suffisamment de validateurs pour doubler la quantité d'ether misée prend environ 200 jours, offrant ainsi aux validateurs honnêtes 200 jours avant que l'attaquant ne puisse tenter une nouvelle attaque à 51 %. Cependant, la communauté pourrait également décider de pénaliser l'attaquant plus sévèrement, en révoquant les récompenses précédentes ou en brûlant une partie (jusqu'à 100 %) de leur capital misé.

Quelle que soit la pénalité imposée à l'attaquant, la communauté doit également décider ensemble si la chaîne malhonnête, bien que favorisée par l'algorithme de choix de fourche codé dans les clients Ethereum, est en réalité invalide et que la communauté devrait construire sur la chaîne honnête à la place. Les validateurs honnêtes pourraient collectivement accepter de construire sur une fourche acceptée par la communauté de la blockchain Ethereum qui aurait, par exemple, bifurqué de la chaîne canonique avant le début de l'attaque ou aurait les validateurs attaquants supprimés de force. Les validateurs honnêtes seraient incités à construire sur cette chaîne car ils éviteraient les pénalités qui leur seraient infligées pour ne pas avoir attesté (à juste titre) de la chaîne de l'attaquant. Les échanges, les points d'entrée et les applications construites sur Ethereum préféreraient probablement être sur la chaîne honnête et suivraient les validateurs honnêtes vers la blockchain honnête.

Cependant, il s'agirait d'un défi important en matière de gouvernance. Certains utilisateurs et validateurs subiraient inévitablement des pertes à 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 remettrait tout simplement en question l'éthique de certains utilisateurs qui ont tendance à croire que « le code est la loi ». Les échanges et les applications auront très probablement lié des actions hors chaîne à des transactions en chaîne qui pourraient maintenant être annulées, déclenchant une cascade de rétractations et de révisions qui seraient difficiles à démêler équitablement, surtout si les 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. Certains utilisateurs, peut-être même institutionnels, auraient certainement déjà bénéficié de la chaîne malhonnête, soit par habileté, soit par hasard, et pourraient s'opposer à une fourche pour protéger leurs gains. Il y a eu des appels à répéter la réponse de la communauté aux attaques >51% afin qu'une mitigation coordonnée sensée puisse être exécutée rapidement. Il y a des discussions utiles de Vitalik sur ethresear.ch ici(opens in a new tab) et là(opens in a new tab) et sur Twitter ici(opens in a new tab). L'objectif d'une réponse sociale coordonnée devrait être de punir très précisément l'attaquant et de minimiser les effets pour les autres utilisateurs.

La gouvernance est déjà un sujet complexe. Gérer une réponse d'urgence de la Couche-0 à une chaîne finalisant malhonnêtement 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 à ce que le dernier recours se situe dans le monde réel. En fin de compte, même avec cette pile technologique immense au-dessus de nous, si le pire devait arriver, de vraies personnes devraient se coordonner pour s'en sortir.

Résumé

Cette page explore certaines des façons dont les attaquants pourraient tenter d'exploiter le protocole de consensus de la preuve d'enjeu d'Ethereum. Les réorganisations et les retards de finalité ont été examinés pour des attaquants possédant des proportions croissantes de l'ether total misé. En général, un attaquant plus riche a plus de chances de réussir car sa mise se traduit par un pouvoir de vote qu'il peut utiliser pour influencer le contenu des futurs blocs. À certains seuils de mise en ether, le pouvoir de l'attaquant s'accroît :

33 % : retard de finalité

34 % : retard de finalité, double finalité

51 % : retard de finalité, double finalité, censure, contrôle sur l'avenir de la blockchain

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

Il existe également une gamme d'attaques plus sophistiquées nécessitant de petites quantités d'ether misé mais reposant sur un attaquant très sophistiqué ayant un contrôle précis sur le moment des messages pour influencer l'ensemble des validateurs honnêtes en leur faveur.

Dans l'ensemble, malgré ces potentiels vecteurs d'attaque, le risque d'une attaque réussie est faible, certainement plus faible que les équivalents de la preuve de travail. Cela est dû au coût énorme de l'ether misé mis en jeu par un attaquant cherchant à submerger les validateurs honnêtes avec leur pouvoir de vote. La couche d'incitation intégrée « la carotte et le bâton » protège contre la plupart des malversations, surtout pour les attaquants à faible mise. Des attaques de déséquilibrage et d'équilibrage plus subtiles sont également peu susceptibles 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 difficiles à réaliser, et les équipes de clients ont rapidement fermé les vecteurs d'attaque connus de déséquilibrage, d'équilibrage et d'avalanche avec des correctifs simples.

Les attaques à 34%, 51% ou 66% nécessiteraient probablement une coordination sociale externe pour être résolues. Bien que cela soit probablement douloureux pour la communauté, la capacité d'une communauté à répondre de manière externe est un puissant moyen de dissuasion pour un attaquant. La couche sociale d'Ethereum est le dernier rempart - une attaque techniquement réussie pourrait toujours être neutralisée par la communauté acceptant d'adopter une fourchette 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 livrée assez rapidement, laissant l'attaquant avec de lourds sacs d'ether misé et illiquide sur une chaîne malhonnête connue et 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 investir dans le maintien d'une couche sociale cohérente avec des valeurs étroitement alignées est si important.