1. Le prochain défi pour Ethereum : la centralisation

des constructeurs Ethereum est souvent considéré comme l’un des réseaux les plus décentralisés aux côtés de Bitcoin. En raison des exigences matérielles relativement faibles pour l’exploitation d’un nœud Ethereum, presque tout le monde peut exécuter un nœud. Il y a cependant une certaine redondance, le réseau se vante de plus de 1 million de validateurs.

(Part de marché des constructeurs | Source : Relayscan)

Cependant, un problème critique souvent négligé est la centralisation des constructeurs. Les constructeurs sont les entités qui rassemblent les transactions et les bundles pour créer des blocs sur le réseau Ethereum. Au cours des sept derniers jours, 95 % des blocs ont été générés par seulement trois constructeurs.

Malgré cela, Comme Vitalik Buterin l’a souligné, la centralisation des constructeurs ne constitue pas une menace sérieuse pour la sécurité globale du réseau Ethereum. En effet, même si la construction de blocs est quelque peu centralisée, les validateurs qui vérifient ces blocs restent décentralisés. Néanmoins, la centralisation des constructeurs peut entraîner divers problèmes tels que la censure, la recherche de rentes et les problèmes d’animation.

Cet article explorera le parcours des Flashbots dans la résolution des externalités négatives du MEV d’Ethereum et examinera comment SUAVE pourrait finalement résoudre les problèmes liés au MEV, y compris la centralisation des constructeurs.

2. Progrès jusqu’à présent

2.1 Preuve de travail

Avant la mise à niveau de The Merge, le réseau Ethereum fonctionnait sur PoW consensus, similaire au réseau Bitcoin, où les mineurs utilisaient du matériel pour miner des blocs. Au cours de cette période, lorsque les chercheurs ont identifié des opportunités de MEV dans le mempool, la seule façon d’inclure leurs transactions ou leurs forfaits dans un bloc était par le biais d’une enchère de gas prioritaire (PGA), où ils ont offert des frais de gaz plus élevés que les autres chercheurs.

Cette approche posait des problèmes fondamentaux. Tout d’abord, le vol de MEV était un problème. Les mineurs pourraient voir le contenu des transactions ou des liasses soumises par les chercheurs et, au lieu de les inclure dans le bloc moyennant des frais prioritaires, ils pourraient copier ces transactions et voler le MEV eux-mêmes. Ainsi, les chercheurs devaient faire confiance aux mineurs pour réaliser des profits MEV.

Le deuxième problème était la congestion du réseau. Chaque fois que des opportunités MEV se sont présentées, les chercheurs ont rivalisé en offrant des frais de priorité plus élevés, ce qui a entraîné une congestion accrue sur le réseau Ethereum. Cela a rendu les frais de transaction moyens coûteux et imprévisibles, ce qui a eu un impact négatif sur les utilisateurs réguliers.

(Vente aux enchères de flashbots | La source : Flashbots)

Pour remédier aux externalités négatives des MEV sur le réseau PoW Ethereum, Flashbots a introduit la vente aux enchères Flashbots, composée de mev-geth et mev-relay. Les éléments clés étaient : 1) la liste blanche des mineurs, 2) l’établissement d’un mempool privé et 3) la mise en œuvre d’un système d’enchères scellées.

Les utilisateurs et les chercheurs pouvaient soumettre des transactions ou des paquets au mempool privé de Flashbots Auction, qui étaient ensuite envoyés aux mineurs sur liste blanche en utilisant le client mev-geth via un relais mev centralisé. Les chercheurs ont fait des offres pour leurs lots, et les mineurs ont utilisé mev-geth pour inclure les lots les plus enchéris du bloc.

Contrairement au système précédent, les chercheurs utilisaient un mempool privé, de sorte que leurs actions n’avaient pas d’impact sur le marché Ethereum gas, et ils ne pouvaient pas voir les enchères des autres chercheurs, ce qui réduisait la concurrence. Par conséquent, Flashbots Auction a efficacement réduit la congestion sur le réseau Ethereum. Cependant, la mise sur liste blanche des mineurs était toujours nécessaire car ils pouvaient toujours voir le contenu des paquets soumis par les chercheurs.

(La source : Flashbots)

La vente aux enchères de flashbots a été largement adoptée, avec plus de 90% d’adoption de mev-geth. Cela a considérablement réduit les transactions MEV échouées et réduit les frais moyens de gaz sur le réseau Ethereum, atténuant efficacement bon nombre des externalités négatives associées au MEV.

(MEV-Boost | La source : EigenLayer) Les constructeurs de blocs reçoivent des transactions des chercheurs et des flux d’ordres privés, en utilisant leurs algorithmes d’extraction MEV pour réorganiser les transactions afin d’obtenir une rentabilité maximale. Ils créent ensuite un bloc complet et soumettent une offre au relais.Le relais vérifie la validité des blocs reçus des constructeurs et les stocke.Le relais envoie les en-têtes de bloc, ainsi que les offres, au soumissionnaire.Le proposant sélectionne l’en-tête de bloc avec l’enchère la plus élevée parmi ceux envoyés par le relais et le signe.Le relais révèle au proposant le contenu complet du bloc correspondant à l’en-tête signé.Le soumissionnaire soumet le bloc complet au réseau et recueille l’offre jointe par le constructeur de blocs. (La source : mevboost.pics) Bien qu’il s’agisse d’un middleware externe plutôt que d’un protocole intégré, MEV-Boost a été adopté avec succès par plus de 90 % des Ethereum validateurs pendant une période prolongée. Bien qu’il y ait un inconvénient à ce que les constructeurs et les promoteurs doivent faire confiance au relais, le nombre de relais est passé à huit, ce qui réduit la domination du relais Flashbots et atténue les préoccupations connexes telles que la censure. 3. Centralisation des constructeurs

3.1 Pourquoi les constructeurs tendent-à-la-centralisation

Bien que MEV-Boost ait atténué bon nombre des externalités négatives associées à la MEV, la question de la centralisation des constructeurs, mentionnée précédemment, n’est toujours pas résolue. Actuellement, environ 90% des blocs du réseau Ethereum sont créés par seulement trois à quatre constructeurs de blocs. Mais pourquoi les constructeurs de blocs ont-ils tendance à centraliser ? Il y a deux raisons principales à cela :

Flux de commandes exclusif (EOF)

Tout d’abord, le marché de la construction de blocs est fondamentalement un marché où le gagnant rafle tout. Imaginez que vous êtes un chercheur qui a identifié une opportunité d’extraction MEV et l’a regroupée. À quels constructeurs allez-vous envoyer votre lot ? Bien que vous puissiez l’envoyer à tous les constructeurs, plus vous impliquez de constructeurs, plus le risque de vol de MEV est élevé, car les constructeurs peuvent voir le contenu du bundle. Par conséquent, votre stratégie optimale serait de n’envoyer le bundle qu’aux quelques premiers constructeurs ayant la plus grande probabilité d’inclusion de bloc.

(Source : Frontier Research, juin 2023)

Le graphique ci-dessus montre que les constructeurs recevant plus d’offres groupées de la part des chercheurs ont une probabilité plus élevée d’inclusion de blocs. Ce phénomène accélère le volant d’inertie de la centralisation : si un constructeur reçoit plus de bundles de la part des chercheurs, il a plus de chances de construire des blocs plus rentables. Par conséquent, ces blocs sont plus susceptibles d’être adoptés par les proposants sur le réseau Ethereum, ce qui incite davantage de chercheurs à envoyer leurs paquets à ce constructeur. L’envoi de lots à des constructeurs moins dominants pourrait entraîner des retards dans l’inclusion des blocs, ce qui rendrait difficiles les prévisions de frais de gaz et pourrait faire perdre des opportunités d’extraction de MEV.

Au-delà de cette tendance naturelle à la centralisation, les constructeurs peuvent se procurer des transactions ou des offres groupées supplémentaires par l’intermédiaire d’EOF. Par exemple, un constructeur spécifique peut offrir des garanties de confidentialité ou une part du MEV extrait aux utilisateurs et aux chercheurs qui leur envoient des transactions ou des offres groupées exclusivement. Ce flux d’ordre supplémentaire, inaccessible aux autres constructeurs, accélère encore la centralisation des constructeurs.

En effet, comme le montre le graphique, BloXroute a un taux d’inclusion de blocs significativement plus élevé par rapport à ses pairs. En effet, BloXroute fonctionne non seulement comme un constructeur de blocs, mais également comme un service de relais, ce qui lui donne un avantage de latence dans le traitement des transactions. De plus, BloXroute fournit de l’EOF via des services tels que BackRunMe.

(MEV distribution | La source : BloXroute)

BackRunMe permet aux utilisateurs de soumettre des transactions privées, les protégeant ainsi contre les attaques malveillantes telles que les attaques front-running et les attaques sandwich. De plus, si les bénéfices MEV sont générés par le backrunning des transactions privées soumises à BackRunMe, les bénéfices sont distribués selon les ratios indiqués dans le graphique. Les utilisateurs et les chercheurs peuvent profiter de divers avantages en utilisant l’interface utilisateur d’échange de BackRunMe ou simplement en modifiant leur RPC pour soumettre des transactions.

Alors, que peuvent faire les nouveaux constructeurs de blocs ? Malheureusement, ils n’ont guère d’autres options que d’augmenter leur part de marché à perte ou d’offrir des services pour attirer les utilisateurs et l’EOF des chercheurs. La première approche, connue sous le nom de stratégie de subvention en bloc, consiste à fixer des offres plus élevées que les bénéfices MEV générés par les blocs de construction afin d’augmenter le taux d’inclusion des blocs. Par exemple, le constructeur f1b a utilisé avec succès cette stratégie pour augmenter rapidement le nombre de ses chercheurs.

MEV inter-domaines

Plus un constructeur de blocs a accès à un flux d’ordres, plus la probabilité de générer des blocs plus rentables est élevée. Si certains constructeurs de blocs créent également des blocs pour d’autres réseaux, ils peuvent accéder non seulement au flux d’ordre du réseau Ethereum, mais également au flux d’ordre externe. Cette capacité conduirait probablement à une plus grande centralisation autour de ces constructeurs.

crList, qui obligerait nativement les constructeurs à inclure toutes les transactions requises par les proposants. Cependant, il est plus difficile de s’attaquer à la recherche de rente dans un marché monopolistique et de résoudre les problèmes de vivacité dus aux temps d’arrêt. Par conséquent, la meilleure solution est d’empêcher la centralisation des constructeurs en premier lieu en atténuant ses principales causes : EOF et MEV inter-domaines. Pour résoudre ces problèmes, Flashbots a introduit le protocole SUAVE (Single Unifying Auction for Value Expression). (Il est intéressant de noter que SUAVE n’est pas la seule solution potentielle à la centralisation des constructeurs ; pour une variété d’autres solutions potentielles, voir 'Decentralizing the Builder Role'). 4. Here Comes SUAVE

4.1 TL ; DR

SUAVE se concentre sur les deux principaux facteurs contribuant à la centralisation des constructeurs : EOF et MEV inter-domaines. Tout d’abord, SUAVE peut accepter les transactions de tous les réseaux, ce qui permet aux constructeurs décentralisés d’extraire intrinsèquement des MEV inter-domaines. Deuxièmement, SUAVE optimise les conditions pour les utilisateurs en gérant les préférences de manière privée et en offrant une part des bénéfices MEV.

4.2 Vue d’ensemble

(Vue d’ensemble de SUAVE | La source : Flashbots)

SUAVE est une blockchain distincte du réseau Ethereum, offrant un mempool plug-and-play et un service de construction décentralisé qui peut être utilisé par plusieurs réseaux. Cela permet à d’autres réseaux d’externaliser les processus complexes de gestion de mempool et de construction de blocs décentralisés à SUAVE. SUAVE se compose de trois composants principaux :

Environnement de préférence universelle

Les utilisateurs et les chercheurs soumettent des transactions, des forfaits, des intentions et d’autres expressions de préférences au mempool de SUAVE, au lieu du mempool du réseau d’origine, avec leurs enchères. Dans SUAVE, ces préférences sont traitées comme un type de transaction natif. En agrégeant les préférences de différents domaines dans un seul mempool, la probabilité d’une exécution optimale augmente. Cette configuration profite aux constructeurs en abaissant les barrières à l’entrée et en augmentant les bénéfices potentiels.

Marché de l’exécution optimale

Les exécuteurs (Searchers, Builders, etc.) surveillent le mempool SUAVE et rivalisent pour créer des bundles avec les meilleures conditions d’exécution. Un concept clé introduit ici est l’enchère de flux d’ordre (OFA).

Dans le modèle traditionnel MEV-Boost, les bénéfices MEV circulent dans une seule direction des utilisateurs aux chercheurs, aux constructeurs et aux proposants. Cependant, avec OFA, les exécuteurs testamentaires se font concurrence pour les préférences des utilisateurs, ce qui permet aux utilisateurs de recevoir également une part des bénéfices MEV. Cette stratégie est similaire à des services comme BackRunMe, qui visent à attirer plus d’EOF en redistribuant une partie des bénéfices MEV aux utilisateurs et aux chercheurs. En outre, SUAVE garantit la confidentialité des préférences dans son mempool, les protégeant contre les attaques MEV malveillantes.

La différence est que, alors que de telles stratégies peuvent conduire à la centralisation de constructeurs spécifiques sur le marché actuel des constructeurs, SUAVE intègre OFA dans le protocole lui-même, donnant à tous les constructeurs décentralisés l’accès à ces préférences. Le concept d’OFA, tel que proposé par Flashbots, est déjà implémenté dans le réseau Ethereum via MEV-Share et sera ensuite incorporé dans SUAVE.

Construction de blocs décentralisés

Dans les composants précédents, la plupart des préférences trouvent leur itinéraire d’exécution optimal. Les constructeurs de blocs décentralisés utilisent ensuite ces informations pour construire des blocs partiels ou complets qui maximisent les profits MEV, qu’ils transmettent ensuite aux validateurs de divers réseaux.

Tous les validateurs d’autres réseaux n’utilisent pas SUAVE, de la même manière que tous les Ethereum validateurs n’utilisent pas MEV-Boost. Les validateurs à l’écoute de SUAVE peuvent accepter des blocs SUAVE et ajouter des blocs rentables à leur réseau. S’ils ne sont pas au courant de SUAVE, les constructeurs de blocs de SUAVE doivent participer à une vente aux enchères de gas prioritaire (PGA) pour que leurs blocs soient inclus. Une fois que les préférences sont remplies dans la chaîne de destination, un oracle informe le réseau SUAVE et l’offre est envoyée aux exécuteurs pour règlement.

4.3 MEVM

SUAVE est une blockchain qui utilise MEVM comme environnement d’exécution. Le MEVM est construit sur le framework EVM, avec des précompilations ajoutées pour les cas d’utilisation MEV. Les développeurs peuvent utiliser Solidity pour créer des applications MEV en tant que smart contracts, ce qui permet la création décentralisée d’une infrastructure liée aux MEV auparavant centralisée. Par exemple, différentes méthodes de construction de blocs ou d’enchères de flux ordre peuvent être mises en œuvre en tant que smart contracts.

Compte tenu du besoin de données et de calculs sensibles, MEVM offre également des fonctionnalités de confidentialité. Les calculs sensibles sont exécutés off-chain par des nœuds d’exécution. Dans un premier temps, les Flashbots ou des tiers fourniront cela de manière centralisée, mais finalement, ils seront exécutés dans des environnements d’exécution de confiance (TEE) comme Intel SGX.

5. Résumé et défis à venir

En résumé, SUAVE vise à collecter les transactions de tous les réseaux blockchain et à fournir les blocs avec l’exécution la plus efficace à ces réseaux. Si la vision de SUAVE est pleinement réalisée, elle permettra une véritable décentralisation du MEV, offrant les avantages suivants aux différents participants de l’écosystème blockchain :

1. Utilisateurs : Protégé contre les attaques MEV malveillantes grâce à la confidentialité et offert la meilleure exécution.
2. Constructeurs : Peuvent concurrencer équitablement les autres constructeurs en raison des transactions de confidentialité inhérentes à SUAVE et des enchères de flux d’ordre (OFA), et ont accès à des préférences inter-domaines, ce qui leur permet de construire des blocs plus rentables que lorsqu’ils opèrent dans un seul domaine.
3. Réseaux : Peut facilement externaliser le processus de construction de blocs à SUAVE.

Malgré sa vision ambitieuse, SUAVE n’en est encore qu’à ses débuts et doit faire face à plusieurs défis avant de pouvoir être pleinement réalisée.

1. Modèle de sécurité : Le modèle de sécurité de SUAVE n’est pas encore défini. Étant donné que les blocs SUAVE sont susceptibles d’être utilisés dans Ethereum et les réseaux L2 basés sur Ethereum, son niveau de sécurité devrait idéalement correspondre à celui d’Ethereum, mais y parvenir est complexe. Il y a des discussions sur la question de savoir si SUAVE devrait être construit comme un Ethereum L2 ou utiliser la sécurité crypto-économique d’EigenLayer.
2. Atomic Cross-Domain Transactions : Il s’agit non garanties. Il est difficile de traiter les transactions de manière atomique sur des réseaux avec des temps de bloc différents. Une transaction peut réussir sur un réseau à temps de bloc rapide, mais échouer sur un réseau plus lent. De plus, étant donné que tous les validateurs sur tous les réseaux ne sont pas sensibles au SUAVE, y compris les blocs via une enchère de gas prioritaire (PGA) peuvent échouer.
3. Conception de l’oracle : Une conception d’oracle sophistiquée est nécessaire pour apporter avec précision et rapidité les résultats des domaines externes dans SUAVE pour le règlement. Les oracles doivent être au moins aussi sécurisés que SUAVE, car ils peuvent devenir des vecteurs d’attaque.
4. Expérience utilisateur : Une expérience utilisateur conviviale doit être conçue pour SUAVE. Les utilisateurs doivent définir des enchères pour leurs préférences et détenir des ETH dans le réseau SUAVE. Une interface qui permet aux utilisateurs d’exprimer facilement différents types de préférences est également nécessaire.

La plus grande préoccupation est de savoir si SUAVE peut atteindre un taux d’adoption significatif similaire à mev-geth ou MEV-Boost. Pour que SUAVE puisse concrétiser sa vision, elle doit réaliser des économies d’échelle. De nombreux utilisateurs de nombreux réseaux doivent envoyer leurs préférences à SUAVE, et de nombreux constructeurs doivent participer à la création d’un système efficace. Alors que mev-geth était un client et MEV-Boost était un side-car middleware que les validateurs existants pouvaient facilement adopter, SUAVE est un réseau blockchain basé sur MEVM. Par conséquent, il reste à voir si ce grand système peut être adopté de manière significative sur de nombreux réseaux.

miroir]. Tous les droits d’auteur appartiennent à l’auteur original [00y]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.