Commençons par une définition de l'acronyme MEV :

Valeur extractible maximale: Le montant maximum de valeur qu'un agent peut extraire en incluant, excluant ou modifiant l'ordre des transactions pendant le processus de production de blocs

Pour être plus clair, le concept de la Valeur Extractible par le Mineur (MEV) fait référence à un scénario dans lequel un agent examine la transaction récente d'un utilisateur, élabore une stratégie pour en tirer profit, et met ensuite en œuvre cette stratégie pour saisir tout gain potentiel.

Merci d’avoir lu Crypto-monnaie et amis ! Abonnez-vous gratuitement pour recevoir de nouveaux articles et soutenir mon travail.

S'abonner

Plus souvent qu'autrement, un agent qui capture avec succès MEV le fera aux dépens d'une autre partie. Il peut s'agir de l'utilisateur émettant une transaction ou d'un agent passif dans un protocole DeFi.

Le simple fait de gagner de l'argent en intervenant dans l'exécution d'une transaction en attente a des ramifications énormes pour les utilisateurs, les protocoles DeFi et le réseau blockchain sous-jacent.

Nous présenterons quelques informations de base sur MEV avant d'entrer dans la discussion principale — quelle est la moralité de MEV ? Dans le contexte des agents qui exploitent MEV et des acteurs qui tentent de s'en défendre.

Agents au sein du jeu MEV

En plus des utilisateurs cherchant à interagir avec un smart contract, il existe deux autres rôles cruciaux profondément liés au concept de MEV:

• Chercheur. Un agent qui trouve une opportunité de tirer profit de la transaction d’un utilisateur, crée un paquet de transactions pour l’exploiter et propose le paquet au proposant.
• Proposant. Un agent ayant le pouvoir de décider de l'ordre des transactions.

Un chercheur peut être une entreprise de trading avec une expertise étendue ou un amateur codant dans sa chambre.

Être un chercheur est un rôle sans permission.

Le seul obstacle est la capacité du chercheur à trouver alpha, à construire un bot MEV compétitif et à exploiter les opportunités. L'accès au capital aide, mais ce n'est pas encore un obstacle significatif.

En revanche, un proposant détient le pouvoir de déterminer la séquence des transactions et, par conséquent, le résultat de leur exécution. Ce rôle pivot peut être rempli par diverses entités, y compris les Mineurs (dans les systèmes de preuve de travail), les Enjeuteurs (dans les systèmes de preuve d'enjeu) ou les Séquenceurs (dans les rollups).

Bien que le groupe de proposants soit généralement restreint, il peut être en accès libre.

Il existe des raisons convaincantes de limiter qui peut assumer le rôle de proposant :

1. Protocole de consensus : De nombreux systèmes blockchain nécessitent la participation des proposants dans un protocole basé sur des rounds, exigeant la coopération d'une majorité (ou une supermajorité) d'entre eux à chaque round. Coordonner la communication entre tous les N participants s'avère souvent être un goulot d'étranglement.
2. Routage des transactions: Les utilisateurs doivent disposer d'un moyen fiable pour transmettre leurs transactions au proposant. Cela peut être réalisé en transférant les transactions à un pool de mémoire public ou directement au proposant désigné.
3. Intégrité vérifiable : La communauté élargie peut chercher une mesure objective pour vérifier que tous les proposants travaillent ensemble comme un collectif pour décider de l'ordre des transactions et qu'ils étendent toujours le dernier ordre. Par exemple, le réseau peut mettre en œuvre une règle de choix de fourche où un proposant construit sur le dessus de la chaîne la plus lourde (enjeu/travail).
4. Risque de MEV : Dans certains systèmes blockchain, en particulier la plupart des rollups aujourd'hui, les proposants sont chargés de la responsabilité de ne pas exploiter les opportunités de MEV. Il est donc crucial pour la communauté d'avoir l'autorité de décider en qui elle a confiance.

En termes plus simples, il doit exister un mécanisme permettant à un utilisateur de vérifier, de manière indépendante, si un proposant détient l'autorité de décider de l'ordonnancement des transactions récentes. Sans cette assurance, des acteurs malveillants pourraient inonder le système avec de faux ordonnancements de transactions, laissant les utilisateurs incapables de discerner la vérité.

Pour simplifier l'explication des agents, nous incorporons le rôle d'un constructeur dans le proposant, et supposons qu'un proposant construira à la fois un bloc et aura l'autorité de le publier.

Interaction et relation des agents

Quelle est l'interaction entre le chercheur et le proposant?

Un grand focus de la recherche sur MEV est de comprendre l'interaction entre les chercheurs et les proposants. De plus, il est essentiel d'établir si ces rôles peuvent être remplis par la même entité ou s'ils nécessitent des agents distincts:

• Même agent. Le chercheur peut être un proposant dans le système,
• Agents séparés. Il y a un (ou plusieurs) chercheurs qui ne sont pas des proposants et ils sont tous en concurrence pour influencer le proposant.

En d'autres termes, il est important d'identifier si un chercheur peut avoir un contrôle total et incontesté de la politique de commande des transactions. Si le chercheur est également le proposeur, il peut potentiellement accorder au chercheur un pouvoir supplémentaire pour observer les tactiques employées par d'autres chercheurs, leur permettant potentiellement de voler des opportunités à des chercheurs plus compétitifs.

D'autre part, si les chercheurs ne peuvent pas être des proposants ou colluder avec les proposants, alors cela nous permet de supposer un environnement où les chercheurs doivent rivaliser les uns contre les autres. Leur objectif est d'influencer le proposant et de le persuader de classer une liste de transactions selon la préférence du chercheur gagnant.

Externalisation vs Monopole dans la Maximisation des Profits de MEV : Il y a un débat intéressant pour savoir s'il est plus lucratif pour un proposant de sous-traiter la tâche d'identification et de valorisation de MEV à un marché ouvert de chercheurs ou s'ils devraient plutôt chercher à consolider l'opportunité par une approche monopolistique.

Nous supposerons qu'un proposant agira en tant que partie honnête et respectera sa politique de commande de transaction promise. De plus, que les chercheurs et les proposants sont toujours des agents séparés.

Notre objectif est de comprendre la stratégie utilisée par un chercheur pour influencer la politique de classement d'un proposant et espérons battre tous les autres concurrents à la même opportunité.

Politique de commande de transaction

La poursuite et la défense de MEV se concentrent sur la capacité du chercheur à influencer un seul composant du système de la blockchain :

• La politique de commande de transaction. Étant donné une liste de transactions d'utilisateurs en attente, quel algorithme de tri est appliqué pour produire la liste finale des transactions ordonnées (c'est-à-dire un bloc confirmé).

Un système de blockchain peut mettre en œuvre une variété de politiques de commande et son objectif est d'offrir une équité à tous les utilisateurs qui souhaitent transiger.

Cela suscite la question : Quelle est la définition de l'équité ?

• Les utilisateurs doivent-ils tous payer les mêmes frais et les transactions sont-elles classées selon le principe du premier arrivé, premier servi ?
• Les utilisateurs doivent-ils payer des frais en fonction de la priorité de la transaction et toutes les transactions sont-elles classées en fonction des frais payés ?

Les deux cas suivent le principe général selon lequel un utilisateur peut effectuer une transaction tant qu'il a la capacité de payer. Cela ne dicte pas que la transaction de l'utilisateur aura une position promise dans l'ordre total, seulement qu'elle sera éventuellement ordonnée pour exécution de manière opportune.

Ce concept d'équité, qui est à la base de la raison pour laquelle un réseau blockchain est résistant à la censure, est intéressant.

Il souligne que la capacité d'un utilisateur à effectuer une transaction ne devrait dépendre que de sa capacité à payer, et qu'il ne devrait pas être discriminé en fonction de son lieu géographique, de son identité, de son genre ou de son système de croyances. Il provient du domaine du Bitcoin et peut facilement être appliqué car le réseau ne prend en charge que les paiements.

Cependant, la capacité de garantir l'inclusion d'une transaction est insuffisante lorsque nous essayons de comprendre l'équité au sein d'un système activé par contrat intelligent. Pour un réseau comme Ethereum, nous devons élargir la portée de l'équité au-delà de l'inclusion de transactions dans l'ordre mondial. Il devrait également tenir compte de l'intention d'un utilisateur qui a signé la transaction et que le résultat souhaité de l'utilisateur a été atteint après l'exécution de la transaction.

Reconnaître le rôle vital de l'intention de l'utilisateur dans l'équité. Les utilisateurs évaluent l'équité, non seulement sur la capacité d'inclure une transaction en temps opportun, mais en évaluant le résultat réel de leur transaction et en vérifiant s'il correspond à leurs attentes initiales lorsqu'ils ont signé la transaction.

Cela peut conduire à une nouvelle et intéressante définition de ce que nous entendons par résistance à la censure :

• Faible résistance à la censure. Un utilisateur peut toujours commander une transaction pour exécution tant qu'il est prêt à payer les frais appropriés pour cela.
• Une forte résistance à la censure. Un utilisateur peut forcer le résultat souhaité de sa transaction et il lui suffit de payer des frais appropriés.

Gardez ceci à l'esprit, car cela deviendra important lorsque nous comprendrons comment MEV peut être utilisé pour interférer avec la transaction d'un utilisateur et la forcer à échouer à son exécution. Ainsi, même si la transaction d'un utilisateur peut être incluse de force dans l'ordre total, le résultat souhaité de l'utilisateur (intention) ne peut pas être atteint.

Il apparaît, à notre connaissance, qu'une politique de commande doit empêcher les chercheurs d'avoir la capacité d'interférer sélectivement avec la transaction d'un utilisateur, si nous voulons construire un système résistant à la censure. Il s'agit d'un problème de recherche ouvert.

L'activation de Sanctions de l'OFAC via Relaysteste activement si un réseau blockchain peut continuer à traiter équitablement les utilisateurs en fonction de leur capacité à payer pour l'inclusion des transactions.

Activation de MEV

Pour approfondir les aspects techniques de la Valeur Extractible par les Mineurs (MEV), nous devons examiner ce qui suit :

1. Identifier les opportunités de MEV: Comprendre comment un chercheur peut découvrir la transaction récente d'un utilisateur dans le système blockchain.
2. Environnement d'exécution: Examen de l'environnement technique dans lequel toutes les transactions sont exécutées.
3. Stratégies d'exploitation: Investigation des diverses stratégies qu'un chercheur peut employer pour exploiter les opportunités MEV, telles que le réordonnancement des transactions, le front-running et l'arbitrage.
4. Influencer l'ordre : Explorer comment un chercheur peut influencer le proposant pour prioriser l'inclusion de leurs transactions liées à la MEV.

Une fois que nous aurons acquis une compréhension solide de ces composants fondamentaux, nous pourrons procéder à l'évaluation des implications éthiques et des considérations morales entourant MEV.

Localisation des opportunités MEV

Un chercheur a besoin d'accéder aux transactions d'utilisateurs récentes pour trouver de nouvelles opportunités MEV et de profit.

Il existe deux approches pour trouver des transactions :

• Protocole de potin. Un utilisateur soumet sa transaction au réseau pair à pair et la transaction est propagée à tous les nœuds dans un laps de temps très rapide (<1 seconde).
• Flux de proposant. Le proposant publie des transactions en attente et/ou récemment ordonnées.

La majorité des utilisateurs envoient leurs transactions sur le protocole de potin dans l'espoir qu'un proposant découvrira leur transaction et l'inclura dans son bloc. En même temps, n'importe qui, y compris les chercheurs, peut rejoindre le protocole de potin et écouter les transactions en attente.

Cela a conduit à des 'Forêt sombre'surnom car il est presque garanti qu'un chercheur trouvera la transaction d'un utilisateur et interférera avec son exécution s'il y a une opportunité de gagner de l'argent. Par exemple, dans le post de Dark Forest, les auteurs n'ont pas réussi à récupérer les fonds en danger car un chercheur a découvert leur transaction, l'a évaluée et a collecté les fonds pour eux-mêmes.

À ce jour, le seul moyen de vaincre la forêt sombre est d'éviter d'envoyer une transaction sur le réseau pair à pair. Dans un post ultérieur, les auteurs Échappé à la forêt sombreen envoyant leur transaction directement à un mineur Ethereum. Cela, ainsi que d'autres cas, a finalement conduit à l'offre Flashbot d'une fonction de transaction directe qui permet à un utilisateur d'envoyer sa transaction directement à un mineur de confiance (en tant que service).

Il existe encore un risque que les robots MEV puissent exploiter une transaction directe si la blockchain subit une réorganisation et que la transaction de l'utilisateur est temporairement non confirmée et placée dans le pool de mémoire. Cependant, les événements de réorganisation sont relativement rares dans Ethereum de preuve d'enjeu par rapport à 7% de tous les blocs dans Ethereum de preuve de travail.

Le même risque ne s'applique pas aux rollups (tels qu'ils sont implémentés aujourd'hui). Presque toutes les transactions sont des transactions directes car les utilisateurs ont une connexion de communication directe avec le Proposer (Séquenceur). Il y a peu ou pas du tout d'opportunité pour un chercheur d'écouter le canal et cela augmente significativement la difficulté à exploiter les opportunités de MEV pour les transactions en attente.

Cela a conduit à une perception selon laquelle les rollups ont battu les chercheurs. Jusqu'à présent, tout succès a dépendu de la fiabilité des proposants pour ne pas exploiter MEV à leur avantage. Bien sûr, ce n'est pas toute l'histoire, et les chercheurs peuvent toujours trouver des opportunités MEV.

Dans les rollups, grâce aux transactions directes, les chercheurs ont déplacé leur attention vers la localisation des transactions récemment confirmées dans l'espoir de trouver des opportunités similaires à l'arbitrage.

Par exemple, dans Arbitrum, le Proposer maintient un flux qui publie les transactions récemment ordonnées. Il est publié toutes les 250 millisecondes, principalement pour aider les fournisseurs d'infrastructure tels qu'Infura et Etherscan à obtenir les données les plus à jour. Cela permet à un utilisateur d'envoyer une transaction au Séquenceur puis de vérifier son état sur Etherscan. De plus, cela permet à quiconque d'exécuter un nœud Arbitrum avec l'état confirmé du Séquenceur.

Regrettably, les bots MEV ont découvert ce flux. Un chercheur se connectera au flux et exploitera des opportunités similaires à l'arbitrage à partir des transactions récemment ordonnées.

Toute information sur les transactions peut permettre MEV. La plupart des discours sur MEV se concentrent sur la capacité des chercheurs à localiser et à interférer avec l'exécution des transactions en attente. Cependant, même si le Proposer est entièrement digne de confiance et n'autorise pas les chercheurs à localiser les transactions en attente, il existe toujours la possibilité pour les chercheurs d'utiliser toute information mise à disposition par le Proposer.

État partagé de la base de données

L'exécution finale d'une transaction peut être différente de l'exécution attendue au moment de la signature de la transaction.

Chaque système blockchain fonctionne comme une machine à états finiset dans ce contexte, il y a une fonction de transition d'état (STF) qui prend :

• Dernier état de la base de données,
• Entrée de l'utilisateur.

À l'exécution, le STF produira un nouvel état de la base de données. Nous pouvons le résumer comme suit :

• STF(database_state, entrée de l'utilisateur) = nouvel_état_de_la_base_de_données

Lorsqu'un utilisateur initie une transaction, il cible une fonction de transition d'état spécifique avec son entrée. Il est important de noter que la transaction ne se conforme pas à l'état actuel de la base de données; l'état le plus récent de la base de données n'est connu que lorsque l'exécution se produit.

Dans un système de blockchain, la fonction de transition d'état comprend de nombreux composants qui peuvent avoir un impact sur une mise à jour de la base de données.

Pour simplifier, il est principalement défini par une machine virtuelle comme l'EVM, WASM, MIPS ou Cairo. En allant un peu plus loin, lorsqu'un développeur déploie un contrat intelligent sur la machine virtuelle, il verrouille une entrée de la base de données pour un usage exclusif par le contrat intelligent. L'entrée de la base de données ne peut être mise à jour que lorsque le contrat intelligent s'exécute dessus.

Un contrat intelligent définit l'accès en écriture à une entrée de base de données spécifique.

Ainsi, lorsque qu'un utilisateur initie une transaction et cible un contrat intelligent, il a l'intention de mettre à jour une entrée spécifique dans la base de données ou toutes les entrées de base de données auxquelles le contrat intelligent a accès en écriture. Comme le contrat intelligent définit l'accès en écriture, il peut définir qui est autorisé à effectuer cette action.

Dans la majorité des cas, un contrat intelligent fonctionne avec une politique inclusive, permettant à quiconque de l'exécuter tant qu'il remplit certains critères prédéfinis. À moins que la fonction du contrat intelligent ne serve un objectif administratif, les critères ne dépendront pas de l'identité de l'initiateur de la transaction mais seront plutôt utilisés pour faire respecter les règles régissant le contrat intelligent. Par exemple, vérifier que l'utilisateur a un solde suffisant en jeton X avant d'effectuer un échange de jeton X → jeton Y.

En résumé, nous devons prendre en compte deux aspects clés d'une transaction :

1. Non-engagement de la production : Lorsqu'un utilisateur signe une transaction, il n'est pas lié à un résultat d'exécution spécifique. Leur signature couvre les entrées et le contrat intelligent cible mais ne dicte pas l'exécution exacte.
2. Préconditions des contrats intelligents : Les contrats intelligents établissent des conditions qui doivent être remplies pour une exécution réussie. Ces conditions tournent souvent autour de l'application des règles du protocole (comme la logique d'échange) plutôt que de l'identité de l'appelant.

Les deux composants sont nécessaires pour permettre aux utilisateurs d'émettre des transactions en même temps et de gérer les conditions de concurrence. Sinon, comme nous l'avons vu avec le lancement des swaps sur Cardano il y a quelques années, cela peut conduire D’horribles problèmes d’ergonomie.

En même temps, cela conduit à la possibilité de MEV sur n'importe quelle plateforme de contrat intelligent car cela permet à un robot d'interférer avec l'exécution de la transaction d'un utilisateur et potentiellement générer un profit en le faisant.

Bundles de transactions et méthodes d'interférence

Grâce à la nature publique de :

• Transactions de l'utilisateur,
• État partagé de la base de données.

Un chercheur peut simuler des transactions en attente et avoir une vision complète des futurs états de la base de données. Leur tâche est de simuler des transactions et de déterminer s'il existe un état futur de la base de données qui leur est profitable. Si c'est le cas, alors ils devraient s'efforcer de faire en sorte que l'état futur de la base de données se produise et de saisir l'opportunité de profit.

Une fois qu'ils trouvent une transaction en attente qui est rentable pour eux, alors le chercheur peut exécuter l'une des deux stratégies :

• Ne pas interférer. Permettre à la transaction de l'utilisateur de s'exécuter comme prévu et le chercheur suivra avec sa propre transaction qui tirera parti de l'état de la base de données résultant.
• N'intervenez pas. Un chercheur doit émettre des transactions qui établissent les conditions idéales avant que la transaction de l'utilisateur ne soit exécutée.

L'approche de ne pas interférer est simple. Le chercheur a essentiellement précalculé à quoi ressemblera la base de données après l'exécution de la transaction de l'utilisateur et ils peuvent émettre une transaction qui s'exécute après coup et capturer le profit résultant. Par exemple, un chercheur peut saisir une opportunité d'arbitrage en reprenant une transaction de l'utilisateur.

Un chercheur peut émettre deux transactions qui encadrent une transaction d'utilisateur et interfèrent avec son exécution pour collecter un profit.

L'approche d'interférence exige que le chercheur émette des transactions et vise à ce que leurs transactions soient ordonnées avant la transaction de l'utilisateur. Cela impactera l'exécution de la transaction de l'utilisateur et aboutira, espérons-le, à un état de base de données souhaité et rentable pour le chercheur.

Deux exemples d'interférence incluent :

• Sandwiching. Un chercheur émettra deux transactions qui entourent la transaction d'un utilisateur. Cela interférera avec l'exécution de la transaction de l'utilisateur afin de collecter un profit.
• Front-running. Un chercheur copiera la transaction de l'utilisateur et la fera exécuter avant lui. Cela permet au chercheur de voler l'opportunité de profit avant l'utilisateur.

Pour que l'approche d'intervention fonctionne, elle doit faire des hypothèses sur le modèle d'exécution des transactions. Comme mentionné précédemment, nous supposons qu'une transaction d'un utilisateur n'a pas de résultat fixe au moment de la signature et que son exécution finale dépend de l'état de la base de données partagée.

Grâce au modèle d'exécution, et au fait qu'un utilisateur peut définir un ensemble de conditions pré/post qui doivent être satisfaites avant que la transaction ne s'exécute avec succès, on peut soutenir qu'un utilisateur définit une gamme de résultats acceptables, même s'il peut être utilisé contre eux par des chercheurs à la recherche d'une opportunité de réaliser un profit.

L'idée qu'un utilisateur a l'autorité d'approuver une gamme de résultats acceptables est importante lors de l'évaluation de la moralité de MEV.

Influencer Comment un Proposeur Priorise l'Ordre des Transactions

Cela nous amène à la dernière pièce pour permettre MEV - comprendre comment un chercheur peut convaincre le proposant de prioriser leur ensemble de transactions à une position spécifique dans l'ordre total.

L'approche adoptée dépend de la politique de commande mise en œuvre par le Proposer, mais elle se divise généralement en deux catégories :

• Enchère prioritaire. Un chercheur doit payer une enchère plus élevée que tous les autres chercheurs.
• Jeux de latence. Un chercheur doit envoyer sa transaction (qui paie des frais appropriés) au proposant avant tous les autres chercheurs.

En d'autres termes, nous devons prendre en compte la concurrence entre les chercheurs, comment ils peuvent se surpasser les uns les autres et quelle approche a la capacité de permettre à un marché ouvert de chercheurs de participer sur un pied d'égalité.

Un exemple d'enchère de gaz prioritairecomme les chercheurs diffusent constamment de nouvelles transactions avec des frais plus élevés. Il y a au moins 100 transactions dans la fenêtre de bloc de 12 secondes.

Grâce à la nature publique d'un protocole de commérages et au mécanisme d'enchères du marché des frais sur Ethereum, un nouveau phénomène a émergé alors que la communauté prenait conscience de MEV, ce qui a entraîné une congestion significative du réseau.

Dans la forêt sombre, si un seul chercheur trouve une opportunité MEV, il est très probable que d'autres chercheurs le trouveront également. Seul un chercheur peut remporter l'opportunité MEV et cela conduit à une guerre d'enchères très compétitive appelée une enchère de gaz de priorité.

Lors d'une enchère de gaz prioritaire, un chercheur veut payer l'offre minimale nécessaire qui est supérieure à tous les concurrents tout en maximisant leur profit. Ils doivent surveiller les ensembles actuels d'offres (dans le pool de mémoire) et émettre une nouvelle transaction avec une offre plus élevée. Toutes les nouvelles transactions doivent remplacer leur transaction précédente.

Les concurrents répètent le processus ci-dessus et cela entraîne une importante quantité de spams sur le réseau pair à pair. Par exemple, dans le graphique ci-dessus, nous pouvons compter au moins 100 transactions dans une fenêtre de 12 secondes. De plus, une seule transaction peut réussir et saisir l'opportunité MEV. Toutes les transactions concurrentes sont encore incluses dans un bloc et risquent probablement d'échouer à s'exécuter. Gaspillant à la fois la bande passante et l'espace de bloc.

Flashbots a résolu le problème de congestion associé aux enchères de gaz prioritaires en déplaçant l'enchère hors chaîne.

Flashbots est apparu avec une solution pour atténuer les problèmes associés aux enchères de gaz prioritaires.

La solution de Flashbot : Prenez le protocole d'enchère de priorité pour choisir le gagnant et déplacez-le hors chaîne.

Tous les chercheurs ont été encouragés à soumettre des bundles à un Relay géré par Flashbots. Il appartenait au Relay de choisir l'offre gagnante et de la transmettre au proposant. Toutes les offres échouées ont été rejetées par le Relay.

Cela a ouvert la voie au développement du cadre de séparation du proposant-constructeur (BPS), un concept qui distingue entre le constructeur de bloc qui ordonne les transactions pour un bloc et le proposant de bloc qui est investi de l'autorité pour décider du contenu final d'un bloc.

La séparation des rôles favorise un marché ouvert pour les constructeurs, ainsi que les chercheurs, pour créer de manière collaborative des blocs rentables tout en partageant une partie du profit avec le proposant via une vente aux enchères prioritaire. L'objectif principal est de garantir qu'aucune partie ne peut prendre tout le profit généré par les opportunités de MEV.

Le processus de persuasion d'un proposant est très différent pour une blockchain de couche 1 comme Ethereum par rapport à un rollup comme Arbitrum.

Ethereum compte environ 800 000 validateurs, un pool de mémoire public, et le processus de sélection du validateur pour devenir le prochain proposant dépend d'une balise aléatoire. En revanche, Arbitrum n'a qu'un seul Séquenceur (Proposant) qui possède un pool de mémoire privé, facilement identifiable et les utilisateurs peuvent avoir une connexion directe avec eux.

L'environnement de rollup impacte la manière dont un chercheur peut tenter d'influencer le proposant car il n'a plus accès aux instructions en attente et il n'y a qu'une (ou quelques) parties à convaincre.

Comme mentionné précédemment, un chercheur peut :

• Écoutez le flux du séquenceur,
• Trouver les transactions récemment commandées,
• Utilisez des stratégies de contournement de levier pour saisir les opportunités de MEV.

Un chercheur peut augmenter ses chances de gagner la compétition et de réaliser un profit s'il est le premier bot à découvrir l'opportunité de MEV et s'il a la connexion la plus rapide avec le proposant. En d'autres termes, sans une enchère de priorité, le seul moyen pour un chercheur de gagner est de participer à un jeu de latence.

Les chercheurs ont découvert, en étudiant la politique d'alimentation du Séquenceur, que l'alimentation priorisera de manière aléatoire une connexion web-socket différente pour recevoir la transaction en premier.

La meilleure stratégie était simplement d’ouvrir autant de connexions que possible et de recevoir la transaction en premier en gagnant à la loterie des connexions. Cela a conduit à >150k connexions au séquenceur Arbitrum.

Les connexions excessives étaient une perte de ressources, une attaque potentielle par déni de service sur le séquenceur Arbitrum, et seulement bénéfiques pour les chercheurs qui peuvent réussir à concourir dans un jeu de latence.

Timeboostproposition. Combine le premier arrivé, premier servi avec des enchères prioritaires. La majorité des transactions peuvent être ordonnées selon le principe du PAAS, mais les chercheurs ont la possibilité de participer à une enchère prioritaire pour les opportunités de back-running. Ainsi, il élimine tout avantage de latence tout en permettant aux utilisateurs de profiter d'une politique de commande PAAS.

Morality of MEV

Tous les écosystèmes doivent se débattre avec la question suivante:

Devrions-nous encourager un environnement MEV ou tenter de le prévenir entièrement ?

Étonnamment, il n'y a pas de réponse claire, mais de nombreux membres de la communauté technique ont une opinion binaire sur le sujet.

Le mot MEV suscite une émotion chez de nombreuses personnes selon laquelle nous jetons simplement les utilisateurs aux loups et c'est toujours mauvais

Il existe deux écoles de pensée autour de l'exploitation et de la prévention de MEV :

• Camp anti-MEV. MEV comme nuisible. C'est comme jeter un utilisateur aux loups dégénérés et leur permettre d'être exploités au maximum. Nous devrions faire tout notre possible pour empêcher son exploitation.
• Le camp Pro-MEV. MEV est bon. Il offre une incitation financière aux chercheurs pour effectuer des actions qui bénéficient finalement à l'expérience utilisateur et stabilisent le marché. De plus, l'exploitation du MEV est inévitable et nous devrions tout faire pour l'embrasser.

Il existe certains facteurs facilement identifiables contribuant aux opinions binaires au sein de la communauté. Plus souvent qu'autrement, la perspective est ancrée dans des preuves anecdotiques et des expériences personnelles au sein du secteur financier.

Certains soutiennent que la prévalence du trading haute fréquence dans le système financier traditionnel tend à désavantager les petits traders tout en favorisant les grandes sociétés de trading qui ont les ressources (et les autorisations) pour exécuter leurs transactions plus rapidement. De plus, cela conduit les utilisateurs effectuant la transaction à obtenir un mauvais accord tout en permettant aux grandes sociétés d'en tirer profit.

En revanche, d'autres considèrent l'exploitation de MEV comme inévitable en raison de la nature ouverte et sans permission des systèmes de blockchain. C'est un aspect inhérent de la façon dont le système fonctionne, et, en théorie, la stabilité d'un système de blockchain dépend de notre capacité à maximiser l'extraction tout en partageant ses bénéfices à tous les participants.

Évaluation de l'impact de MEV sur un système de blockchain

Volé à mev.day - un grand objectif des événements flashbot est de comprendre comment MEV impacte le protocole de consensus d'un système blockchain (comme la preuve d'enjeu).

Pour comprendre si MEV est moralement justifiable, nous devrions évaluer comment cela impacte l'hypothèse de récompense équitable des systèmes blockchain de couche 1 et si cela impacte négativement l'intention d'une transaction de l'utilisateur.

Récompense équitable pour tous les proposants

Une caractéristique essentielle pour une blockchain de couche 1, comme Bitcoin et Ethereum, est que tous les proposants reçoivent approximativement la même récompense pour produire des blocs au nom du réseau.

La motivation d'offrir une récompense équitable à tous les proposants comporte deux aspects clés qui sous-tendent la sécurité et la fiabilité d'un système de blockchain.

• Gardez l'ensemble des proposeurs décentralisé. Tout d'abord, il vise à empêcher qu'un seul proposant prenne une ampleur disproportionnée par rapport à tous les autres proposeurs au fil du temps, ce qui pourrait éventuellement leur permettre d'accumuler suffisamment de capital pour exécuter une attaque de 51%.
• Incitation financière à suivre la chaîne la plus longue. Deuxièmement, cela crée une incitation financière pour que tous les proposants étendent de manière cohérente la chaîne la plus longue. Si la récompense d'un bloc dépasse significativement celle du bloc suivant, il existe un risque qu'un proposant soit incité à réorganiser l'extrémité de la chaîne.entraînant une instabilité pour les utilisateurs.

Dans la communauté Ethereum, l'insight ci-dessus a conduit à la séparation proposant-constructeur (PBS) comme méthode pour démocratiser les profits de MEV. En d'autres termes, l'objectif d'embrasser MEV est de partager équitablement les récompenses entre tous les Proposers, et finalement protéger la décentralisation et la fiabilité du réseau.

Un rollup ne se concentre pas sur une récompense équitable pour des centaines de milliers de participants, mais pour récompenser toute partie prête à s'impliquer et à maintenir le système en vie.

Inversement, l'obligation d'offrir une récompense équitable à tous les proposants est différente dans un écosystème de rollup, principalement en raison des divergentes hypothèses de confiance sous-jacentes.

Dans une blockchain de couche 1, telle qu'Ethereum, l'hypothèse de confiance repose sur une majorité de proposants agissant honnêtement pour maintenir l'intégrité du système. Il devrait optimiser un vaste réseau de participants divers et les récompenser pour leur disponibilité.

Dans un rollup, l'exigence de confiance est beaucoup plus modeste :

• Sécurité. Une partie honnête pour protéger l'intégrité du système.
• La vivacité. Tout utilisateur peut soumettre sa transaction en utilisant le mécanisme d'inclusion forcée sur la chaîne.

Bien entendu, le mécanisme d’inclusion forcée doit être une option de dernier recours qui peut être utilisée par l’utilisateur (Je ne suis pas fan de based-rollups).

Presque tous les utilisateurs dépendent du Proposer désigné pour décider de l'ordre des transactions et offrir une confirmation douce sur la manière dont leur transaction sera finalement exécutée. Les confirmations douces peuvent être soutenues par un seul proposant ou plusieurs proposants travaillant ensemble. Vous pouvez lire cet articlepour en savoir plus sur les différents niveaux de finalité des transactions dans un rollup.

Séquençage décentralisé. Certains rollups peuvent rechercher une hypothèse de confiance plus forte, comme une majorité honnête, s'ils veulent garantir la disponibilité des confirmations douces au sein d'un comité (ou ensemble) de proposants. Ce n'est pas une exigence stricte pour un rollup et diverses options sont encore en cours d'exploration par la communauté.

L'élément important à retenir est qu'un rollup n'a pas nécessairement besoin de garantir la disponibilité pour des centaines de milliers de participants ou de maximiser la décentralisation des participants. La priorité est de s'assurer que le système est ouvertement accessible et qu'une seule partie honnête peut intervenir au bon moment pour le protéger.

Ainsi, il y a un besoin moindre d'embrasser MEV et d'offrir une récompense équitable à tous les proposants d'un rollup, surtout s'il n'y a qu'un seul proposant. La question d'embrasser MEV ne concerne pas la sécurité du système, mais plutôt si c'est dans l'intérêt du proposant de laisser de l'argent sur la table ou de capturer un certain profit d'un flux de revenus supplémentaire.

Il reste une question de recherche ouverte, mais des preuves empiriques indiquent que la plupart des rollups aujourd'hui ont fonctionné avec succès avec un seul séquenceur tout en n'adoptant pas MEV, ce qui suggère cette conclusion.

Interférence d'une transaction d'utilisateur

Un autre aspect à considérer lors de l'évaluation de la moralité de MEV est de comprendre l'influence potentielle, qu'elle soit positive ou négative, qu'un ensemble de transactions d'un chercheur peut exercer sur l'exécution d'une transaction d'un utilisateur.

Nous soutenons que se concentrer uniquement sur la manière dont cela impacte l'intention d'une transaction de l'utilisateur est excessivement limité.

Une évaluation devrait englober une perspective plus large qui tienne compte des répercussions sur les agents au sein d'un protocole DeFi, ainsi que de sa capacité à contribuer aux opérations synchrones des protocoles DeFi.

Profitons de cette occasion pour examiner des exemples spécifiques de regroupement de transactions et déterminer s'il peut être justifié en tant qu'activité morale.

Front-running

Les attaques de front-running peuvent entraîner une censure en forçant l'échec d'une transaction d'un utilisateur.

La stratégie est souvent associée à un chercheur évaluant la transaction d'un utilisateur, copiant son contenu et volant l'opportunité de l'utilisateur.

• Négatif — Livraison Tx garantie
  • Le Rainbow Bridge de Near a profité des bots MEV pour garantir la livraison de la transactionpour leurs preuves de fraude. Cela aide à protéger l'intégrité d'un protocole DeFi et protège finalement les utilisateurs.
• Négatif — Problèmes de censure
  • Le front-running peut permettre la censure car le chercheur force l'échec de la transaction de l'utilisateur.
  • Cela a été constaté lorsque Vitalik tentait de “dumper” des jetons SHIBA et Les robots MEV ont interféré avec ses transactions pour l'empêcher de vendre les jetons.
  • Vitalik a été contraint de migrer vers CoW Swap et d'envoyer ces transactions directement aux proposants (mineurs).
• Positif — Impossible de récupérer les fonds exposés
  • Dans l'exemple de la Forêt Sombre, le bot MEV a pu voler les fonds pendant que l'utilisateur essayait de le récupérer d'un contrat intelligent exposé/cassé.

Sandwiching

La stratégie est souvent associée à un chercheur changeant le taux de change avant et après le trade d'un utilisateur.

• Négatif — Le pire taux de change
  • Il existe de nombreuses instances de sandwich où un utilisateur se retrouve finalement avec le pire taux de change lorsqu'il effectue son échange. Cela est dû au fait que le chercheur déplace le prix défavorablement pour l'utilisateur, l'échange de l'utilisateur s'exécute, puis le chercheur déplace à nouveau le prix.
  • Le chercheur bénéficie en créant une opportunité d'arbitrage et collecte tout glissement positif que l'utilisateur a pu recevoir. Il y a des arguments queLe 'sandwiching' peut être bénéfique pour l'acheminement des transactions, mais la plupart des discours se concentrent sur l'expérience négative immédiate pour l'utilisateur.
• Positive — Meilleur taux de change (Positif).
  • La liquidité Just In Time (JIT) implique que le chercheur injecte stratégiquement une liquidité concentrée juste avant l'échange de l'utilisateur et la retire immédiatement après l'échange.
  • Cela permet à l'utilisateur d'obtenir un taux de change plus favorable lors de l'exécution de son échange, tandis que le chercheur gagne la majeure partie des frais pour faciliter l'échange.
  • Les fournisseurs de liquidité passifs (LP) peuvent se retrouver désavantagés, car ils reçoivent des frais minimes voire nuls puisque c'est la liquidité du chercheur, pas la leur, qui est utilisée pour exécuter l'échange.

Malheureusement, il a récemment été découvert dans la natureles deux stratégies de sandwich peuvent être combinées et donnent les pires résultats des deux mondes. L'utilisateur recevra le pire taux de change et permettra au chercheur d'obtenir la plupart des frais pour faciliter l'échange. Ainsi, l'utilisateur et les LP passifs perdent tous les deux.

Back-running

La stratégie est souvent associée à un chercheur poursuivant une opportunité semblable à l'arbitrage.

• Opportunités de type arbitrage (positif).
  • Le cas le plus courant de backrunning, à ma connaissance, est lorsque qu'un chercheur souhaite arbitrer le taux de change après un gros swap effectué par l'utilisateur.
  • Cela est bénéfique pour la synchronicité des protocoles DeFi, car cela permet de synchroniser le prix des jetons et, en fin de compte, pour l’utilisateur, car il paie toujours le taux du marché lorsqu’il échange un jeton.

Je ne peux pas me rappeler de stratégies de back-running qui ont un impact négatif sur un utilisateur ou un protocole DeFI. Si vous en connaissez, n'hésitez pas à les laisser dans les commentaires !

Une évaluation objective avec des jugements subjectifs est requise

Nous pouvons jeter un éclairage dans la forêt sombre, mesurer objectivement son impact, puis prendre une décision sur la question de savoir s'il doit être embrassé (et dans quelle mesure).

Il y a un besoin croissant d'une méthodologie améliorée pour évaluer l'impact de MEV.

Cette méthodologie devrait englober :

• Stratégie de regroupement de transactions,
• Effets spécifiques à l'application,
• Rentabilité pour les agents qu'elle bénéficie,
• Pertes potentielles pour les agents qui n'en bénéficient pas,
• Fréquence d'occurrence.

Avec des métriques objectives comme ci-dessus, la communauté peut alors porter un jugement de valeur sur sa moralité. Par exemple, si nous considérons la liquidité Just in Time, cela offre aux utilisateurs un meilleur taux de change pour les actifs en fin de vie, et si cela représente <1% de tous les échanges, alors cela pourrait être une stratégie MEV justifiable à autoriser car les avantages l'emportent sur les risques.

À ma connaissance, le type d'analyse ci-dessus est complètement absent dans le discours de MEV. Les données on-chain sont disponibles, mais l'ensemble de données n'est pas encore facilement accessible pour l'analyse ci-dessus.

Il y a une discussion à avoir dans la communauté sur la manière de trouver un équilibre entre le soutien aux activités de MEV tout en maintenant l'équité dans l'écosystème, où l'équité devrait être explicitement définie,

Faire respecter la subjectivité?

Le discours entourant l'acceptation de formes moralement justifiables de MEV suscite une enquête fondamentale :

Qui, dans le système blockchain, a la responsabilité de défendre les jugements subjectifs sur le type de MEV qui doit être embrassé ou restreint?

Dans le contexte d'une blockchain de couche 1 comme Ethereum, il n'y a pas d'autorité centrale habilitée à imposer des jugements subjectifs. La responsabilité de déterminer si certains types de MEV doivent être exclus incombe aux proposants ou constructeurs individuels. Cependant, de telles exclusions sont souvent impraticables sans une action collective coordonnée.

De plus, étant donné l'engagement de la communauté à préserver la neutralité crédible et à défendre les principes de décentralisation pour garantir le droit de transaction, il est très peu probable d'imposer une quelconque forme de jugement subjectif sur un réseau comme Ethereum. Même l'application des sanctions de l'OFAC a finalement échoué à obtenir un soutien de 100%.

Maintenant, lorsque nous déplaçons notre attention vers une solution rollup de couche 2, nous rencontrons un scénario différent.

Ici, une seule entité, le Proposer, possède l'autorité pour imposer des jugements subjectifs concernant les confirmations douces qu'ils peuvent choisir de fournir pour les transactions. Par exemple, dans la plupart des implémentations de rollup, on fait confiance au Proposer pour ne pas exploiter sa position privilégiée pour des récompenses supplémentaires en manipulant les opportunités de MEV. Cependant, il est concevable qu'à l'avenir, un Proposer puisse choisir de restreindre des formes spécifiques de MEV - du moins autant qu'il est en leur pouvoir de le faire.

Cela soulève la question de la praticité pour imposer la subjectivité et conduit à un problème de recherche intéressant :

Faciliter les confirmations douces pour MEV sélectif. Évaluer l'efficacité pour un séquenceur d'inspecter les transactions en temps réel, de déterminer la stratégie MEV déployée et de décider s'ils doivent être rejetés, sans impact sur l'expérience utilisateur globale ou l'augmentation de la latence du système pour la finalité douce.

Autrement dit, s'il existe une méthodologie objective pour évaluer l'impact de MEV et un cadre subjectif pour décider quel MEV devrait être toléré, dans quelle mesure est-il pratique pour un séquenceur de rollup de l'appliquer.

Neutralité crédible avant tout?

En mettant en place un système qui permet librement à un Proposer d'exclure certaines transactions, nous pourrions ouvrir la porte à une érosion supplémentaire des droits des utilisateurs à effectuer des transactions.

Alors que nous plongeons dans les considérations éthiques de MEV et la justification potentielle de restreindre certaines formes de celui-ci, un dilemme moral plus large émerge — celui qui tourne autour du potentiel de ces jugements de favoriser involontairement la censure.

Il existe une crainte légitime que la liberté des utilisateurs de réaliser des transactions puisse être érodée avec le temps, car certaines transactions sont considérées comme moralement injustes par les opérateurs du système. Cela peut commencer par des transactions qui ne nuisent pas directement à l'utilisateur, mais finir par conduire à la censure d'autres formes de transactions simplement parce que la technologie permet maintenant de le faire.

Je crois fermement qu'une blockchain de couche 1 comme Ethereum doit rester neutre de manière crédible à tout prix. Non seulement pour protéger le droit de transaction, mais aussi pour protéger tous les rollups qui se construisent dessus. C'est une condition préalable pour garantir qu'Ethereum puisse être la racine de confiance et la plateforme pour protéger les fonds des utilisateurs qui sont bloqués dans un système hors chaîne.

D'autre part, il existe un potentiel pour les Proposers dans un système de type rollup d'implémenter un filtrage de transaction en temps réel et de renoncer à la neutralité crédible.

Cette avenue de recherche est susceptible d'être poursuivie, quelle que soit notre opinion sur l'importance de la neutralité crédible. Il est impératif que notre communauté s'engage de manière proactive avec elle et comprenne dans quelle mesure elle peut être mise en œuvre de manière pratique.

Il est vrai que embrasser la praticité du filtrage des transactions peut inadvertamment conduire à un système qui érode la liberté des utilisateurs de faire des transactions.

C'est pourquoi notre communauté doit travailler en parallèle sur un autre courant de recherche qui se concentre sur les protocoles de commande qui lient les mains du proposant, empêchant leur capacité à filtrer des transactions spécifiques, et protéger en fin de compte le droit de l'utilisateur de réaliser des transactions.

Par défaut, on ne peut pas être malveillant. À mon avis, l'objectif final est de construire un rollup où le Proposer ne peut pas être malveillant, plutôt que de simplement promettre qu'il ne le sera pas.

En supposant que la communauté décide de mettre en œuvre des protocoles qui lient les mains du proposant, alors il y a une crainte légitime que MEV doit être embrassé par défaut. Je suis d'avis que ce n'est pas nécessairement le cas.

Par exemple, la proposition Time-boost est un exemple qui combine:

• Commande selon le principe du premier arrivé, premier servi,
• Accord de commande par comité,
• Activer le back-running via des micro-enchères.

Cela permet à un rollup d'adopter des stratégies de back-running, quelque chose qui est généralement considéré comme moralement juste, tout en rendant difficile l'insertion d'une transaction d'un utilisateur sans accès direct à l'utilisateur.

Sans filtrage des transactions, le compromis est qu'un protocole de commande peut décourager des catégories entières de stratégies MEV, mais cela peut être nécessaire pour aider à protéger la liberté des utilisateurs de transiger.

Bien sûr, d'un autre côté, peut-être qu'un rollup ne devrait pas essayer de prévenir les opportunités d' MEV du tout et d'embrasser MEV dans son intégralité. Permettez au marché d'atteindre un certain équilibre autour des profits générés par MEV en permettant un marché ouvert aux participants. Tout peut arriver!

Il n'y a pas de bonne réponse sur la question de prévenir ou d'embrasser MEV.

Heureusement, les rollups en tant que pile technologique nous offrent la liberté d'expérimenter avec tout ce qui précède et de trouver la solution qui protège au mieux les intérêts de toutes les parties impliquées, y compris l'utilisateur effectuant la transaction, les agents dans les protocoles DeFi et les participants dans le protocole sous-jacent.

Disclaimer：

1. Cet article est repris de [ Cryptomonnaie et amis]. Tous les droits d'auteur appartiennent à l'auteur original [PATRICK MCCORRY]. Si des objections sont émises à cette réimpression, veuillez contacter l'équipe Gate Learn, qui s'en occupera rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.