Introduction

Dans la quête continue d'améliorer les performances de la blockchain pour gérer l'adoption de masse, Monad se distingue comme une force pionnière pour optimiser le modèle de la machine virtuelle Ethereum (EVM) avec une série d'améliorations de bas niveau : E/S asynchrones, un Trie de Patricia optimisé, une exécution différée et un contrôle de concurrence optimiste pour le traitement parallèle [2]. Ces améliorations s'attaquent efficacement aux goulots d'étranglement de l'exécution et à l'accès inefficace à l'état observés sur des plateformes comme Ethereum sans sacrifier la décentralisation.

Dans ce post, nous explorons les mises en œuvre possibles d'une infrastructure robuste d'enchères de la valeur extractible par les mineurs (MEVA) sur Monad. Nous décrivons également quelques leçons transférables et précieuses issues d'approches existantes telles que Flashbots sur Ethereum et Jito Network sur Solana.

Nous voulons souligner quelques points clés :

1. MEV est inhérent à tout réseau blockchain. Une infrastructure MEVA robuste est cruciale pour éviter un processus de production de blocs désordonné avec des externalités négatives et des incitations désalignées.
2. La conception de MEVA est profondément intégrée aux mécanismes sous-jacents d'une chaîne, en particulier à son processus de consensus et d'exécution. Les améliorations futures dépendront de l'évolution de ces facteurs et des performances du réseau sous différents niveaux de stress.
3. Les tendances historiques de l'évolution de la production de blocs, telles qu'observées sur Ethereum et Solana, peuvent informer la conception de MEVA sur Monad.
4. MEVA sur des blockchains à exécution différée et haute performance comme Monad nécessitera probablement des stratégies de construction et de recherche de blocs probabilistes, similaires au trading à haute fréquence, en raison de ses contraintes temporelles.

En abordant ces points, nous espérons apporter un éclairage sur les défis et les considérations impliqués dans la conception d'une infrastructure MEVA adaptée à l'architecture et aux exigences de performance uniques de Monad.

Paysage MEV sur Ethereum

MEVA sous la Staging de Consensus-Execution d'Ethereum

Dans Ethereum, le consensus nécessite une exécution préalable. Lorsque les nœuds s'accordent sur un bloc, ils s'accordent à la fois sur la liste des transactions dans le bloc et sur la racine de Merkle résumant l'état post-facto après l'exécution du bloc. Par conséquent, les leaders doivent exécuter toutes les transactions dans le bloc proposé avant de propager la proposition. Pendant ce temps, les nœuds de validation doivent exécuter les transactions avant de voter.

Figure 1: Le flux de travail de Builder dans MEV-Boost sous la séparation EL-CL.

La figure 1 illustre un flux de travail de constructeur typique dans MEV-Boost pour la séparation Proposer-Builder (PBS). Les constructeurs terminent la construction des blocs et les soumettent à un relais, qui transfère les blocs à un client de la couche d'exécution (EL) pour la simulation et les vérifications de validité.

Étant donné que l'exécution est une condition préalable au consensus, lorsqu'un constructeur construit un bloc, il doit transmettre le bloc construit à un client de la couche d'exécution (EL) et simuler le bloc pour en vérifier la validité. Au-delà de son rôle nécessaire dans la mise en scène de l'exécution du consensus, l'étape de simulation apporte également des avantages à la fois aux constructeurs et aux chercheurs.

Perspective du constructeur : Les constructeurs peuvent estimer avec précision la valeur du bloc pour eux-mêmes et pour les validateurs en simulant chaque transaction. Ils peuvent également expérimenter le réordonnancement des transactions pour minimiser les retours en arrière et maximiser l'extraction des frais de gaz ou des pourboires de base à la fois des transactions dans le mempool et du paquet. Leur estimation précise permet des offres plus élevées aux validateurs.

Perspective du chercheur : En raison du filtrage effectué par les constructeurs pour éliminer les ensembles potentiellement réversibles avant leur arrivée sur la chaîne, les chercheurs voient également une exécution de stratégie garantie, ajoutant du déterminisme. De plus, les chercheurs ont également accès à l'état le plus récent du bloc. Lorsque la couche de consensus (CL) propage un nouveau bloc, les chercheurs peuvent utiliser l'état de ce bloc comme point de départ pour construire des ensembles rentables. Pendant ce temps, il existe des indications pour plus de transactions ou de fonctionnalités hors protocole offertes par les constructeurs en ce moment, ce qui permet aux chercheurs d'obtenir des informations d'état même pour le bloc actuel à construire pour ajouter des stratégies de rétrogradation à leurs blocs à venir.

Cependant, le développement de PBS a vu une montée de la centralisation dans la construction de blocs, reflétant le commerce traditionnel dans lequel les entreprises concourent pour des canaux réseau à micro-ondes dédiés afin de gagner la priorité pour exécuter des stratégies d'arbitrage.

Itération de produit à mesure que le réseau mûrit

Nous explorons maintenant comment MEV a évolué au fur et à mesure de la progression d'Ethereum, illustré chronologiquement dans la Figure 2.

Figure 2: Une vue chronologique de la façon dont MEV évolue alors que le réseau Ethereum progresse. La figure est légèrement adaptée de [4].

Ère des enchères de gaz prioritaires (PGA)

Comme indiqué dans la Figure 3, les chercheurs ont identifié des opportunités MEV rentables et ont soumis leurs transactions activées par smart contract au mempool public. Cette visibilité publique a entraîné un format d'enchères à prix ouvert et à premier prix on-chain, où même les transactions échouées entraînaient des coûts de gaz.

Cette période a vu des activités de MEV non structurées, compétitives et coûteuses telles que des transactions avec la même paire (compte, nounce) et des offres croissantes [6], contribuant à la congestion du réseau ou à l'instabilité du consensus.

Figure 3: Enchère de gaz à priorité simple. La figure est légèrement adaptée de [6].

Flashbots et EIP-1559

Pour remédier à ces problèmes, Flashbots a introduit des relais, des maisons de vente aux enchères intermédiaires entre les chercheurs et les producteurs de blocs (les mineurs à l'époque du PoW). Cette initiative transforme le marché du MEV d'une enchère au prix le plus élevé à une enchère scellée. La figure 4 montre comment les relais aident à prévenir l'escalade des offres dans la mempool publique et à établir un processus de production de blocs plus ordonné et sécurisé.

La structure de frais de l'EIP-1559 joue également un rôle ici [7]. Elle a simplifié les enchères en introduisant des prix partiellement affichés via des frais de base, mais n'a pas abordé l'ordre des transactions au sein des blocs, qui continue de générer des MEV via des frais prioritaires. En réalité, de nombreux chercheurs exprimaient auparavant des offres directement aux mineurs via des transferts de coinbase. Ils ont fini par se plaindre davantage des frais de coinbase, car ils ne pouvaient plus soumettre de bundles de 0 gaz.

Figure 4: MEVA avec relais. La figure est légèrement adaptée de [6].

Séparation Proposant-Constructeur (PBS)

Suite à la transition d'Ethereum vers la preuve d'enjeu (PoS) après la fusion, la séparation Proposer-Builder (PBS) a été mise en œuvre pour affiner davantage la séparation des rôles dans le pipeline de production de blocs. Comme décrit précédemment, les relais agissent désormais en tant qu'intermédiaires entre les constructeurs de blocs et les proposants, agissant en tant que gardiens pour assurer la disponibilité des données et la validité des blocs. Étant donné qu'un proposant peut se connecter à plusieurs constructeurs pour différentes transactions privées, les constructeurs doivent rivaliser en offrant des paiements au proposant. Cette dynamique est illustrée dans la figure 5.

Figure 5: MEVA à l'ère de PBS. Cette figure est légèrement adaptée de [6].

Risques de concentration

Malgré ces progrès historiques, il est important de souligner les préoccupations croissantes liées aux risques de concentration sur le marché des constructeurs. Au cours de l'année écoulée, une oligarchie des 9 principaux constructeurs a régulièrement détenu plus de 50% du marché, ce qui indique un degré élevé de concentration du marché, comme le montre la Figure 6. L'état de la concentration est encore plus prononcé actuellement, les trois principaux constructeurs couvrant plus de 90% des blocs.

Figure 6 : Part de marché des constructeurs. Le graphique indique la forte concentration prévalant dans le marché des constructeurs. Le graphique est adopté dehttps://arxiv.org/pdf/2405.01329

Jito sur Solana

Architecture de Jito

En tant que MEV canonique sur Solana, Jito a été créé pour remédier au taux élevé de spam sur Solana en raison des faibles coûts de transaction. Les échanges de spam sont efficacement incités tant que le coût d'une transaction échouée (environ 0,000005 SOL) n'excède pas le profit attendu.

Selon un rapport de Jito Labs en 2022 [8], plus de 96% des tentatives d'arbitrage et de liquidation ont échoué cette année-là, avec des blocs contenant plus de 50% de transactions liées à la MEV. Le rapport met également en évidence le fait que les robots de liquidation ont spamé le réseau avec des millions de paquets dupliqués pour accomplir plusieurs milliers de liquidations réussies, entraînant un taux d'échec supérieur à 99% [8].

Figure 7: Un aperçu global du MEVA de Jito sur Solana.

La gravité des externalités MEV sur Solana a conduit Jito à développer une couche MEVA visant à apporter de l'ordre et du déterminisme au processus de production de blocs. Examinons l'architecture MEVA originale proposée par Jito, telle qu'illustrée à la figure 7.

Jito a les composants suivants :

Relais - agit comme un proxy pour recevoir les transactions et les transmet aux deux moteurs de blocs (ou à la chaîne d'approvisionnement MEVA) et aux validateurs.

Block Engine - ingère les transactions du relais, coordonne avec les chercheurs, accepte les paquets, effectue des simulations de paquets et transmet les meilleures transactions et paquets au validateur pour traitement. Notamment, Jito organise une vente aux enchères partielle de blocs pour l'inclusion de paquets au lieu d'une vente aux enchères complète, traitant historiquement plus de 80% des paquets dans deux créneaux [9].

Pseudo Mempool - crée une fenêtre temporelle opérationnelle d'environ 200 millisecondes via le client Jito-Solana, induisant une enchère discrétisée pour le flux de commandes [10]. Jito a fermé ce mempool le 9 mars 2024.

Choix de conception de Jito

Explorons les composants spécifiques de la conception du système de Jito et considérons comment ces choix de conception découlent du processus de production de blocs de Solana.

Jito ne prend en charge que des enchères partielles de blocs plutôt que la construction complète de blocs, probablement en raison du modèle d'exécution multi-thread de Solana, qui manque de planification globale. Plus précisément, la Figure 8 montre des threads parallèles qui exécutent des transactions, chacun maintenant sa propre file d'attente de transactions en attente d'exécution. Les transactions sont attribuées de manière aléatoire aux threads et sont ordonnées localement par frais de priorité et temps. Sans ordonnancement global du côté du planificateur (avant la mise à jour 1.18.x), les transactions de Solana connaissent intrinsèquement un non-déterminisme dû aux fluctuations du planificateur [11]. Par conséquent, dans le MEVA, les chercheurs ou les validateurs ne peuvent pas déterminer de manière fiable l'état actuel.

Figure 8: Le modèle d'exécution multi-thread pour le client Solana. Remarquez que l'étape Bundle de MEVA est ajoutée en tant que thread distinct dans la file d'attente multi-thread.

D'un point de vue technique, l'intégration de l'alimentation du moteur de blocs de Jito en tant que fil supplémentaire fonctionnant en parallèle avec les fils existants s'intègre bien dans l'architecture multi-thread de Solana. Bien que les enchères de bundle assurent un ordre basé sur les frais prioritaires au sein du fil du moteur de blocs de Jito, il n'y a aucune garantie que les bundles seront toujours placés avant les transactions utilisateur à l'échelle mondiale.

Pour remédier à cela, Jito préalloue une partie de l'espace de bloc pour le thread groupé, garantissant des groupes avec de l'espace dans le bloc. Bien que l'indétermination persiste, cette approche augmente la probabilité d'exécution réussie de la stratégie. Elle incite également les chercheurs à participer à l'enchère plutôt qu'à envoyer du spam sur le réseau. En réservant de l'espace de bloc pour les groupes, Jito parvient à trouver un équilibre, favorisant des enchères ordonnées et atténuant les effets chaotiques du spam de transactions.

Suppression du pseudo-pool de mémoire

L'adoption généralisée de Jito a donné des résultats positifs dans la lutte contre le problème de spam sur Solana. Les recherches menées par p2p [12] et les données présentées dans la Figure 9 révèlent une amélioration statistiquement significative du taux de production de blocs relatifs après l'adoption du client Jito. Cela indique que le traitement des transactions est devenu plus efficace, grâce au moteur de blocs optimisé de Jito introduit en 2023.

Figure 9: Preuve de l'efficacité de Jito dans la lutte contre le problème de spam sur Solana. Le graphique est extrait d'un article de recherche dans [12] réalisé par l'équipe p2p.

Bien que des progrès significatifs aient été réalisés, de nombreux défis restent à relever. Étant donné que les bundles Jito ne remplissent que partiellement les blocs, les transactions induisant un MEV peuvent encore contourner le canal d'enchères Jito. Ce problème est au moins partiellement confirmé par le tableau de bord Dune dans la Figure 10 [13], qui montre que le réseau continue de connaître une moyenne de plus de 50% d'échecs de transactions en raison de spam de bots depuis 2024.

Figure 10: Un tableau de bord Dune (https://dune.com/queries/3537204/5951285) illustrant les activités de spam de bot sur Solana depuis mai 2022.

Le 9 mars 2024, Jito a pris la décision de suspendre son mempool phare. Cette décision a été motivée par la croissance des transactions memecoin et une augmentation correspondante des attaques sandwich (un type de front-running où les chercheurs placent des transactions avant et après la transaction cible), ce qui a finalement dégradé l’expérience utilisateur. À l’instar des tendances observées sur Ethereum avec les canaux de flux d’ordres privés dans MEVA, la fermeture du mempool public peut encourager la croissance du flux d’ordres privés grâce à des partenariats avec des services frontaux tels que les fournisseurs de portefeuilles et les bots Telegram. Les chercheurs peuvent former des partenariats directement avec les validateurs pour l’exécution, l’inclusion et l’exclusion préférées. En fait, la figure 11 en est la preuve, qui illustre le profil de profit horaire du bot sandwich pour le plus grand chercheur privé de mempool (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) après l’arrêt du mempool.

Figure 11: Le bénéfice horaire pour Sandwich Bot avec Private Mempool pour le chercheur “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

La décision de Jito de fermer la mempool souligne l'engagement fort de l'équipe à aborder les problèmes fondamentaux au sein de l'écosystème Solana. Au-delà de l'itération sur MEVA ou de l'ajustement du mécanisme de frais de gaz de Solana, Jito aide également à éduquer les protocoles sur la réduction des vecteurs d'attaque par le biais de choix de conception de produit UI tels que la limitation des paramètres de glissement par défaut. Que ce soit par des ajustements de structure de frais qui rendent le spamming plus coûteux ou par la modification des protocoles de communication, l'infrastructure de Jito restera essentielle pour maintenir la santé et la stabilité du réseau Solana.

Conception MEVA sur Monad

Exécution différée & Implications sur MEVA

Contrairement à Ethereum, où le consensus sur un bloc nécessite à la fois la liste des transactions (avec un ordre) et la racine de Merkle résumant tous les états post factum, Monad découple l'exécution antérieure du consensus. L'accord des nœuds ne nécessite que de régler l'ordre officiel. Comme illustré dans la figure 12, chaque nœud exécute indépendamment les transactions dans le bloc N tout en lançant le consensus sur le bloc N+1. Cette disposition permet un budget de gaz correspondant au temps total du bloc puisque l'exécution n'a besoin que de suivre le consensus. [15] Sans avoir besoin que le nœud principal calcule la racine de l'état de facto, l'exécution peut utiliser toute la période de consensus pour le prochain bloc.

Figure 12: Exécution différée du monade comparée à la mise en scène Exécution-Consensus d'Ethereum. La fenêtre temporelle opérationnelle est également illustrée du point de vue de la conception MEV.

Nous définissons la fenêtre temporelle opérationnelle comme la période autorisée pour MEVA sur Monad pour finaliser une proposition de construction de bloc à la fois réalisable et rentable par rapport à la méthode de construction de bloc par défaut. Il y a deux conséquences immédiates du modèle d'exécution différée:

1. Lorsque MEVA construit pour le N-ième bloc dans la fenêtre de temps opérationnelle, les validateurs sont d'accord en même temps sur la liste des transactions pour le N-ième bloc tout en essayant de terminer l'exécution pour le bloc N-1. Par conséquent, dans la fenêtre de temps opérationnelle à N, il est très possible que l'état disponible soit encore à N-2. Cela signifie qu'il n'y a pas de «état le plus récent» garanti pour le relais ou le constructeur dans cette architecture d'exécution différée. Par conséquent, il est impossible de simuler contre le dernier bloc avant que le suivant ne soit produit, ce qui entraîne de l'indéterminisme.
2. Avec un temps de blocage d'une seconde de Monad, la fenêtre de temps opérationnelle pour MEVA est extrêmement limitée. Cela signifie que les constructeurs peuvent ne pas avoir suffisamment de temps pour simuler séquentiellement des blocs complets de transactions et de paquets comme ils le font généralement sur Ethereum. De nombreuses variables peuvent affecter le temps nécessaire à la simulation de transaction sur EVM. Cependant, en supposant qu'une simulation de transaction prend entre 10^1 et 10^2 microsecondes (une estimation approximative), et avec l'objectif de Monad de 10^4 transactions par seconde, cela pourrait prendre environ 1 seconde complète pour simuler le bloc complet dans la fenêtre de temps opérationnelle. Étant donné un temps de bloc de 1 seconde de Monad, il serait difficile pour les constructeurs ou les relais de réaliser plusieurs simulations de bloc complet pour optimiser le bloc construit.

Stratégie de constructeur probabiliste et de recherche

Étant donné les contraintes, il est impraticable de mener à bien une simulation complète du bloc dans la fenêtre temporelle opérationnelle et de simuler par rapport à l'état le plus récent. Étant donné que les constructeurs manquent désormais à la fois de temps et de l'état le plus récent pour connaître le pourboire exact de chaque transaction, ils doivent déduire le pourboire du chercheur en se basant sur la probabilité de réversion de la transaction en se fiant à la réputation ou en simulant par rapport à l'état (au mieux) N-2. Cela rend la valorisation du bloc moins déterministe.

Les chercheurs font face à une plus grande incertitude d'exécution en raison du manque de garantie théorique contre les retours de transaction une fois que le validateur accepte le bloc construit par le constructeur. Cela contraste avec Ethereum, où les chercheurs se disputent des canaux de flux de commandes privés dédiés au constructeur pour des exécutions de stratégie relativement déterministes. Dans ce cadre relativement probabiliste sur Monad, les chercheurs font désormais face à un risque plus élevé de retours de bundles on-chain, ce qui conduit à un profil de PnL d'exécution plus incertain. Cela ressemble aux traders à haute fréquence qui exécutent des signaux probabilistes avec des rendements attendus légèrement positifs au fil du temps.

Figure 13 : Un diagramme de spectre conceptuel illustrant différents paradigmes de conception MEVA classés par le degré de vérification ou de simulation de bloc proposé.

Comme le montre la figure 13, le degré de vérification préalable de l’ensemble ou du bloc du côté du constructeur crée un spectre d’incertitude quant au prix ou à l’évaluation du bloc proposé. D’un côté se trouve le modèle PBS de style Ethereum avec une tarification précise, où les constructeurs doivent utiliser le client de couche d’exécution (EL) pour simuler la transaction dans le bloc proposé. Ils doivent naviguer à travers un large éventail de combinatoires parmi les ensembles soumis. À l’autre extrémité se trouve le modèle Optimistic Builder [16] avec vérification de bloc asynchrone. Dans ce modèle, les constructeurs contournent le temps requis pour toute simulation pendant la fenêtre de temps opérationnelle et honorent les conseils montrés aux validateurs ou au relais en déposant des garanties soumises à des coupes budgétaires. L’approche de vérification probabiliste ou de simulation partielle proposée ici sur Monad se situe entre les deux, augmentant la probabilité d’une exécution réussie de la stratégie pour les chercheurs malgré un certain indéterminisme.

Par exemple, un teneur de marché sur un DEX de carnet de commandes onchain pourrait payer pour pré-déplacer leurs positions via le MEVA lorsqu'ils repèrent un mouvement de prix uni-directionnel majeur pour éviter la sélection adverse. Cette stratégie probabiliste leur permet d'agir rapidement, même sans les informations d'état les plus récentes, équilibrant le risque et la récompense dans un environnement de trading dynamique.

Remarques de clôture

MEV joue un rôle crucial dans l'optimisation de la production de blocs en atténuant les externalités et en améliorant la stabilité globale du système. L'évolution continue des cadres de MEV, illustrée par Jito sur Solana et diverses mises en œuvre sur Ethereum, est extrêmement utile pour relever les défis de la scalabilité et aligner les incitations des participants au réseau.

Monad est un réseau prometteur dans sa petite enfance, offrant une opportunité unique à la communauté de façonner la conception optimale de MEV. Compte tenu de la mise en scène unique d'exécution-consensus de Monad, nous invitons les chercheurs, les développeurs et les validateurs à collaborer et à partager leurs idées. Cette collaboration sera essentielle pour créer un processus de production de blocs robuste et efficace, permettant à Monad de réaliser son potentiel en tant que réseau blockchain à haut débit.

Avertissement :

1. Cet article est repris de [ 0xavr]. Tous les droits d'auteur appartiennent à l'auteur original [APRIORI ⌘]. S'il y a des objections à cette republication, veuillez contacter le Portail Apprendreéquipe, et ils s'en occuperont 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 effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.