La Maximal Extractable Value, souvent abrégée MEV, désigne la valeur additionnelle qu’un acteur peut extraire en modifiant l’ordre, l’inclusion ou l’exclusion des transactions à l’intérieur d’un bloc sur une blockchain programmable. D’abord nommée Miner Extractable Value à l’ère du proof‑of‑work, la notion s’est étendue avec le proof‑of‑stake : tout acteur qui contrôle l’assemblage ou la proposition d’un bloc (builders, proposers/validateurs, relais, bots) peut potentiellement capter de la MEV.
Origines et chronologie de la MEV
Le concept a été évoqué dès le milieu des années 2010 par des traders et chercheurs, mais c’est l’étude « Flash Boys 2.0 » (2019) qui a popularisé l’idée que l’ordre des transactions était une source de profit systématique. Des articles techniques comme « Ethereum is a Dark Forest » et « Escaping the Dark Forest » ont ensuite montré comment la visibilité des transactions dans le mempool expose les utilisateurs à des stratégies automatisées. La transition d’Ethereum vers le proof‑of‑stake a modifié les acteurs en présence, sans résoudre le phénomène : validateurs, constructeurs de blocs (builders) et relais se sont organisés pour capter la valeur, d’où l’émergence de modèles comme la Proposer/Builder Separation (PBS).
Comment la MEV est‑elle extraite ?
La MEV repose sur la possibilité de connaître ou d’influencer l’ordre d’exécution des transactions. Voici les techniques les plus répandues et leurs mécanismes.
Front‑running : prioriser une transaction
Le front‑running consiste à repérer une transaction lucrative dans le mempool (par exemple un gros swap sur un DEX) puis à soumettre une transaction concurrente avec des frais plus élevés afin d’être exécuté avant la transaction cible. Le profit provient de l’exécution prioritaire qui capture une variation de prix ou une opportunité d’arbitrage.
Attaque sandwich
Le sandwich est une forme de front‑running en deux temps : un bot place d’abord une transaction acheteuse qui pousse le prix, laisse passer la transaction cible (qui subit le slippage) puis vend immédiatement après, empochant la différence. Les utilisateurs paient le coût en slippage, et le bot capte la marge.
Back‑running et liquidations
Le back‑running intervient après une transaction identifiée comme créatrice d’opportunité (par exemple, une grosse swap ou un ajustement d’oracle). Les bots de liquidation surveillent les protocoles de prêt : lorsqu’une position devient sous‑collatéralisée, le bot exécute la liquidation et emporte la prime ou la ristourne associée.
Réorganisation et censure
Les validateurs peuvent réordonner, retarder ou même exclure certaines transactions dans le bloc qu’ils proposent. Cette capacité peut conduire à des formes de censure, soit pour des raisons commerciales (préférer des transactions plus rémunératrices), soit sous pression réglementaire ou par accords privés.
Les acteurs impliqués dans la chaîne MEV
Pour comprendre la MEV, il faut identifier les rôles qui contribuent à sa capture.
Bots et traders algorithmiques
Ils scrutent le mempool, envoient des transactions compétitives, et automatisent front‑running, sandwichs et arbitrages. Leur vitesse et l’optimisation des frais sont cruciales.
Builders (constructeurs de blocs)
Les builders agrègent des transactions dans des blocs optimisés pour la MEV et proposent ces blocs aux validateurs via des relais. Leur rôle a grandi avec l’émergence des marchés privés de blocs.
Proposers / validateurs
Ils valident et signent les blocs. En acceptant les blocs proposés par les builders, ils perçoivent une rémunération (souvent partagée) et deviennent un maillon clé de l’allocation de la MEV.
Relais et marketplaces de blocs
Les relais mettent en relation builders et proposers en organisant des enchères sur des blocs optimisés. Ils centralisent une partie de la capture et de la distribution de la MEV.
Impacts négatifs de la MEV
Si une partie de la MEV peut stabiliser l’économie des validateurs, son extraction agressive a plusieurs externalités négatives.
Augmentation du coût pour l’utilisateur
Front‑running et sandwichs augmentent le slippage, font échouer des transactions et réduisent l’efficacité des utilisateurs DeFi. Les petits acteurs paient souvent le prix fort.
Risque de centralisation
La concentration des revenus MEV entre quelques builders, relais et validateurs favorise l’émergence d’acteurs dominants ; cela réduit la diversité des fournisseurs de blocs et menace la décentralisation.
Censure et conformité imposée
Si les validateurs acceptent des exigences externes (sanctions, demandes d’autorités), la neutralité des transactions peut être remise en cause. La possibilité technique de censure rend ce risque tangible.
Course aux ressources et instabilité du mempool
La compétition entre bots provoque une « forêt sombre » dans le mempool : beaucoup de trafic machine‑to‑machine, augmentation des frais, et réduction de la lisibilité pour les utilisateurs humains.
Solutions techniques et protocolaires
La communauté développe des pistes pour réduire les externalités tout en conservant des incitations économiques.
Proposer/Builder Separation (PBS)
PBS dissocie la construction du bloc (builders) de sa proposition (proposers). L’objectif est d’éviter que les validateurs effectuent eux‑mêmes la sélection prédatrice de transactions et de rendre la compétition sur la construction des blocs plus transparente. Idéalement, PBS intégré au consensus limite les arrangements opaques.
Mempool chiffré et ordonnancement secret
Envoyer les transactions chiffrées aux validateurs ou utiliser des schémas d’ordonnancement confidentiel empêche les bots d’observer le mempool public et réduit front‑running et sandwichs.
Enchères transparentes et redistribution
Organiser des enchères sur la capture de la MEV et redistribuer une part à la communauté (par ex. via fonds communs ou réductions de frais) permet d’aligner incitations et intérêts collectifs.
Batch auctions et fair ordering
Les enchères en lots (batch auctions) regroupent les ordres sur une période de temps afin d’atténuer l’avantage de l’ordre temporel. Le fair ordering cherche à imposer des règles d’ordre équitable pour réduire l’arbitrage dérivé de la position dans la file.
Bonnes pratiques par acteur
Adopter des mesures pragmatiques peut limiter l’exposition individuelle et collective à la MEV.
Pour les développeurs de smart contracts
Concevoir des échanges et des contrats avec moins de fenêtres d’arbitrage : utiliser des oracles robustes, batcher les transactions sensibles, prévoir des marges de slippage raisonnables et simuler des attaques MEV pendant le développement.
Pour les validateurs et opérateurs
Publier la transparence des revenus MEV, choisir des relais éthiques, mettre en place des politiques anti‑censure et contribuer à des mécanismes de redistribution.
Pour les utilisateurs
Utiliser des wallets proposant protection MEV (option de soumission protégée), diviser de gros ordres, fixer des limites de slippage et privilégier des plateformes qui implémentent des protections anti‑MEV.
Cas concrets illustratifs
Rendre la MEV tangible aide à mieux évaluer les risques.
Sandwich sur un DEX
Un utilisateur place un swap important. Un bot identifie cette transaction dans le mempool et soumet une transaction acheteuse avant, puis revend après l’exécution de l’utilisateur. Le prix payé par l’utilisateur augmente, et le bot prélève la marge.
Liquidation sur un protocole de prêt
La position d’un emprunteur devient sous‑collatéralisée ; un bot exécute la liquidation, reçoit une prime, et capture la valeur récupérée. Si la compétition est faible, le profit est substantiel ; s’il y a bataille, les frais d’exécution réduisent le gain.
Cadre éthique et régulation potentielle
La MEV soulève des questions éthiques et juridiques : où commence la pratique acceptable et où commence l’abus ? Les autorités peuvent s’intéresser à des cas de manipulation ou de censure, tandis que la communauté technique travaille sur des garde‑fous.
Perspectives et recherches en cours
La recherche avance sur la cryptographie appliquée au mempool (threshold encryption), sur des modèles économiques pour une redistribution équitable, et sur l’intégration de PBS au niveau du protocole. Les solutions doivent être testées à grande échelle pour mesurer leurs effets sur sécurité, performance et décentralisation.
Recommandations pratiques et checklist
Voici des actions concrètes à mettre en œuvre selon votre rôle :
- Utilisateur : activer protections MEV, découper gros ordres, choisir DEXs résistants.
- Développeur : implémenter batch auctions, renforcer oracles, simuler attaques.
- Validateur : transparence des revenus, partenariats avec relais protecteurs, politique anti‑censure.
- Communauté : financer outils de recherche, promouvoir standards de reporting MEV.
Conclusion
La MEV est une réalité structurelle des blockchains programmables. Elle crée à la fois des incitations nécessaires pour la sécurité et des risques pour l’équité et la décentralisation. La meilleure stratégie consiste à combiner innovations protocolaires (PBS, mempool chiffré), bonnes pratiques opérationnelles et transparence économique pour minimiser les externalités négatives tout en préservant les incitations à sécuriser le réseau.
FAQ
La MEV est‑elle illégale ?
La MEV en elle‑même n’est pas illégale. Certaines pratiques peuvent relever de la manipulation de marché ou de la censure selon les lois locales et le contexte ; il convient d’évaluer au cas par cas.
La transition vers Proof‑of‑Stake a‑t‑elle supprimé la MEV ?
Non. Le passage au proof‑of‑stake a changé les acteurs (validateurs au lieu de mineurs) mais la MEV persiste tant que l’ordre d’exécution des transactions peut être influencé.
Comment se protéger en tant qu’utilisateur DeFi ?
Utilisez des wallets et DEX proposant une protection MEV, limitez le slippage, fractionnez les ordres importants et privilégiez les plateformes transparentes.
Les builders menacent‑ils la décentralisation ?
Les builders peuvent accroître la centralisation si peu d’acteurs dominent les enchères. Favoriser la concurrence entre builders et intégrer PBS au protocole sont des pistes pour limiter ce risque.
Quelles technologies combattent le front‑running ?
Parmi les solutions : mempool chiffré, threshold encryption, batch auctions, relays « protect » et mécanismes d’enchères transparents.
