Analyse complet de l'attaque MEV en sandwich : de la réorganisation à l'échange instantané, la chaîne mortelle
TechFlow SélectionTechFlow Sélection
Analyse complet de l'attaque MEV en sandwich : de la réorganisation à l'échange instantané, la chaîne mortelle
Comprendre le MEV et ses risques permet de mieux naviguer dans ce monde numérique plein d'opportunités mais aussi d'embûches.
Dédié à des analyses Web3 approfondiesRédaction : Daii
Mercredi dernier (12 mars), un trader de cryptomonnaies a perdu 215 000 dollars en une seule attaque MEV, un événement qui a fait grand bruit.
En résumé, cet utilisateur souhaitait échanger sur Uniswap v3 une somme de 220 800 dollars en stablecoin USDC contre une valeur équivalente en USDT. Il n’a finalement reçu que 5 272 USDT, voyant ainsi son actif s’évaporer de 215 700 dollars en quelques secondes seulement, comme illustré ci-dessous.
L’image ci-dessus montre une capture d’écran de l’enregistrement de cette transaction sur la blockchain. La cause fondamentale de ce drame est une « attaque en sandwich » (Sandwich Attack), notoire dans le monde blockchain.
C’est Michael (voir image ci-dessus) qui a révélé en premier cette attaque MEV. Il explique :
An MEV bot front-ran the tx by swapping all the USDC liquidity out. After the transaction executed, they put back the liquidity. The attacker tipped a block builder (bobTheBuilder) $200k and profited $8k from this transaction. Traduction : Un robot MEV a devancé la transaction en retirant toute la liquidité USDC. Une fois la transaction exécutée, ils ont remis la liquidité. L’attaquant a versé un pourboire de 200 000 dollars au constructeur de bloc (bobTheBuilder) et a tiré un profit de 8 000 dollars de cette transaction.
Cependant, il y a une erreur dans ce texte : le robot d’attaque MEV a retiré une grande quantité de USDT, pas de USDC.
Malgré ces explications et les reportages médiatiques, vous êtes probablement encore confus, car de nombreux termes techniques sont utilisés — comme attaque en sandwich (Sandwich Attack), devancer une transaction (front-ran the tx), remettre la liquidité (put back the liquidity), ou verser un pourboire à un constructeur de bloc (tipped a block builder).
Nous allons donc utiliser cette attaque MEV comme cas pratique pour décortiquer tout le processus et vous plonger dans cet univers obscur qu’est le MEV.
Tout d’abord, clarifions ce qu’est le MEV.
1. Qu’est-ce que le MEV ?
MEV signifie à l’origine « Miner Extractable Value » (Valeur extractible par les mineurs). Cela désigne les profits supplémentaires que les mineurs peuvent obtenir en réorganisant, insérant ou excluant des transactions dans un bloc blockchain. Ces manipulations peuvent obliger les utilisateurs ordinaires à payer un prix plus élevé ou à subir des conditions de trading défavorables.
Avec la transition d’Ethereum et d’autres réseaux blockchain du mécanisme de consensus Proof-of-Work (PoW) au Proof-of-Stake (PoS), le pouvoir de tri des transactions est passé des mineurs aux validateurs. Le terme a donc évolué de « Valeur extractible par les mineurs » (Miner Extractable Value) vers « Valeur maximale extractible » (Maximal Extractable Value).
Bien que le nom ait changé, le concept central reste inchangé : extraire de la valeur via la manipulation de l’ordre des transactions.
Ce qui précède reste assez technique. Retenez simplement ceci : le MEV existe parce que les anciens mineurs, désormais remplacés par les validateurs, ont le droit de trier les transactions présentes dans le mempool. Ce tri a lieu une fois par bloc — environ toutes les 11 secondes sur Ethereum. C’est précisément grâce à ce pouvoir de tri que l’attaque MEV en question a pu se produire.
En cliquant sur ce lien, vous verrez le contenu des transactions incluses dans le bloc numéro 22029771 lié à cette attaque, comme montré ci-dessous.
Notez bien que les transactions 1, 2 et 3 représentent l’attaque MEV mentionnée au début de cet article. Cet ordre a été fixé par le validateur (bobTheBuilder). Mais pourquoi est-ce possible ?
2. Le principe du MEV
Pour comprendre comment fonctionne le MEV, il faut d’abord saisir comment la blockchain enregistre et met à jour ses informations.
2.1 Mécanisme de mise à jour d’état de la blockchain
La blockchain peut être vue comme un grand livre comptable en constante croissance, enregistrant toutes les transactions effectuées. L’état actuel de ce registre — par exemple, le solde de chaque compte ou les réserves de jetons dans un pool Uniswap — est déterminé par l’historique des transactions précédentes.
Lorsqu’un nouveau bloc est ajouté à la chaîne, toutes les transactions qu’il contient sont exécutées séquentiellement selon leur ordre dans le bloc. Chaque transaction modifie progressivement l’état global de la blockchain.
Ainsi, non seulement l’ordre des blocs est crucial, mais aussi l’ordre des transactions au sein de chaque bloc. Comment cet ordre est-il déterminé ?
2.2 Les validateurs décident de l’ordre des transactions
Lorsqu’un utilisateur lance une transaction sur le réseau blockchain — par exemple, échanger du USDC contre du USDT via Uniswap — celle-ci est d’abord diffusée aux nœuds du réseau. Après une validation préliminaire, elle entre dans une zone appelée « mempool ». Le mempool agit comme une file d’attente où les transactions attendent d’être confirmées et intégrées dans le prochain bloc.
Dans les systèmes PoW, ce rôle incombait aux mineurs ; aujourd’hui, dans les systèmes PoS, ce sont les validateurs qui choisissent les transactions du mempool et décident de leur ordre dans le prochain bloc.
L’ordre des transactions dans un bloc est crucial. Avant qu’un bloc ne soit validé et ajouté à la blockchain, les transactions qu’il contient s’exécutent dans l’ordre défini par le validateur (comme bobTheBuilder). Ainsi, si plusieurs transactions interagissent avec le même pool, leur ordre d’exécution affectera directement leurs résultats respectifs.
Cette capacité permet aux validateurs de prioriser certaines transactions, retarder ou rejeter d’autres, voire d’insérer leurs propres transactions afin de maximiser leurs gains.
L’ordre des transactions est ici essentiel : la moindre erreur rendrait l’attaque impossible.
2.3 Ordre des transactions dans cette attaque MEV
Examinons brièvement les trois transactions liées à cette attaque MEV :
-
Transaction 1 (première transaction de l’attaquant) : Exécutée avant celle de la victime. Son objectif est généralement de faire grimper le prix du jeton que la victime souhaite acheter.
-
Transaction 2 (transaction de la victime) : Exécutée après la première transaction de l’attaquant. En raison de l’intervention précédente, le prix dans le pool est désormais désavantageux pour la victime : elle doit payer davantage de USDC pour obtenir moins de USDT.
-
Transaction 3 (deuxième transaction de l’attaquant) : Exécutée après celle de la victime. Elle permet de tirer profit des nouvelles variations de prix causées par la transaction de la victime.
Le validateur ayant orchestré cette attaque est bob-The-Builder.eth. C’est lui qui a organisé l’ordre 1, 2, 3. Bien sûr, bobTheBuilder n’a pas agi gratuitement : il a empoché plus de 100 ETH pour sa participation, tandis que l’attaquant n’a reçu que 8 000 dollars. Leur revenu provient directement de la perte de la victime lors de la transaction 2.
En résumé, l’attaquant (le robot MEV) et le validateur (bobTheBuilder) ont conspiré : la victime a perdu 215 000 dollars, dont 8 000 sont allés à l’attaquant et environ 200 000 dollars (plus de 100 ETH) au validateur.
Leur méthode porte un nom évocateur : l’« attaque en sandwich ». Voyons maintenant chaque transaction en détail pour bien comprendre ce type complexe d’attaque MEV.
3. Analyse complète de l’attaque en sandwich
On parle d’attaque en sandwich (Sandwich Attack) parce que les deux transactions de l’attaquant (transactions 1 et 3) encadrent celle de la victime (transaction 2), formant une structure similaire à un sandwich (voir illustration ci-dessus).
-
Les transactions 1 et 3 ont des rôles distincts. En bref : la transaction 1 crée les conditions du piège, la transaction 3 réalise le gain et partage le butin. Voici le déroulement précis :
-
3.1 Transaction 1 : Faire grimper le prix du USDT
-
En cliquant sur le lien de la transaction 1, vous verrez son détail. L’attaquant fait grimper le prix du USDT de manière directe : il utilise 18,65 millions de USDC pour échanger les 17,58 millions de USDT disponibles dans le pool, comme montré ci-dessous.
Après cette opération, le pool contient désormais une grande quantité de USDC et très peu de USDT. Si l’on suit les rapports, le pool Uniswap contenait initialement environ 19,8 millions de USDC et USDT. Après la transaction 1, il ne reste plus que 2,22 millions de USDT (=19,8 - 17,58) et environ 38,45 millions de USDC (=19,8 + 18,65).
Le taux d’échange entre USDC et USDT n’est plus du tout de 1:1, mais atteint environ 1:17 — autrement dit, il faut 17 USDC pour obtenir 1 USDT. Ce ratio est approximatif, car dans Uniswap V3, la liquidité n’est pas uniformément répartie.
Un point important : l’attaquant n’a pas utilisé 18,65 millions de USDC de son propre chef. En réalité, seul 1,09 million de USDC a été mobilisé — moins de 6 %. Comment est-ce possible ? Nous y reviendrons après avoir décrit toute l’attaque.
3.2 Transaction 2 : Échanger 220 000 USDC contre du USDT
En cliquant sur le lien de la transaction 2, vous obtenez l’image suivante.
Comme visible ci-dessus, la transaction 2 de la victime, influencée par la transaction 1, ne rapporte que 5 272 USDT pour 220 000 USDC, perdant ainsi inconsciemment 170 000 USDT. Pourquoi « inconsciemment » ? Parce que si la victime a utilisé l’interface Uniswap, elle a vu cet écran lors de la soumission :
Sur cette image, on voit que la victime devait recevoir au minimum 220 000 USDT. Elle n’a obtenu que 5 000 USDT à cause d’un glissement de prix (slippage) dépassant 90 %. Pourtant, Uniswap impose par défaut une limite de slippage maximal de 5,5 %, comme montré ci-dessous.
Autrement dit, si la victime avait utilisé l’interface officielle d’Uniswap, elle aurait dû recevoir au minimum 208 381 USDT (= 220 510 × 94,5 %). Vous vous demandez alors pourquoi la blockchain indique que la transaction a eu lieu sur « Uniswap V3 » ?
Parce que le frontend et le backend des transactions blockchain sont séparés. « Uniswap V3 » fait référence au pool de liquidité USDC-USDT, public et accessible à toute interface tierce.
C’est pourquoi certains soupçonnent que la victime n’était pas un utilisateur lambda, mais quelqu’un de plus sophistiqué — voire qu’il s’agissait d’un blanchiment via MEV. Nous reviendrons sur ce point plus tard.
3.3 Transaction 3 : Récolte et partage du butin
Le lien mène aux détails de la transaction 3, comme illustré ci-dessus. Décortiquons les trois sous-transactions A, B et C :
-
Transaction A : Restaurer la liquidité normale du pool, en échangeant 17,32 millions de USDT contre 18,60 millions de USDC ;
-
Transaction B : Préparer le partage, convertir une partie des gains — 204 000 USDC — en 105 ETH ;
-
Transaction C : Partager le butin, transférer 100,558 ETH au validateur bob-The-Builder.eth.
À ce stade, l’attaque en sandwich est terminée.
Répondons maintenant à une question clé soulevée plus haut : comment l’attaquant a-t-il réussi une attaque de 18 millions de USDC avec seulement 1,09 million de USDC ?
4. Comment l’attaquant a-t-il réalisé une attaque de 18 millions de USDC ?
L’attaquant a pu utiliser seulement 1,09 million de USDC pour une attaque de l’ordre de 18 millions grâce à un mécanisme particulier et puissant dans le monde blockchain : le Flash Swap (échange flash) d’Uniswap V3.
4.1 Qu’est-ce qu’un Flash Swap ?
En résumé :
Le Flash Swap permet à un utilisateur de retirer temporairement des actifs d’un pool Uniswap dans une même transaction, puis de les rembourser avec un autre actif (ou le même, plus des frais).
À condition que toute l’opération s’achève dans une seule transaction, Uniswap autorise ce mécanisme de « livraison avant paiement ». Cette règle est cruciale : l’opération entière doit se produire dans une seule transaction. Cette conception assure la sécurité d’Uniswap :
-
Prêt sans risque : Uniswap permet d’emprunter sans garantie depuis le pool, à condition de rembourser immédiatement à la fin de la transaction.
-
Atomicité (Atomicity) : L’opération entière est atomique — soit elle réussit complètement (remboursement inclus), soit elle échoue totalement (rollback de la transaction).
Le Flash Swap a été conçu pour faciliter l’arbitrage on-chain, mais il est malheureusement aussi utilisé par les attaquants MEV comme arme de manipulation de marché.
4.2 Comment le Flash Swap a-t-il facilité l’attaque ?
Voyons étape par étape comment le Flash Swap a permis cette attaque, comme illustré ci-dessous.
-
F1 : L’attaquant emprunte 1,09 million de USDC depuis Aave, en utilisant 701 WETH en garantie ;
-
F2 : L’attaquant lance un Flash Swap, retirant 17,58 millions de USDT du pool Uniswap (aucun paiement requis à ce stade) — son compte gagne temporairement 17,58 millions de USDT ;
-
F3 : L’attaquant échange rapidement ces 17,58 millions de USDT contre 17,55 millions de USDC sur Curve — son compte perd 17,58 millions de USDT et gagne 17,55 millions de USDC. Comme montré ci-dessous, Curve a été choisi pour sa haute liquidité (70,54 millions de USDT, 50,71 millions de USDC), limitant ainsi le slippage.
-
F4 : L’attaquant utilise les 17,55 millions de USDC obtenus sur Curve, ajoutés aux 1,09 million de USDC empruntés, soit 18,64 millions de USDC, pour rembourser intégralement le Flash Swap sur Uniswap. L’opération est complète.
À la fin de cette transaction (transaction 1), le compte de l’attaquant a perdu 1,09 million de USDC, car seuls 17,55 millions provenaient de Curve, le reste (1,09 million) étant son propre capital.
Vous avez remarqué : cette transaction coûte réellement 1,09 million à l’attaquant. Mais grâce à une manœuvre similaire dans la transaction 3, non seulement il récupère ses 1,09 million, mais il réalise un bénéfice supplémentaire de plus de 200 000 dollars.
Analysons maintenant la transaction 3 étape par étape.
-
K1 : L’attaquant retire 18,60 millions de USDC du pool Uniswap via Flash Swap ;
-
K2 : Il utilise 17,30 millions de ces USDC pour racheter 17,32 millions de USDT ;
-
K1 : Il rembourse les 17,32 millions de USDT à Uniswap. Le Flash Swap est complet. Notez qu’il n’a dépensé que 17,30 millions de USDC pour obtenir 17,32 millions de USDT. Sur les 130 millions restants (18,60 - 17,30), 1,09 million sont son capital initial, et les 210 000 USDC restants constituent son profit.
-
K3 : L’attaquant rembourse Aave, récupère ses 701 WETH, convertit 200 000 USDC en 105 ETH, envoie 100,558 ETH au validateur comme pourboire (environ 200 000 dollars), et garde moins de 10 000 dollars de bénéfice.
Vous vous demandez peut-être pourquoi l’attaquant accepte de donner 200 000 dollars de profit au validateur ?
4.3 Pourquoi verser un « pourboire » de 200 000 dollars ?
Ce n’est pas de la générosité, mais une condition nécessaire au succès de l’attaque en sandwich MEV.
Le cœur du succès réside dans le contrôle parfait de l’ordre des transactions, justement détenu par le validateur (bobTheBuilder).
Non seulement le validateur garantit que la transaction de la victime est bien encadrée par celles de l’attaquant, mais surtout, il empêche d’autres robots MEV concurrents d’interférer ou de griller la priorité.
Par conséquent, l’attaquant préfère sacrifier la majeure partie du profit pour assurer le succès de l’attaque, gardant juste assez pour lui-même.
Précisons également que les attaques MEV ont un coût : les frais du Flash Swap sur Uniswap, les frais de transaction sur Curve. Toutefois, ces frais sont minimes (environ 0,01 à 0,05 %) et négligeables face au profit généré.
Enfin, notez que la protection contre le MEV est simple : définissez une tolérance au slippage stricte (pas plus de 1 %) et divisez les gros échanges en plusieurs petites transactions. Inutile donc de renoncer aux DEX (bourses décentralisées) par peur du MEV.
Conclusion : Avertissement et enseignements dans la forêt sombre
Cet incident d’attaque MEV de 215 000 dollars illustre cruellement la loi de la « forêt sombre » du monde blockchain. Il révèle les jeux complexes d’exploitation des failles systémiques dans un environnement décentralisé et sans permission.
À un niveau plus élevé, le MEV incarne l’effet double tranchant de la transparence et de la programmabilité blockchain.
D’un côté, toutes les transactions étant publiques, les attaques peuvent être traquées et analysées.
De l’autre, la logique complexe des contrats intelligents et la déterminisme de l’exécution offrent des opportunités aux participants les plus astucieux.
Il ne s’agit pas simplement de piratage, mais d’une exploitation approfondie des mécanismes fondamentaux de la blockchain. Cela teste la robustesse des protocoles et met à l’épreuve la vigilance des utilisateurs.
Comprendre le MEV et ses risques permet de mieux naviguer dans ce monde numérique, plein d’opportunités mais aussi de dangers cachés.
Souvenez-vous : dans la « forêt sombre » de la blockchain, seule la crainte des règles et une connaissance approfondie peuvent vous éviter de devenir la prochaine proie.
C’est précisément l’objectif que j’ai cherché à atteindre avec cet article.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@yzdxs8
