Analyse complète des attaques de sandwich MEV : de l'ordonnancement à la chaîne mortelle des échanges éclair.

Rédigé par : Daii

Mercredi dernier (12 mars), un trader de cryptomonnaies a perdu 215 000 dollars en une seule fois à cause d'une attaque MEV.

En termes simples, cet utilisateur voulait échanger des USDC d'une valeur de 220 800 dollars contre l'équivalent en USDT dans la piscine de trading Uniswap v3, mais il n'a obtenu que 5 272 USDT, perdant ainsi 215 700 dollars en quelques secondes, comme le montre l'image ci-dessous.

L'image ci-dessus est une capture d'écran des enregistrements en chaîne de cette transaction. La raison fondamentale de cette tragédie est la rencontre avec la tristement célèbre "attaque de sandwich" (Sandwich Attack) dans le monde de la blockchain.

La première à révéler cette attaque MEV est Michael (voir l'image ci-dessus), qui a expliqué que :

Un bot MEV a devancé la transaction en échangeant toute la liquidité USDC. Après l'exécution de la transaction, ils ont remis la liquidité. L'attaquant a donné un pourboire de 200 000 $ à un constructeur de blocs (bobTheBuilder) et a réalisé un bénéfice de 8 000 $ grâce à cette transaction.

Le contenu ci-dessus contient une erreur typographique, le robot d'attaque MEV échange une grande quantité de USDT, et non de USDC.

Cependant, après avoir lu ses explications et les reportages, vous êtes peut-être toujours dans le flou, car il y a trop de nouveaux termes, comme attaque par sandwich (Sandwich Attack), passer devant (front-ran the tx), remettre la liquidité (put back the liquidity), donner un pourboire à un constructeur de blocs (tipped a block builder), etc.

Aujourd'hui, nous allons prendre cet exemple d'attaque MEV pour décomposer l'ensemble du processus et vous emmener explorer ce monde obscur qu'est le MEV.

Tout d'abord, nous devons expliquer ce qu'est le MEV.

1. Qu'est-ce que l'MEV ?

MEV, qui était à l'origine appelé valeur extractible par les mineurs (Miner Extractable Value), fait référence aux profits supplémentaires que les mineurs peuvent obtenir en réorganisant, en insérant ou en excluant des transactions dans les blocs de la blockchain. Cette opération peut entraîner des coûts plus élevés pour les utilisateurs ordinaires ou des prix de transaction moins favorables.

Avec le passage des réseaux blockchain comme Ethereum du mécanisme de consensus de preuve de travail (Proof-of-Work, PoW) à celui de preuve de participation (Proof-of-Stake, PoS), le pouvoir de contrôler l'ordre des transactions a été transféré des mineurs aux validateurs. Par conséquent, le terme a également évolué de « valeur extractible par le mineur » (Miner Extractable Value) à « valeur extractible maximale » (Maximal Extractable Value).

Bien que le nom ait changé, le concept fondamental d'extraction de valeur par la manipulation de l'ordre des transactions reste le même.

Le contenu ci-dessus est encore un peu technique, vous devez juste vous rappeler : l'existence de l'MEV est due au fait que les anciens mineurs et les validateurs actuels détiennent un droit de trier les transactions dans le mempool. Ce tri se produit dans un bloc, et actuellement, Ethereum produit un bloc environ toutes les 11 secondes, ce qui signifie qu'il y a un exercice de ce pouvoir toutes les 11 secondes. De même, cette attaque MEV a également été réalisée par le biais du tri par les validateurs.

En cliquant sur ce lien, vous verrez le contenu des transactions contenues dans le bloc numéro 22029771 lié à cette attaque, comme indiqué dans l'image ci-dessous.

Veuillez noter que les transactions dans les images 1, 2 et 3 correspondent à l'attaque MEV mentionnée au début de cet article, et cet ordre a été organisé par le validateur (bobTheBuilder). Pourquoi cela est-il possible ?

2. Le principe de l'MEV

Pour comprendre le fonctionnement de l'MEV, nous devons d'abord comprendre comment la blockchain enregistre et met à jour les informations.

2.1 Mécanisme de mise à jour de l'état de la blockchain

La blockchain peut être considérée comme un registre en constante augmentation, qui enregistre toutes les transactions effectuées. L'état de ce registre, comme le solde de chaque compte, les réserves de divers tokens dans le pool de transactions Uniswap, etc., est déterminé par les transactions antérieures.

Lorsqu'un nouveau bloc est ajouté à la blockchain, toutes les transactions contenues dans ce bloc sont exécutées une par une dans l'ordre dans lequel elles sont disposées dans le bloc. À chaque exécution d'une transaction, l'état global de la blockchain change en conséquence.

C'est-à-dire que non seulement l'ordre des blocs est important, mais l'ordre des transactions dans les blocs l'est également. Alors, comment l'ordre des transactions dans un bloc est-il déterminé ?

2.2 Les validateurs décident de l'ordre des transactions

Lorsque l'utilisateur initie une transaction sur le réseau blockchain, par exemple cette transaction qui convertit USDC en USDT via Uniswap, elle est d'abord diffusée aux nœuds du réseau. Après une vérification préliminaire, la transaction entre dans une zone appelée « mempool ». La mempool est comme une zone d'attente où les transactions n'ont pas encore été confirmées et ajoutées au prochain bloc de la blockchain.

Les anciens mineurs (dans un système PoW), maintenant des validateurs (dans un système PoS) ont le droit de sélectionner des transactions dans la mempool et de décider de l'ordre de ces transactions dans le prochain bloc.

L'ordre des transactions dans un bloc est crucial. Avant qu'un bloc ne soit définitivement confirmé et ajouté à la blockchain, les transactions de ce bloc sont exécutées dans l'ordre déterminé par le validateur (comme bobTheBuilder). Cela signifie que si un bloc contient plusieurs transactions interagissant avec le même pool de transactions, l'ordre d'exécution de ces transactions affectera directement le résultat de chacune d'elles.

Cette capacité permet aux validateurs de traiter en priorité certaines transactions, de retarder ou d'exclure d'autres transactions, voire d'insérer leurs propres transactions pour maximiser leurs profits.

L'ordre de cette transaction est tout aussi important, une légère erreur rendrait impossible une attaque réussie.

2.3 Séquençage des transactions dans cette attaque MEV

Nous allons d'abord comprendre brièvement les 3 transactions liées à cette attaque MEV :

Transaction 1 (première transaction de l'attaquant) : effectuée avant la transaction de la victime. Le but de cette transaction est généralement de faire monter le prix du jeton que la victime souhaite échanger.

Transaction 2 (Transaction of the victim): Executed after the attacker’s first transaction. Due to the attacker’s previous actions, the price in the transaction pool is now unfavorable for the victim, who needs to pay more USDC to exchange for an equivalent amount of USDT, or can only exchange for less USDT.

Transaction 3 (la deuxième transaction de l'attaquant) : exécutée après la transaction de la victime. Le but de cette transaction est généralement de tirer parti des nouveaux mouvements de prix causés par la transaction de la victime pour réaliser un profit.

Cette fois, le validateurs de l'attaque MEV est bob-The-Builder.eth, c'est lui qui est responsable de l'ordre des transactions, comme 1, 2, 3. Bien sûr, bobTheBuilder ne travaille pas pour rien, il a gagné plus de 100 ETH grâce à ce tri, tandis que l'initiateur de l'attaque MEV n'a gagné que 8000 dollars. Leur revenu provient de la deuxième transaction de la victime.

En d'autres termes, l'attaquant (robot MEV) a conspiré avec le validateur (bobTheBuilder), entraînant une perte de 215 000 dollars pour la victime de la deuxième transaction, dont l'attaquant a obtenu 8 000 dollars et le validateur 200 000 dollars (plus de 100 ETH).

Ils utilisent une méthode d'attaque qui a un nom évocateur : l'attaque sandwich. Ci-dessous, nous allons expliquer cela transaction par transaction, afin que vous compreniez complètement en quoi consiste l'attaque sandwich, qui est relativement complexe en ce qui concerne MEV.

3. Analyse complète de l’attaque sandwich

C'est pourquoi on appelle cela une attaque sandwich (Sandwich Attack), car les deux transactions de l'attaquant (transaction 1 et transaction 3) sont respectivement placées avant et après la transaction de la victime (transaction 2), ce qui donne à l'ensemble de l'ordre des transactions une structure semblable à celle d'un sandwich (voir l'image ci-dessus).

Les transactions 1 et 3 ont des fonctions différentes. En termes simples, la transaction 1 est responsable de l'exécution, tandis que la transaction 3 est responsable de la répartition du butin. Plus précisément, le processus est le suivant :

3.1 Transaction 1, responsable d'augmenter le prix de l'USDT

Cliquez sur le lien de la transaction numéro 1 dans l'image ci-dessus, vous verrez les détails de la transaction numéro 1. L'attaquant a également directement augmenté le prix du USDT en échangeant les 17,58 millions de USDT présents avec 18,65 millions de USDC, comme le montre l'image ci-dessous.

À ce stade, tout ce qui reste dans le pool de liquidité est une grande quantité d’USDC et une petite quantité d’USDT. Si, selon le reportage, avant l’attaque, Uniswap disposait d’environ 19,8 millions d’USDC et d’USDT de liquidités, alors après l’exécution de la transaction 1, il ne restait plus que 2,22 millions d’USDT dans le pool (=1980-1758), et le solde USDC est passé à environ 38,45 millions (=1980+1865).

À ce stade, le taux de conversion entre l'USDC et l'USDT dans ce pool n'est plus de 1:1, mais plutôt de 1:17, ce qui signifie qu'il faut maintenant 17 USDC pour échanger contre 1 USDT. Cependant, ce taux est approximatif, car ce pool est de type V3 et sa liquidité n'est pas uniformément répartie.

Il y a encore un point que je dois vous dire. En réalité, l'attaquant n'a pas utilisé 18,65 millions de USDC d'un coup, le montant réel utilisé était de 1,09 million, même pas 6 %. Comment a-t-il fait ? Nous en parlerons plus en détail une fois que nous aurons terminé de décrire l'attaque.

3.2 Transaction 2, exécution de 220 000 USDC échangés contre USDT

En cliquant sur le lien de la transaction 2 dans l'image ci-dessus, vous pouvez voir l'image ci-dessous.

Comme indiqué sur l'image ci-dessus, la transaction 2 de la victime a été affectée par la transaction 1, recevant seulement 5272 USDT pour 220 000 USDC, perdant ainsi 170 000 USDT sans s'en rendre compte. Pourquoi dit-on que c'est sans s'en rendre compte ? Parce que si la victime avait effectué la transaction via Uniswap, elle aurait vu l'interface suivante au moment de soumettre la transaction.

En regardant l'image ci-dessus, vous constaterez que les victimes devraient au minimum recevoir 220 000, ce qui devrait être garanti. La raison pour laquelle les victimes n'ont finalement reçu que plus de 5000 USDT est en raison d'un glissement énorme, atteignant plus de 90 %. Cependant, Uniswap a une limite de glissement maximale par défaut de 5,5 %, comme le montre l'image ci-dessous.

Cela signifie que si la victime a effectué la transaction via l'interface d'Uniswap, elle devrait recevoir au moins 208381 USDT (= 220510 * 94.5%). Vous vous demandez peut-être pourquoi l'enregistrement de la blockchain ci-dessus indique que cette transaction a été effectuée sur « Uniswap V3 ».

Parce que la partie avant et la partie arrière des transactions sur la blockchain sont séparées. Ce que l'on appelle « Uniswap V3 » fait référence à la réserve USDC-USDT d'Uniswap, qui est publique et accessible à tous les fronts de transaction pour effectuer des échanges.

C'est aussi pour cette raison que certaines personnes doutent que la victime soit ordinaire, qu'elle ne soit pas une personne comme les autres, sinon il n'y aurait pas eu un tel glissement, et il se pourrait qu'il s'agisse d'une attaque MEV pour du blanchiment d'argent. Nous en parlerons plus tard.

3.3 Transaction 3, récolte + partage des gains

Cliquez sur le lien pour voir les détails de la transaction 3, comme indiqué ci-dessus. Nous allons parler des transactions A, B et C.

Transaction A, a rétabli la liquidité dans le pool, a échangé 17,32 millions de USDT contre 18,60 millions de USDC.

Transaction B, préparation du partage, échange d'une partie des bénéfices — 20,4 milliers USDC contre 105 ETH ;

Transaction C, partage des gains, payer 100,558 ETH au validateur bob-The-Builder.eth.

Ainsi, l'attaque sandwich est terminée.

Maintenant, répondons à une question très importante mentionnée ci-dessus : comment l'attaquant a-t-il réalisé une attaque de 18 millions avec 1,09 million de USDC.

4. Comment les attaquants ont mis en œuvre l’attaque du pool de 18 millions d’USDC

La raison pour laquelle l'attaquant a pu réaliser une attaque de niveau 18 millions de dollars avec seulement 1,09 million de USDC de capital, c'est à cause d'un mécanisme magique et spécial dans le monde de la blockchain : l'échange instantané (Flash Swap) de Uniswap V3.

4.1 Qu'est-ce que l'échange éclair (Flash Swap) ?

En termes simples :

L'échange instantané permet aux utilisateurs de retirer des actifs d'un pool Uniswap dans la même transaction, puis de rembourser avec un autre actif (ou le même actif plus des frais).

Uniswap permet ce type de comportement « obtenir d'abord, payer ensuite » tant que l'ensemble de l'opération est effectué dans la même transaction. Notez qu'il doit être réalisé dans la même transaction. Ce design a été conçu pour garantir la sécurité de la plateforme Uniswap elle-même :

Prêt sans risque : Uniswap permet aux utilisateurs de retirer temporairement des fonds du pool sans garantie (similaire à un prêt), mais ils doivent rembourser immédiatement à la fin de la transaction.

Atomicité : L'ensemble de l'opération doit être atomique, soit totalement réussi (remboursement des fonds), soit complètement échoué (annulation de la transaction).

Le design de l'échange éclair a été conçu pour effectuer des arbitrages sur la chaîne de manière plus efficace, mais il a malheureusement été exploité par des attaquants MEV, devenant ainsi un instrument de manipulation du marché.

4.2 Comment l'échange instantané soutient-il ?

Voyons maintenant l'illustration pour expliquer étape par étape comment l'échange éclair de cette attaque a été réalisé, voir l'image ci-dessous.

Le F1 attaquant emprunte 1,09 million de USDC auprès d'AAVE en utilisant ses 701 WETH.

L'attaquant F2 lance une demande d'échange éclair, retirant d'abord 17,58 millions de USDT du pool Uniswap (sans paiement préalable à ce stade) ; le compte de l'attaquant a temporairement augmenté de 17,58 millions de USDT.

L'attaquant F3 a rapidement investi 17,58 millions de USDT dans la piscine Curve, échangeant contre 17,55 millions de USDC. Le compte de l'attaquant a vu ses USDT diminuer de 17,58 millions et ses USDC augmenter de 17,55 millions. Comme vous pouvez le voir sur le graphique ci-dessous, l'attaquant a choisi Curve car la liquidité y est très abondante, avec plus de 70,54 millions de USDT et 50,71 millions de USDC, ce qui entraîne un slippage relativement faible.

F4 les attaquants ont ensuite remboursé à Uniswap un total de 18,64 millions de USDC, en utilisant 17,55 millions de USDC échangés via Curve, ainsi que 1,09 million de USDC (provenant de prêts Aave) en une seule fois ;

Après cette transaction (transaction 1), le solde du compte de l'attaquant a diminué de 1,09 million USDC, car sur les 18,64 millions USDC restitués à Uniswap, seulement 17,55 millions USDC provenaient de Curve, les 1,09 million USDC restants étant des fonds propres de l'attaquant.

Vous devriez avoir remarqué que cette transaction a en réalité coûté 1,09 million à l'attaquant. Cependant, la transaction 3 suivante, qui a également utilisé la méthode d'échange instantané, non seulement a récupéré 1,09 million USDC, mais a également gagné plus de 200 000.

Analysons étape par étape les données de la transaction 3.

K1 Attacker a retiré 18,6 millions de USDC sur Uniswap avec un échange éclair ;

L'attaquant K2 a échangé 17,3 millions de USDC, provenant d'un retrait récent d'Uniswap, contre 17,32 millions de USDT.

L'attaquant K1 a retourné les 17,32 millions de USDT échangés depuis Curve à Uniswap. L'échange éclair est terminé. Vous devez noter que l'attaquant a obtenu 17,32 millions de USDT en ne dépensant que 17,30 millions de USDC via K2. Parmi les 1,30 million (soit 1,860-1,730) de USDC restants, 1,09 million provient de fonds propres, tandis que les 210 000 USDC restants représentent le profit de cette attaque.

K3 attaquant, a remboursé le principal à AAVE, a pris 701 WETH pour lui-même, tout en échangeant 200 000 USDC contre 105 ETH, et a envoyé 100,558 ETH à un validateur en tant que pourboire (environ 200 000 dollars), ne gardant pour lui-même qu'un bénéfice de moins de 10 000 dollars.

Vous pourriez être surpris de savoir pourquoi les attaquants sont prêts à céder jusqu'à 200 000 dollars de bénéfices aux validateurs.

4.3 Pourquoi donner un « pourboire » de 200 000 dollars ?

En fait, il ne s’agit pas de générosité, mais d’une condition nécessaire à la réussite d’une attaque MEV comme une attaque sandwich :

Le cœur du succès d'une attaque réside dans le contrôle précis de l'ordre des transactions, et c'est le validateur (bobTheBuilder) qui contrôle cet ordre.

Les validateurs aident non seulement les attaquants à s'assurer que les transactions des victimes se trouvent entre les transactions d'attaque, mais surtout, les validateurs peuvent garantir qu'aucun robot MEV concurrent ne peut se faufiler ou interférer avec le bon déroulement de l'attaque.

Ainsi, l'attaquant préfère sacrifier la majeure partie de ses bénéfices pour garantir le succès de l'attaque, tout en conservant une certaine part de bénéfice pour lui-même.

Il convient de préciser que les attaques MEV ont également un coût. Il y a un coût lors des échanges flash sur Uniswap, et il y a aussi un coût lors des transactions sur Curve. Cependant, en raison de taux relativement bas, d'environ 0,01 à 0,05 %, cela peut sembler insignifiant par rapport aux gains des attaques.

Pour finir, je tiens à rappeler que la défense contre les attaques MEV est en réalité très simple. Il vous suffit de : définir un seuil de tolérance au slippage, ne pas dépasser 1 % ; exécuter les grosses transactions en plusieurs fois. Donc, vous n'avez pas à vous priver de trader sur les DEX (échanges décentralisés) à cause de cela.

Conclusion : Avertissement et révélation dans la forêt sombre

Cet incident d'attaque MEV de 215 000 dollars est sans aucun doute une nouvelle démonstration brutale de la loi de la "forêt sombre" dans le monde de la blockchain. Il révèle de manière vivante la complexité des jeux qui se cachent derrière l'exploitation des failles des mécanismes pour en tirer profit dans un environnement décentralisé et sans autorisation.

D'un point de vue plus élevé, l'émergence de l'MEV est une manifestation de l'effet à double tranchant de la transparence et de la programmabilité de la blockchain.

D'une part, tous les enregistrements de transactions sont publics et vérifiables, ce qui permet de suivre et d'analyser les comportements malveillants ;

D'autre part, la logique complexe des contrats intelligents et la détermination de l'exécution des transactions offrent également aux participants avisés une opportunité à saisir.

Ce n'est pas un simple acte de piratage, mais une compréhension profonde et une utilisation des mécanismes sous-jacents de la blockchain, qui met à l'épreuve la robustesse de la conception des protocoles et défie la conscience des risques des participants.

Comprendre le MEV et reconnaître ses risques est essentiel pour naviguer au mieux dans ce monde numérique rempli d'opportunités mais aussi de dangers. Souvenez-vous, dans la "forêt sombre" de la blockchain, seule la crainte des règles et l'amélioration de la conscience peuvent vous éviter de devenir la prochaine proie dévorée.

C'est aussi l'effet que je souhaite atteindre à travers cet article.