De proposeurs centralisés à une architecture modulaire de builders
Traditionnellement, les proposeurs de blocs mineurs en preuve de travail ou validateurs en preuve d’enjeu avaient un contrôle total sur les transactions incluses dans un bloc et sur leur ordre. Cela leur conférait un avantage considérable, leur permettant d’extraire directement de la MEV ou de déléguer ce droit à des tiers. La fusion d’Ethereum et son passage à la preuve d’enjeu ont ouvert une nouvelle voie : dissocier la proposition de blocs de leur construction.
Flashbots a introduit ce concept avec MEV-Boost, un middleware permettant aux validateurs de déléguer la construction des blocs à un marché ouvert de builders. Au lieu de construire eux-mêmes les blocs, les validateurs recevaient des blocs préconstruits de différents builders en concurrence et sélectionnaient celui proposant la meilleure offre. Ce système incitait les builders à rivaliser pour obtenir le flux d’ordres en construisant le bloc le plus rentable possible et en partageant la récompense avec le validateur.
Cette séparation a permis de mettre en place une architecture de consensus plus modulaire. Elle a réduit le contrôle monopolistique des validateurs sur l’ordonnancement des transactions et a permis à de nouveaux acteurs, tels que les searchers, les builders et les relais, de participer à la production de blocs. Elle a également apporté plus de transparence sur le processus d’extraction de la MEV et favorisé l’émergence de standards et de pratiques éthiques.
Le rôle des searchers, des builders et des relais
Avec MEV-Boost, la chaîne d’approvisionnement de la MEV est devenue plus structurée. À la base se trouvent les searchers, des acteurs spécialisés qui analysent le mempool, détectent les opportunités de MEV et créent des lots de transactions. Ces lots sont envoyés aux builders, qui les intègrent dans des blocs avec des transactions classiques d’utilisateurs et des stratégies de remplissage afin de maximiser la rentabilité. Les builders soumettent ensuite leurs blocs aux validateurs via les relais.
Les relais agissent comme des intermédiaires : ils vérifient que les blocs respectent les règles du protocole et que les paiements promis seront bien versés aux validateurs. Ils jouent ainsi un rôle de garant de la confiance, notamment lorsque certains builders pourraient ne pas honorer leurs engagements de paiement. Toutefois, leur existence introduit aussi un risque de centralisation, car seuls quelques relais opèrent à grande échelle et contrôlent une part importante de l’activité des validateurs.
Cette chaîne d’approvisionnement a permis plus de transparence et de spécialisation, mais elle a aussi fait apparaître de nouveaux points de blocage et des dépendances en matière de confiance. Les builders ont progressivement gagné de l’influence sur le choix des lots de transactions soumis par les searchers. Les relais pouvaient censurer certains blocs ou tomber hors ligne. Quant aux validateurs, bien qu’écartés de l’extraction directe de MEV, ils restaient incités à nouer des accords avec des builders « de confiance » pour garantir des revenus réguliers. Ces tensions ont montré que si MEV-Boost atténuait certains problèmes, il ne changeait pas fondamentalement les règles du jeu — il ne faisait que les redistribuer.
Les limites de MEV-Boost et du flux d’ordres privé
MEV-Boost a montré que la construction concurrentielle de blocs pouvait réduire la centralisation du pouvoir chez les validateurs, mais il a aussi mis en lumière de nouveaux problèmes. Les builders ont commencé à concentrer des parts de marché, entraînant une domination des builders plutôt que des validateurs. Certains builders remportaient systématiquement les blocs les plus rentables tandis que d’autres restaient à la traîne, ce qui a réduit la décentralisation pourtant théorique du marché des builders.
De plus, MEV-Boost reposait toujours sur un mempool public, ce qui signifiait que la plupart des transactions des utilisateurs restaient visibles et vulnérables avant leur inclusion dans un bloc. Certains utilisateurs et protocoles ont donc cherché à soumettre leurs transactions de manière privée. Des projets comme Eden Network et Taichi ont proposé des canaux protégés permettant de contourner le mempool public et d’envoyer les transactions directement aux builders ou aux validateurs.
Ces solutions ont introduit de nouveaux compromis. Bien qu’elles réduisent l’exposition aux attaques de frontrunning et de type sandwich, elles nécessitaient souvent de faire confiance à des opérateurs centralisés et pouvaient facturer des frais pour cette protection. Elles rompaient également la composabilité : les transactions soumises de manière privée ne pouvaient plus interagir de façon prévisible avec celles du mempool public. En somme, ces mécanismes protégeaient les utilisateurs, mais au prix de la transparence et de la coordination au niveau du protocole.
Les mempools privés, comme ceux développés par Shutter Network ou Gnosis Chain, sont allés plus loin en chiffrant les transactions jusqu’à leur inclusion dans un bloc. Cette approche retardait la visibilité des transactions, réduisant ainsi les opportunités de MEV, mais nécessitait une coordination complexe et introduisait de la latence. En outre, les mempools chiffrés limitaient l’utilisabilité des applications reposant sur une estimation en temps réel de l’état du réseau, comme les bots d’arbitrage ou les gestionnaires de portefeuille.
L’essor des enchères de flux d’ordres (OFA)
Une avancée plus prometteuse est apparue avec l’essor des enchères de flux d’ordres (OFA). Dans ce modèle, les transactions des utilisateurs ne sont plus simplement diffusées dans le mempool ni envoyées à des points d’accès privés. À la place, les utilisateurs — ou les portefeuilles agissant en leur nom — vendent le droit d’inclure leurs transactions via un mécanisme d’enchères. Les builders ou solvers se disputent ce droit d’exécution, et l’utilisateur reçoit une partie de la valeur MEV qui lui aurait autrement été extraite.
Cette approche fait passer la logique de l’extraction de MEV à son partage. Elle reconnaît que les transactions des utilisateurs ont une valeur et que celle-ci mérite une compensation équitable. Des projets comme CowSwap et MEV-Share (un prototype de Flashbots) permettent aux utilisateurs d’exprimer leur intention de transaction et de recevoir en échange un devis ou un remboursement partiel. Ce mécanisme repose sur des environnements d’exécution sans confiance, des engagements cryptographiques et des enchères scellées pour empêcher le frontrunning.
Les enchères de flux d’ordres instaurent également un marché programmable pour l’inclusion des transactions. Au lieu de s’appuyer sur une protection centralisée, elles offrent aux utilisateurs un moyen ouvert et transparent de soumettre leurs transactions tout en garantissant une exécution équitable. Elles favorisent la concurrence entre solvers et builders, tout en alignant les incitations des utilisateurs et des fournisseurs d’infrastructure.
Cependant, les OFA en sont encore à leurs débuts. Ils nécessitent une intégration au niveau des portefeuilles, une standardisation entre les différentes blockchains et une conception cryptographique robuste. De plus, une adoption à grande échelle suppose que les utilisateurs comprennent les avantages de la vente de leur flux d’ordres et que les protocoles puissent acheminer les transactions de manière sécurisée via des couches d’enchères sans altérer les fonctionnalités existantes.
Pourquoi ces mesures de protection sont insuffisantes
Malgré les avancées réalisées, les premiers outils d’atténuation du MEV et les OFA ne permettent pas d’atteindre une résistance complète au MEV. MEV-Boost traite une couche du problème, mais en ignore d’autres. Les transactions privées offrent une protection limitée et locale, mais elles sont peu évolutives et n’assurent pas un accès universel. Quant aux enchères de flux d’ordres, elles montrent un certain potentiel, mais restent fragmentées et non interopérables.
Ce que toutes ces approches n’offrent pas, c’est une infrastructure unifiée, décentralisée et programmable capable de servir de couche d’exécution pour les applications sensibles au MEV entre différentes chaînes. Un système alliant propagation chiffrée des transactions, enchères équitables et logique d’exécution programmable, tout en garantissant la composabilité, des délais prévisibles et le contrôle par l’utilisateur.
Cette prise de conscience a conduit au développement de SUAVE, une architecture ambitieuse conçue pour absorber, décentraliser et repenser la couche de flux d’ordres. SUAVE ne cherche pas à colmater l’extraction de MEV ; il propose de reconstruire l’infrastructure même qui la rend possible.
