L'ère de l'exécution parallèle est arrivée : un aperçu du paysage MEV sur Monad
TechFlow SélectionTechFlow Sélection
L'ère de l'exécution parallèle est arrivée : un aperçu du paysage MEV sur Monad
Cet article explore la possibilité de construire sur Monad une infrastructure solide d'enchères pour la valeur extractible par les mineurs (MEVA).
Dédié à des analyses Web3 approfondiesAuteur :APRIORI ⌘
Traduction : TechFlow
Introduction
Dans le processus d'amélioration des performances des blockchains afin de permettre une adoption à grande échelle, Monad a optimisé en profondeur le modèle de la machine virtuelle Ethereum (EVM) grâce à une série d'optimisations fondamentales telles que l'E/S asynchrone, un arbre de Patricia optimisé, l'exécution différée et un contrôle concurrentiel optimiste. Ces améliorations résolvent efficacement les goulots d'étranglement liés à l'exécution ainsi que les problèmes d'accès inefficace à l'état présents sur des plateformes comme Ethereum, sans compromettre la décentralisation.
Cet article explore la possibilité de construire sur Monad une infrastructure robuste d'enchères pour la valeur extractible par les mineurs (MEVA), en s'inspirant des expériences précieuses accumulées par Flashbots sur Ethereum et par le réseau Jito sur Solana.
Nous souhaitons insister sur plusieurs points clés :
-
La MEV est une caractéristique inhérente à toute blockchain. Une infrastructure MEVA solide est cruciale pour éviter les externalités négatives et les désalignements d'incitations durant la production des blocs.
-
La conception de la MEVA est étroitement liée aux mécanismes fondamentaux de la blockchain, notamment à sa phase de consensus-exécution. Les améliorations futures dépendront de l’évolution de ces facteurs ainsi que du comportement du réseau sous différentes contraintes.
-
Les tendances historiques observées dans la production de blocs sur Ethereum et Solana peuvent servir de référence utile pour concevoir la MEVA sur Monad.
-
Sur une blockchain haute performance et à exécution différée comme Monad, la MEVA pourrait nécessiter des stratégies probabilistes de construction de blocs et de recherche analogues au trading haute fréquence, afin de respecter les contraintes temporelles strictes.
En explorant ces questions, nous espérons offrir des perspectives utiles pour concevoir une infrastructure MEVA adaptée à l’architecture unique et aux exigences de performance de Monad.
Contexte de la MEVA sur Ethereum
La MEVA dans le cadre du cycle consensus-exécution d’Ethereum
Sur Ethereum, le consensus implique une exécution préalable. Lorsqu’un nœud valide un bloc, il ne s’accorde pas uniquement sur la liste des transactions (ordonnées), mais aussi sur la racine Merkle résultant de l’état après exécution complète. Ainsi, le proposant doit exécuter toutes les transactions du bloc avant de transmettre sa proposition. De même, les validateurs doivent eux aussi exécuter ces transactions avant de voter.
Figure 1 : Flux de travail typique d’un constructeur dans le modèle de séparation Proposant-Constructeur (PBS) via MEV-Boost
La Figure 1 illustre le flux de travail classique d’un constructeur dans le système PBS de MEV-Boost. Après avoir construit un bloc, le constructeur le soumet à un relais, qui le transfère ensuite au client de la couche d’exécution (EL) pour simulation et vérification de validité.
Étant donné que l’exécution est une condition préalable au consensus, lorsqu’un constructeur assemble un bloc, il doit le transmettre au client EL pour en simuler l’exécution et en vérifier la validité. En plus de son rôle obligatoire dans la phase consensus-exécution, cette étape de simulation offre également des avantages aux constructeurs et aux chercheurs (searchers).
Du point de vue du constructeur : en simulant chaque transaction, le constructeur peut estimer précisément la valeur du bloc tant pour lui-même que pour le validateur. Il peut aussi réorganiser les transactions afin de minimiser les reversals (rejets) et maximiser les frais de gaz ou les petits pourboires extraits du mempool ou des bundles. Cette estimation précise lui permet d’offrir un prix plus élevé au validateur.
Du point de vue du chercheur : puisque le constructeur filtre, avant validation, les bundles susceptibles d’échouer, le chercheur bénéficie d’une plus grande certitude quant à l’exécution de sa stratégie. De plus, il a accès à l’état le plus récent. Dès qu’un nouveau bloc est diffusé par la couche de consensus (CL), le chercheur peut utiliser cet état comme point de départ pour construire des bundles rentables. En outre, certains signes indiquent que les constructeurs offrent désormais davantage de fonctionnalités hors protocole, permettant aux chercheurs d’accéder à des informations sur l’état du prochain bloc en cours de construction, afin d’ajouter des stratégies de frontrunning directement dans le bloc imminent.
Toutefois, l’évolution du PBS a entraîné une centralisation croissante de la construction de blocs, phénomène comparable à celui observé dans les marchés traditionnels où les entreprises se disputent des canaux privilégiés (comme des réseaux micro-ondes) pour exécuter leurs stratégies d’arbitrage en priorité.
Évolution continue des produits avec la maturation du réseau
Examinons maintenant comment la MEVA a évolué avec le développement d’Ethereum, comme illustré dans la Figure 2.
Figure 2 : Vue chronologique de l’évolution de la MEVA avec le réseau Ethereum
L’ère des enchères prioritaires de gaz (PGA)
Comme illustré dans la Figure 3, les chercheurs identifient des opportunités lucratives de MEV et soumettent leurs transactions de contrat intelligent au mempool public. Cette visibilité publique conduit à des enchères publiques sur la chaîne, prenant la forme d’une enchère au premier prix, où même les transactions perdantes génèrent des frais de gaz.
Cette période a vu l’émergence d’activités MEV non structurées, coûteuses et très compétitives, telles que des transactions avec les mêmes paires (compte, annonce) et des surenchères incessantes, provoquant congestion du réseau ou instabilité du consensus.
Figure 3 : Schéma simplifié d'une enchère prioritaire de gaz (PGA)
Flashbots et EIP-1559
Pour remédier à ces problèmes, Flashbots a introduit un relais agissant comme intermédiaire entre les chercheurs et les producteurs de blocs (mineurs à l’époque PoW). Cette initiative a transformé le marché de la MEV d’une enchère ouverte et transparente en un système d’enchères scellées. Comme montré dans la Figure 4, le relais contribue à empêcher l’escalade des surenchères dans le mempool public et instaure un processus de production de blocs plus ordonné et sécurisé.
La structure tarifaire introduite par l’EIP-1559 a également joué un rôle ici. Elle a simplifié les enchères via les frais de base, bien qu’elle n’ait pas résolu le problème de l’ordre des transactions à l’intérieur du bloc, qui reste piloté par les frais prioritaires et donc par la MEV. En pratique, de nombreux chercheurs faisaient auparavant des offres directes aux mineurs via des transferts vers le coinbase. Ils ont finalement exprimé plus de frustrations concernant les frais du coinbase, car ils ne pouvaient plus soumettre des bundles à gaz nul.
Figure 4 : MEVA avec relais
Séparation entre Proposant et Constructeur (PBS)
Après la fusion d’Ethereum vers la preuve d’enjeu (PoS), la séparation entre proposant et constructeur (PBS) a été mise en œuvre pour optimiser davantage la spécialisation des rôles dans le pipeline de production des blocs. Comme mentionné précédemment, le relais joue désormais un rôle d’intermédiaire entre les constructeurs et les proposants, garantissant la disponibilité des données et la validité des blocs. Puisque les proposants peuvent se connecter à plusieurs constructeurs pour recevoir différentes transactions privées, les constructeurs doivent rivaliser en payant des frais aux proposants. Cette dynamique est illustrée dans la Figure 5.
Figure 5 : MEVA à l’ère de la PBS
Le risque de centralisation
Malgré ces avancées historiques, il convient de souligner le risque croissant de centralisation sur le marché des constructeurs. Au cours de l’année écoulée, les 9 principaux constructeurs se sont régulièrement partagé plus de 50 % des parts de marché, témoignant d’un haut niveau de concentration, comme le montre la Figure 6. La situation actuelle est encore plus marquée : les trois premiers constructeurs couvrent désormais plus de 90 % des blocs.
Figure 6 : Parts de marché des constructeurs, illustrant la forte concentration du marché (source : lien)
Jito sur Solana
Architecture du système Jito
En tant que solution standard de MEVA sur Solana, Jito a été conçu pour répondre au problème élevé de spam transactionnel induit par les coûts de transaction très bas sur Solana. Tant que le coût d’une transaction ratée (environ 0,000005 SOL) reste inférieur au profit anticipé, le spam est fortement incité.
Selon un rapport de Jito Labs datant de 2022, plus de 96 % des tentatives d’arbitrage et de liquidation ont échoué cette année-là, et plus de 50 % des transactions dans les blocs étaient liées à la MEV. Le rapport indique également que les robots de liquidation ont envoyé des millions de paquets redondants pour seulement quelques milliers de succès, entraînant un taux d’échec supérieur à 99 %.
Figure 7 : MEVA de Jito sur Solana
La gravité des externalités liées à la MEV sur Solana a poussé Jito à développer une couche MEVA destinée à apporter ordre et déterminisme au processus de production des blocs. Revenons sur l’architecture MEVA initiale proposée par Jito, illustrée dans la Figure 7.
Jito comprend les composants suivants :
Relais - Agit comme intermédiaire pour recevoir les transactions et les transférer au moteur de bloc (ou chaîne logistique MEVA) ainsi qu’aux validateurs.
Moteur de bloc - Reçoit les transactions du relais, coordonne les chercheurs, accepte les bundles, simule leur exécution, puis transmet les meilleures transactions et bundles aux validateurs pour traitement. À noter : Jito réalise une enchère partielle de bloc pour intégrer les bundles, et non une enchère de bloc complet, traitant historiquement plus de 80 % des bundles dans deux slots.
Pseudo-mempool - Créé via le client Jito-Solana, il ouvre une fenêtre temporelle d’environ 200 ms, conduisant à une discrétisation des enchères de flux d’ordres. Jito a fermé ce mempool le 9 mars 2024.
Les choix de conception de Jito
Analysons maintenant les composants spécifiques de la conception du système Jito, et examinons comment ces choix découlent du processus de production de blocs sur Solana.
Le fait que Jito ne prenne en charge que des enchères partielles de blocs, plutôt que la construction complète du bloc, est probablement dû au modèle d’exécution multithread de Solana, qui manque d’ordonnanceur global. Plus précisément, la Figure 8 montre que les threads exécutent des transactions en parallèle, chacun gérant sa propre file d’attente locale. Les transactions sont assignées aléatoirement aux threads, puis triées localement selon les frais prioritaires et l’ordre chronologique. En l’absence d’un ordonnancement global côté scheduler (avant la mise à jour 1.18.x), les transactions sur Solana subissent essentiellement un non-déterminisme causé par les fluctuations du scheduler. Par conséquent, ni les chercheurs ni les validateurs ne peuvent fiablement connaître l’état courant dans le cadre de la MEVA.
Figure 8 : Modèle d’exécution multithread du client Solana. Notez que la phase de bundle MEVA est ajoutée comme thread indépendant aux files multithreads
D’un point de vue technique, intégrer le moteur de bloc de Jito comme thread supplémentaire en parallèle s’harmonise bien avec l’architecture multithread de Solana. Bien que l’enchère de bundles garantisse un ordre basé sur les frais prioritaires au sein du thread du moteur, elle ne peut assurer que les bundles soient toujours globalement prioritaires par rapport aux transactions utilisateur.
Pour pallier cela, Jito réserve à l’avance une partie de l’espace du bloc au thread des bundles, garantissant ainsi leur place dans le bloc. Bien que l’incertitude persiste, cette méthode augmente la probabilité de succès des stratégies. Cela incite également les chercheurs à participer aux enchères plutôt qu’à inonder le réseau de spams. En réservant de l’espace aux bundles, Jito parvient à équilibrer promotion d’enchères ordonnées et atténuation du chaos causé par les courriels transactionnels indésirables.
Suppression du pseudo-mempool
L’adoption massive de Jito a eu des effets positifs dans la réduction du problème de spam sur Solana. Selon une étude menée par l’équipe p2p et les données de la Figure 9, le taux relatif de production de blocs a nettement augmenté après l’adoption du client Jito. Cela indique que, grâce aux optimisations du moteur de bloc introduites par Jito en 2023, le traitement des transactions est devenu plus efficace.
Figure 9 : Preuves que Jito a efficacement atténué le problème de spam sur Solana. Graphique extrait d’une étude réalisée par l’équipe p2p
Bien que des progrès significatifs aient été accomplis, de nombreux défis persistent. Étant donné que les bundles Jito ne remplissent que partiellement les blocs, les transactions induites par la MEV peuvent encore contourner le canal d’enchères de Jito. Des indices se trouvent dans le tableau de bord Dune de la Figure 10, montrant qu’en moyenne, depuis 2024, plus de 50 % des transactions échouent en raison de bots spammeurs.
Figure 10 : Tableau de bord Dune sur l’activité de spam de bots sur Solana depuis mai 2022 (voir Dune)
Le 9 mars 2024, Jito a décidé de suspendre son mempool phare. Cette décision découle de la hausse des transactions liées aux memecoins et de l’explosion des attaques en sandwich (où les chercheurs placent des transactions avant et après une transaction cible), nuisant à l’expérience utilisateur. À l’instar des canaux privés de flux d’ordres sur Ethereum, la fermeture du mempool public pourrait favoriser la croissance des flux privés via des partenariats avec des services frontaux (tels que les fournisseurs de portefeuilles ou les robots Telegram). Les chercheurs pourraient désormais nouer directement des collaborations avec les validateurs pour obtenir des droits d’exécution, d’inclusion ou d’exclusion prioritaires.
En effet, la Figure 11 montre les profits horaires du principal chercheur de bundles privé après la fermeture du mempool.
Principal chercheur de mempool privé :
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
(Note du traducteur : un robot « sandwich » est un outil courant d’attaque de frontrunning utilisé principalement pour tirer profit des transactions sur blockchain.)
Figure 11 : Profits horaires du chercheur « 3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81 » utilisant un mempool privé
La décision de Jito de fermer son mempool reflète son engagement à résoudre les problèmes fondamentaux de l’écosystème Solana. Au-delà de l’itération de la MEVA ou de l’ajustement du mécanisme de frais de gaz de Solana, Jito aide les protocoles à réduire les risques d’attaques via des choix de conception de produits UI (par exemple, limitation des paramètres de slippage par défaut). Que ce soit par des ajustements tarifaires rendant le spam plus coûteux, ou par la modification des protocoles de communication,l’infrastructure de Jito continuera de jouer un rôle clé dans le maintien de la santé et de la stabilité du réseau Solana.
Conception de la MEVA sur Monad
Exécution différée et ses implications pour la MEVA
Contrairement à Ethereum, où valider un bloc requiert à la fois la liste des transactions (ordonnée) et la racine Merkle résumant tous les états post-exécution, Monad dissocie l’exécution précédente du consensus. Le protocole des nœuds doit uniquement résoudre le problème de l’ordre officiel. Comme illustré dans la Figure 12, chaque nœud exécute indépendamment les transactions du bloc N au moment où commence le consensus sur le bloc N+1. Cette disposition permet un budget de gaz correspondant à la durée complète d’un bloc, car l’exécution doit simplement suivre le rythme du consensus. Puisque aucun nœud leader n’a besoin de calculer la racine d’état finale, l’exécution peut exploiter toute la période de consensus pour traiter le bloc suivant.
Figure 12 : Comparaison entre l’exécution différée de Monad et le cycle consensus-exécution d’Ethereum. La fenêtre temporelle opérationnelle est également indiquée du point de vue de la conception MEVA
Nous définissons la fenêtre temporelle opérationnelle comme le cadre temporel autorisant la MEVA à proposer, sur Monad, la construction d’un bloc qui soit à la fois réalisable et rentable comparé à la méthode par défaut. Le modèle d’exécution différée a deux conséquences directes :
-
Pendant que la MEVA construit le bloc N dans la fenêtre temporelle opérationnelle, les validateurs parviennent à un accord sur la liste des transactions du bloc N tout en essayant de terminer l’exécution du bloc N-1. Ainsi, durant cette fenêtre opérationnelle, l’état potentiellement disponible pourrait encore être celui du bloc N-2. Cela signifie que, dans cette architecture à exécution différée, il n’est pas garanti que le relais ou le constructeur dispose de l’« état le plus récent ». Par conséquent, il est impossible de simuler contre l’état le plus récent avant la génération du prochain bloc, ce qui crée de l’incertitude.
-
Compte tenu du temps de bloc de 1 seconde sur Monad, la fenêtre temporelle opérationnelle de la MEVA est extrêmement limitée. Cela signifie que les constructeurs peuvent ne pas avoir suffisamment de temps pour simuler séquentiellement toutes les transactions et bundles d’un bloc complet, comme cela se fait habituellement sur Ethereum. De nombreux facteurs influencent le temps nécessaire pour simuler une transaction sur une EVM. Toutefois, en supposant qu’une simulation prenne entre 10¹ et 10² microsecondes (estimation approximative), et en visant 10⁴ transactions par seconde, la simple simulation d’un bloc complet pendant la fenêtre opérationnelle pourrait prendre environ 1 seconde. Étant donné le temps de bloc de 1 seconde sur Monad, il serait difficile pour un constructeur ou un relais de réaliser plusieurs simulations complètes pour optimiser la construction du bloc.
Stratégies probabilistes pour les constructeurs et chercheurs
Face à ces limitations, il est irréaliste de simuler complètement un bloc entier dans la fenêtre temporelle opérationnelle ou de simuler contre l’état le plus récent. Les constructeurs, désormais privés de temps et d’accès à l’état le plus récent, ne peuvent plus connaître avec certitude le résultat de chaque transaction. Ils doivent donc inférer les indications des chercheurs en fonction de la probabilité de rollback, en s’appuyant sur la réputation ou en simulant (si possible) contre l’état N-2. Cela rend l’évaluation du bloc moins certaine.
Faute de garantie théorique contre les rollbacks, une fois qu’un validateur accepte un bloc construit par un constructeur, les chercheurs font face à une plus grande incertitude d’exécution. Cela contraste avec Ethereum, où les chercheurs se disputent des flux d’ordres privés auprès des constructeurs, obtenant une exécution relativement déterministe de leurs stratégies. Dans ce cadre probabiliste relatif sur Monad, les chercheurs encourent désormais un risque accru de rollback de leurs bundles, entraînant un profil de profit/perte (PnL) plus incertain. Ce cas ressemble à celui des traders haute fréquence, qui exécutent des transactions sur la base de signaux probabilistes, accumulant progressivement un rendement légèrement supérieur en espérance.
Figure 13 : Un spectre conceptuel illustrant différents paradigmes de conception MEVA, classés selon le degré de vérification ou de simulation des blocs proposés
Comme le montre la Figure 13, le degré de vérification préalable (simulation de bundles/blocs) par les constructeurs crée un spectre d’incertitude dans l’évaluation ou la tarification des blocs proposés. À une extrémité, on trouve le modèle PBS à la manière d’Ethereum, avec une tarification précise : les constructeurs doivent utiliser un client de la couche d’exécution (EL) pour simuler les transactions du bloc proposé, naviguant dans une large combinatoire de bundles soumis. À l’autre extrémité, on trouve le modèle du constructeur optimiste [16], avec vérification asynchrone des blocs. Ici, les constructeurs contournent tout délai de simulation pendant la fenêtre opérationnelle, en déposant une mise (susceptible d’être confisquée) pour soutenir leurs propositions adressées aux validateurs ou relais. La méthode probabiliste ou de simulation partielle proposée ici pour Monad se situe entre les deux, augmentant malgré tout la probabilité de succès des chercheurs, même si une certaine incertitude subsiste.
Par exemple, un market maker sur une DEX à carnet d’ordres chainé pourrait, via la MEVA, anticiper un mouvement de prix unidirectionnel important en ajustant prématurément sa position pour éviter la sélection adverse. Une telle stratégie probabiliste leur permet d’agir rapidement, même sans information d’état à jour, en équilibrant risques et rendements dans un environnement transactionnel dynamique.
Conclusion
La MEVA joue un rôle crucial dans l’optimisation de la production de blocs, l’atténuation des externalités et l’amélioration de la stabilité du système. À mesure que les cadres MEVA évoluent — comme Jito sur Solana ou diverses implémentations sur Ethereum —, ils contribuent grandement à résoudre les problèmes de scalabilité et à aligner les incitations des participants au réseau.
Monad est un réseau prometteur en phase initiale, offrant à la communauté une opportunité unique de concevoir une MEVA optimale. Compte tenu du mécanisme unique de dissociation entre exécution et consensus de Monad, nous invitons chaleureusement chercheurs, développeurs et validateurs à collaborer et partager leurs idées. Cette collaboration aidera à créer un processus de production de blocs robuste et efficace, soutenant pleinement le potentiel de Monad en tant que blockchain haute performance.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@aprMEV
