La confrontation actuelle entre la consensus d'Ethereum et la MEV remonte au jour où l'on est passé de PoW à PoS...
TechFlow SélectionTechFlow Sélection
La confrontation actuelle entre la consensus d'Ethereum et la MEV remonte au jour où l'on est passé de PoW à PoS...
Il faut non seulement concevoir un mécanisme de marché pour redistribuer la MEV, mais aussi réfléchir à la manière de rendre les validateurs plus décentralisés et d'améliorer la résistance à la censure.
Dédié à des analyses Web3 approfondiesRédaction : Tia, Techub News
Le processus de résolution du problème des MEV revient en réalité à redéfinir les règles d’allocation de l’espace bloc. Si le concept de MEV ne vous est probablement plus étranger, comprendre précisément les propositions actuelles de gouvernance des MEV sur Ethereum nécessite encore quelques connaissances préalables. Cet article présente ainsi une série de propositions post-PoS concernant la gouvernance des MEV sur Ethereum — PBS, ePBS et PEPC — afin d’offrir un contexte utile.
PBS (Proposer-Builder Separation)
Avant la fusion ("merge") d’Ethereum, la gestion des MEV s’appuyait sur MEV-Geth, un client go-ethereum modifié développé par Flashbots. L'idée centrale était de permettre aux mineurs de se concentrer sur leur tâche principale — miner — plutôt que de participer activement à la capture des MEV, évitant ainsi d’éventuels problèmes de réorganisation. Le mécanisme de MEV-Geth était simple : il s’agissait d’une solution de marché où les mineurs choisissaient quels bundles soumis par les "searchers" inclure dans un bloc selon la rentabilité offerte. Grâce à ce mécanisme marchand bien conçu, tous les acteurs retiraient des bénéfices tout en étant partiellement contraints. Bien que les searchers doivent céder une partie de leurs profits aux mineurs, ils obtiennent en contrepartie une sécurité accrue contre le vol de leurs opportunités de MEV. En encadrant cette source majeure de profit pour les searchers, les mineurs étaient progressivement incités à adopter MEV-Geth, eux-mêmes devenant alors soumis à ses règles. MEV-Geth maintenait une liste blanche de mineurs autorisés à recevoir les bundles ; tout mineur tentant de voler les résultats d’un searcher était exclu de cette liste, ce qui constituait une forme de sanction par réputation.
Cependant, après la fusion, le passage à un système de sélection aléatoire de validateurs comme "proposer" rendait inopérante la contrainte fondée sur la réputation pour empêcher les proposers de s'approprier les MEV.
Une solution envisageable consiste à rendre le contenu du bloc invisible pour le proposer. Cette idée a été approfondie et formalisée sous la forme du PBS (Proposer-Builder Separation), ou séparation entre proposer et builder. Le PBS décompose davantage les responsabilités du proposer — désormais issu du groupe des validateurs — en deux fonctions distinctes : construction du bloc (build) et proposition du bloc (propose). La tâche complexe de construction, potentiellement impliquée dans des conflits d’intérêts, est externalisée vers des entités spécialisées appelées builders. Ainsi, le rôle du proposer devient très simple : il choisit simplement quel bloc proposer en fonction du profit offert par chaque builder.
Initialement, Ethereum avait prévu d’intégrer nativement le PBS au protocole lors du merge, mais en raison de sa complexité potentielle, ce plan fut mis en suspens, ouvrant la voie à MEV-Boost de Flashbots. Actuellement, le PBS est implémenté via MEV-Boost. Outre le builder et le proposer, un troisième acteur joue un rôle crucial : le relay (relais). Le builder n'envoie pas directement le bloc au proposer, mais passe par ce relais intermédiaire.
D'autres problèmes doivent également être résolus, tels que garantir que le builder paiera effectivement le proposer, ou qu’il divulguera bien le contenu complet du bloc au proposer afin d’éviter toute pénalité liée à la soumission d’un bloc vide. Il faut aussi assurer que le bloc soumis par le builder sera bien intégré à la chaîne beacon. Ces garanties pour les droits du builder et du proposer sont principalement assurées par le relais.
Le builder envoie son bloc au relais, qui trie les blocs reçus selon leur profit potentiel, puis transmet uniquement l’en-tête du bloc le plus rentable au proposer, garantissant ainsi que le proposer ne voit pas le contenu complet du bloc. Une fois que le proposer a signé cet en-tête (exprimant ainsi son engagement), le relais lui révèle alors le bloc complet. Le paiement du builder au proposer passe également par le relais, qui agit comme garant. Ce paiement prend la forme d'une transaction incluse dans le bloc, mais comme le proposer ne peut pas voir le contenu du bloc, c’est le relais qui doit s’assurer préalablement que la transaction est bien incluse.
In-protocol vs out-of-protocol
Pour participer au marché construit par MEV-Boost, les validateurs doivent exécuter, en plus des clients de consensus et d’exécution d’Ethereum, un programme tiers externe à Ethereum : MEV-Boost. C’est là tout l’étonnement suscité par le PBS tel qu’il fonctionne aujourd’hui : un acteur extérieur au protocole participe activement à la formation du consensus. D’un point de vue de propriété, cela paraît inconcevable.
Cela soulève également des questions sur la « crédibilité » des mécanismes protocolaires : comment celle-ci est-elle renforcée, et comment peut-elle être affaiblie par d’autres mécanismes ? MEV-Boost en est un excellent exemple, car il illustre une situation où un protocole externe peut modifier les mécanismes existants. Lorsque le protocole principal tarde à évoluer, ces changements peuvent émerger de l’extérieur. Ces mécanismes externes répondent souvent à une demande du marché, mais leur fiabilité, leur conception rigoureuse face aux risques potentiels, voire leur capacité à nuire au protocole, restent des inconnues.
Le problème de centralisation des relais
La critique la plus fréquente adressée à MEV-Boost concerne la centralisation du marché des relais. Ce modèle introduit des problèmes de confiance. Les builders doivent faire confiance au relais pour ne pas voler leurs MEV. Les proposers doivent croire que les en-têtes de bloc qu’ils reçoivent et signent via le relais sont valides. Pourtant, malgré leur rôle essentiel, les relais n’ont aucun incitatif économique direct, et leur fonctionnement entraîne des coûts non négligeables. L’année dernière, 11 relais soutenaient le réseau Ethereum ; aujourd’hui, ils ne sont plus que 9.
Il convient de noter que l’accès aux relais n’est pas libre. Certains, comme Eden, ne relaient que les blocs de leurs propres builders. D’autres, comme bloXroute, affirment filtrer les transactions liées aux attaques front-running ou sandwich. Dans une certaine mesure, les relais détiennent donc un pouvoir de régulation.
Données provenant de Rated Network
De plus, du point de vue de la disponibilité ("liveness"), l’intermédiation du relais empêche une confirmation atomique entre builder et proposer. Si le proposer signe l’en-tête du bloc et que le builder fournit bien le payload, mais que le relais — qu’il soit malveillant ou non — ne transmet pas correctement le contenu à temps, cela peut entraîner des pertes pour les deux parties.
ePBS : intégrer le PBS dans le protocole Ethereum
Que ce soit pour résoudre la centralisation des relais ou pour ramener des composants externes dans le protocole, l’intégration du PBS au sein d’Ethereum via ePBS semble devenue incontournable. ePBS n’est plus seulement une proposition théorique : l’éditeur des EIP d’Ethereum lui a déjà attribué un numéro officiel — EIP-7732.
ePBS fournit une infrastructure fiable aux proposers et builders pour externaliser la construction des blocs. Le rôle du builder, auparavant externe au protocole, est désormais intégré : une nouvelle catégorie de validateurs, les builders, est créée, et ces derniers doivent également effectuer un stake sur Ethereum. Comme ePBS modifie la répartition des rôles au niveau de la couche de consensus (le proposer initial étant scindé), cela nécessite une mise à jour de cette couche. Le builder est chargé de construire le payload d’exécution (la liste finale des transactions à exécuter dans le bloc), tandis que le proposer se contente de proposer le bloc beacon. Le processus se déroule comme suit :
-
Une fois désigné comme Proposer, celui-ci crée et diffuse une Inclusion List (IL), indiquant les transactions qui doivent obligatoirement être incluses durant ce slot.
-
Les builders envoient au proposer un « SignedExecutionPayloadHeader », contenant le hachage du bloc avec le payload d’exécution et leur promesse de paiement, en veillant à ce que le payload respecte l’IL.
-
Le proposer sélectionne l’un des « SignedExecutionPayloadHeader » reçus (généralement celui offrant le paiement le plus élevé) et diffuse le bloc beacon signé (« SignedBeaconBlock »).
-
Les validateurs remplissent leur rôle de témoins (attesters).
-
Les agrégateurs soumettent leurs agrégats d’attestations ; simultanément, le builder diffuse le payload d’exécution.
-
Un comité nommé PTC (Payload Timeliness Committee) — composé de 512 validateurs tirés au sort chaque slot — vérifie si le builder a bien révélé le payload à temps, et diffuse le résultat de cette vérification.
Entre sa proposition initiale et l’attribution d’un numéro EIP, ePBS a fait l’objet de multiples discussions. Initialement proposé par Vitalik en juin 2021, le concept a été affiné quatre mois plus tard avec la version Two-slot, puis trois mois après avec le Single-slot PBS. Ce n’est qu’en juillet 2023 que l’idée du PTC a été formellement introduite.
PEPC (Protocol-Enforced Proposer Commitments)
Certains, toutefois, s’opposent à ePBS et préconisent d’autres solutions. C’est le cas de PEPC. Alors qu’ePBS intègre une règle fixe dans le protocole, PEPC propose une approche différente : le proposer vend un droit de construction de bloc programmable.
Proposé par barnabe en octobre 2022, PEPC repose sur l’idée que si le mécanisme PBS doit être intégré au protocole, il vaut mieux concevoir un mécanisme général de transmission de signaux fiables, plutôt qu’un mécanisme spécifique (par exemple : « si tu me laisses construire le bloc, je te rendrai X ETH »).
Comme son nom l’indique (Protocol-Enforced Proposer Commitments), certains mécanismes destinés à protéger les droits du builder et du proposer reposent sur des engagements ("commitments") faits par le proposer au sein du protocole, engagements vérifiables sur la chaîne grâce à l’opcode « BEACONROOT ». Il s’agit d’un mécanisme plus universel : l’engagement peut consister à externaliser la totalité de la construction du bloc, ou seulement une partie. Autrement dit, le proposer vend un droit de construction de bloc paramétrable.
Conclusion
Voici un aperçu succinct de PBS, ePBS et PEPC. Du point de vue de la conception protocolaire, il ne s’agit pas seulement de concevoir un nouveau mécanisme de marché pour redistribuer les MEV, mais aussi de s’assurer que les validateurs restent décentralisés et que la résistance à la censure soit renforcée. De nombreux compromis entrent en jeu. Prenons l’exemple d’ePBS, désormais doté d’un numéro EIP. Bien qu’il résolve efficacement le problème de centralisation des relais, peut-on vraiment dire que le rôle des relais tiers, bien qu’externe au protocole, n’a que des effets négatifs ? En matière de mécanisme de paiement du builder, par exemple, l’utilisation d’un relais s’avère même supérieure à ePBS : dans ePBS, le paiement est prépayé, ce qui signifie qu’un builder ayant construit un bloc extrêmement lucratif ne peut pas offrir une récompense élevée au proposer, contrairement à un système où le paiement est effectué via le bloc lui-même.
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
@News_Techub
