L'ère de l'exécution parallèle arrive et le modèle MEV sur Monad est expliqué en détail

Auteur original : AVANT ⌘

Traduction originale : TechFlow

introduire

Dans le cadre de l'amélioration des performances de la blockchain pour les applications à grande échelle, Monad optimise efficacement le modèle de machine virtuelle Ethereum (EVM) grâce à une série de mesures d'optimisation sous-jacentes, telles que les E/S asynchrones, le Patricia Trie optimisé, l'exécution différée et le contrôle de concurrence optimiste. Ces améliorations résolvent les goulots d'étranglement de l'exécution et les problèmes d'accès inefficace à l'état sur des plateformes telles qu'Ethereum sans sacrifier la décentralisation.

Cet article explore la possibilité de créer une puissante infrastructure d'enchères de valeur extractible par les mineurs (MEVA) sur Monad, en s'appuyant sur l'expérience précieuse de Flashbots sur Ethereum et de Jito Network sur Solana.

Nous tenons à souligner quelques points essentiels :

• La MEV est une caractéristique inhérente à tout réseau blockchain. Une infrastructure MEVA solide est essentielle pour éviter les externalités négatives et le désalignement des incitations dans le processus de production de blocs.

• La conception de MEVA est étroitement liée aux mécanismes sous-jacents de la blockchain, en particulier à la phase d'exécution du consensus. Les améliorations futures dépendront de l'évolution de ces facteurs et de la façon dont le réseau se comporte sous différentes contraintes.

• Les tendances historiques de la production de blocs sur Ethereum et Solana peuvent servir de référence pour la conception de MEVA sur Monad.

• Sur une blockchain à hautes performances et à exécution différée comme Monad, MEVA peut nécessiter une construction de blocs probabiliste et une stratégie de recherche similaire au trading haute fréquence pour faire face aux contraintes de temps.

En explorant ces questions, nous espérons fournir des éclairages pour la conception d’une infrastructure MEVA qui répond aux exigences architecturales et de performance uniques de Monads.

Contexte MEVA dans Ethereum

MEVA dans la phase d'exécution du consensus Ethereum

Dans Ethereum, le consensus nécessite d'abord l'exécution. Lorsque les nœuds se mettent d'accord sur un bloc, ils se mettent d'accord non seulement sur la liste des transactions du bloc, mais également sur la racine Merkle qui est résumée après l'exécution du bloc. Par conséquent, le proposant doit exécuter toutes les transactions du bloc avant de propager la proposition. Dans le même temps, les nœuds de validation doivent également exécuter ces transactions avant de voter.

Figure 1 : Flux de travail du constructeur pour la séparation proposant-constructeur (PBS) dans MEV-Boost

La figure 1 montre un flux de travail de création typique pour la séparation Proposer-Builder (PBS) dans MEV-Boost. Une fois que le créateur a terminé la construction du bloc, il le soumet au relais, qui transmet ensuite le bloc au client de la couche d'exécution (EL) pour simulation et vérification de la validité.

L'exécution étant une condition préalable au consensus, lorsqu'un constructeur construit un bloc, il doit transmettre le bloc au client de la couche d'exécution (EL) et simuler le bloc pour vérifier sa validité. En plus de son rôle nécessaire dans la phase d'exécution du consensus, la phase de simulation apporte également des avantages aux constructeurs et aux chercheurs.

Du point de vue des constructeurs : en simulant chaque transaction, le constructeur peut estimer avec précision la valeur du bloc pour lui-même et pour les validateurs. Il peut également essayer de réorganiser les transactions pour minimiser les retours en arrière et maximiser les frais de gaz ou les pourboires de base extraits du pool de mémoire et des transactions groupées. Des estimations précises leur permettent de proposer des prix plus élevés aux validateurs.

Du point de vue du chercheur : comme les constructeurs éliminent les transactions groupées qui peuvent être annulées avant que la transaction ne soit placée sur la chaîne, le chercheur peut garantir l'exécution de la stratégie, ce qui augmente la certitude. En outre, le chercheur peut également accéder au dernier statut du bloc. Lorsque la couche de consensus (CL) propage un nouveau bloc, le chercheur peut utiliser l'état du bloc comme point de départ pour créer une transaction groupée rentable. Dans le même temps, certains signes indiquent que les constructeurs fournissent désormais davantage de transactions ou de fonctions hors protocole qui permettent aux chercheurs d'obtenir les informations sur l'état du bloc à créer afin que la stratégie de retour en arrière puisse être ajoutée au bloc à placer sur la chaîne.

Cependant, le développement du PBS a conduit à une centralisation accrue de la construction de blocs, de la même manière que les entreprises se disputent les canaux de réseau micro-ondes dédiés dans le trading traditionnel pour donner la priorité à l’exécution des stratégies d’arbitrage.

À mesure que le réseau mûrit, les produits évoluent

Nous explorons maintenant comment MEVA a évolué à mesure qu’Ethereum s’est développé, comme le montre la figure 2.

Figure 2 : Une vue chronologique du développement de MEVA avec le réseau Ethereum

L'ère des enchères prioritaires sur le gaz (PGA)

Les chercheurs identifient les opportunités MEV rentables et soumettent les transactions de contrats intelligents au mempool public, comme le montre la figure 3. Cette visibilité publique conduit à des enchères ouvertes et à des enchères au premier prix sur la chaîne, où même les transactions échouées entraînent des frais de gaz.

Cette période a été marquée par une activité MEV non structurée hautement compétitive et coûteuse, comme des transactions avec des paires identiques (compte, annonce) et des enchères croissantes, entraînant une congestion du réseau ou une instabilité du consensus.

Figure 3 : Diagramme simple d'enchères de gaz prioritaire

Flashbots et EIP-1559

Pour résoudre ces problèmes, Flashbots a introduit des relais comme maisons de vente aux enchères intermédiaires entre les chercheurs et les producteurs de blocs (les mineurs à l'ère du PoW). Cette initiative a transformé le marché MEV d'une enchère ouverte à prix unique en une enchère scellée. Comme le montre la figure 4, les relais aident à empêcher l'escalade des enchères dans le pool de mémoire publique et à établir un processus de production de blocs plus ordonné et plus sécurisé.

La structure tarifaire de l'EIP-1559 entre également en jeu ici. Elle simplifie les enchères via des frais de base, mais ne résout pas le problème de l'ordre des transactions au sein d'un bloc, qui continue de stimuler le MEV via des frais de priorité. En fait, de nombreux chercheurs enchérissaient auparavant directement auprès des mineurs via des transferts Coinbase. Ils ont fini par recevoir davantage de plaintes concernant les frais Coinbase car ils ne pouvaient plus soumettre de transactions groupées sans gaz.

Figure 4 : MEVA avec relais

Séparation du proposant et du constructeur (PBS)

Après qu'Ethereum a terminé la fusion et est passé à la preuve d'enjeu (PoS), la séparation des proposants et des constructeurs (PBS) a été mise en œuvre pour optimiser davantage la séparation des rôles dans le pipeline de production de blocs. Comme mentionné précédemment, les relais agissent désormais comme intermédiaires entre les constructeurs de blocs et les proposants, chargés de garantir la disponibilité des données et la validité des blocs. Étant donné que les proposants peuvent connecter plusieurs constructeurs pour 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 du PBS

Risque de concentration

Malgré ces avancées historiques, il convient de souligner le risque croissant de concentration sur le marché des constructeurs. Au cours de l’année écoulée, les 9 premiers constructeurs ont constamment représenté plus de 50% de parts du marché, ce qui démontre un degré élevé de concentration du marché, comme le montre la figure 6. L’état actuel de concentration est encore plus prononcé, les trois premiers constructeurs couvrant plus de 90% de blocs.

Figure 6 : Part de marché des constructeurs, montrant la forte concentration qui prévaut sur le marché des constructeurs (Image source )

Jito sur Solana

Architecture du système Jitos

En tant que MEVA standard sur Solana, Jito a été créé pour répondre au niveau élevé de spam de Solana en raison des faibles coûts de transaction. Tant que les frais pour les transactions échouées (environ 0,000005 SOL) ne dépassent pas le profit attendu, le spam est effectivement encouragé.

Selon un rapport de Jito Labs de 2022, plus de 961 TP9T de tentatives d'arbitrage et de liquidation ont échoué cette année-là, et plus de 501 TP9T de transactions liées à MEV ont été incluses dans les blocs. Le rapport souligne également que les robots de liquidation ont envoyé des millions de paquets en double au réseau juste pour réaliser quelques milliers de liquidations réussies, ce qui a entraîné un taux d'échec de plus de 991 TP9T.

Figure 7 : MEVA de Jito sur Solana

La gravité du problème d'externalité MEV sur Solana a incité Jito à développer une couche MEVA conçue pour apporter de l'ordre et de la certitude au processus de production de blocs. Examinons l'architecture MEVA originale proposée par Jito, comme illustré dans la figure 7.

Jito possède les composants suivants :

Relais – Agit comme un proxy pour recevoir les transactions et les transmettre au moteur de blocs (ou à la chaîne d'approvisionnement MEVA) et aux validateurs.

Moteur de blocs – Reçoit les transactions des relais, coordonne les chercheurs, accepte les lots, effectue une simulation de lots et transmet les meilleures transactions et lots aux validateurs pour traitement. Notamment, Jito effectue des enchères de blocs partiels pour inclusion dans des lots, plutôt que des enchères de blocs complets, et a historiquement traité plus de 80% de lots dans deux créneaux.

Pseudo pool de mémoire – Crée une fenêtre d'opération d'environ 200 ms via le client Jito-Solana, déclenchant une enchère discrétisée du flux d'ordres. Jito a fermé ce pool de mémoire le 9 mars 2024.

Les choix de conception de Jito

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

Jito ne prend en charge que les enchères de blocs partiels, et non la construction de blocs complets, probablement en raison du manque de planification globale du modèle d'exécution multithread de Solana. Plus précisément, la figure 8 montre des threads parallèles exécutant des transactions, chaque thread conservant 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 triées localement par priorité, frais et heure. Sans tri global côté planificateur (avant la mise à jour 1.18.x), les transactions de Solana sont intrinsèquement sujettes au non-déterminisme en raison de la gigue du planificateur. Par conséquent, dans MEVA, il n'existe aucun moyen pour un chercheur ou un validateur de déterminer de manière fiable l'état actuel.

Figure 8 : Modèle d'exécution multithread du client Solana. Notez que la phase de regroupement de MEVA est ajoutée à la file d'attente multithread en tant que thread distinct.

D'un point de vue technique, l'exécution du moteur de blocs de Jito en parallèle en tant que thread supplémentaire s'intègre parfaitement à l'architecture multithread de Solana. Bien que les enchères groupées garantissent un classement prioritaire basé sur des frais au sein du thread du moteur de blocs Jito, rien ne garantit que les bundles seront toujours prioritaires au niveau mondial par rapport aux transactions utilisateur.

Pour résoudre ce problème, Jito pré-alloue une partie de l'espace de bloc au thread de bundle, garantissant ainsi que le bundle dispose d'un espace dans le bloc. Bien que l'incertitude persiste, cette approche augmente la probabilité d'une exécution réussie de la stratégie. Elle incite également les chercheurs à participer à l'enchère au lieu de spammer le réseau. En réservant de l'espace de bloc pour les bundles, Jito est en mesure de trouver un équilibre entre la promotion d'enchères ordonnées et l'atténuation des effets perturbateurs du spam de transaction.

Supprimer le faux pool de mémoire

L'adoption généralisée de Jito a donné des résultats positifs dans la réduction du problème de spam sur Solana. Selon les recherches p2p et les données présentées dans la figure 9, la productivité relative des blocs a considérablement augmenté après l'adoption du client Jito. Cela suggère que le traitement des transactions est devenu plus efficace grâce au moteur de blocs optimisé introduit par Jito en 2023.

Figure 9 : Preuve que Jito atténue efficacement les problèmes de spam sur Solana. Cette figure est tirée d'une étude menée par l'équipe p2p

Bien que des progrès significatifs aient été réalisés, de nombreux défis demeurent. Étant donné que les bundles Jito ne remplissent que partiellement les blocs, les transactions induites par MEV peuvent toujours contourner le canal d'enchères Jito. On peut en trouver la preuve dans le tableau de bord Dune de la figure 10, qui montre que depuis 2024, le réseau enregistre toujours en moyenne plus de 501 échecs de transaction TP9T dus au spam de bots.

Figure 10 : Tableau de bord Dune de l'activité de spam des robots sur Solana depuis mai 2022 (voir Dune pour plus de détails)

Le 9 mars 2024, Jito a décidé de suspendre son pool de mémoire phare. Cette décision était due à une augmentation de la croissance des transactions de memecoin et aux attaques sandwich qui ont suivi (les chercheurs plaçant des transactions avant et après une transaction cible), qui ont finalement affecté l'expérience utilisateur. À l'instar des canaux de flux d'ordres privés MEVA sur Ethereum, la fermeture du pool de mémoire publique peut favoriser la croissance du flux d'ordres privés grâce à la coopération avec des services frontaux tels que les fournisseurs de portefeuilles et les robots Telegram. Les chercheurs peuvent établir des partenariats directs avec les validateurs pour obtenir des droits d'exécution, d'inclusion ou d'exclusion prioritaires.

En fait, la figure 11 montre les bénéfices horaires de Sandwichbot des plus grands chercheurs de mempool privés après la fermeture du mempool.

Le plus grand moteur de recherche de pool de mémoires privé :

3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81

(Note du traducteur : le robot sandwich est un outil d’attaque de premier plan courant, principalement utilisé pour réaliser des bénéfices dans les transactions blockchain).

Figure 11 : Bénéfices horaires du bot Sandwich utilisant des pools de mémoire privés pour le chercheur « 3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81 »

La décision de Jito de fermer le pool de mémoires démontre l'engagement de l'équipe à résoudre les problèmes fondamentaux de l'écosystème Solana. En plus d'itérer sur MEVA ou d'ajuster le mécanisme de frais de gaz de Solana, Jito aide également le protocole à réduire le risque d'attaques grâce à des choix de conception de produits d'interface utilisateur tels que la limitation des paramètres de glissement par défaut. Que ce soit par des ajustements de la structure des frais qui rendent les transactions de spam plus coûteuses ou par des modifications des protocoles de communication, l'infrastructure de Jito continuera à jouer un rôle clé dans le maintien de la santé et de la stabilité du réseau Solana.

MEVA Design sur Monad

Retard d'exécution et son impact sur MEVA

Contrairement à Ethereum, où l'accord sur un bloc nécessite une liste de transactions (avec ordre) et une racine de Merkle résumant tous les états post-facto, Monad dissocie l'exécution antérieure du consensus. L'accord des nœuds n'a besoin que de résoudre le problème de l'ordre officiel. Comme le montre la figure 12, chaque nœud exécute indépendamment les transactions du bloc N lorsqu'il commence le consensus sur le bloc N+1. Cet arrangement permet un budget de gaz correspondant à un temps de bloc complet, puisque l'exécution n'a besoin que de suivre le consensus. Comme il n'est pas nécessaire qu'un nœud leader calcule une racine d'état factuel, l'exécution peut utiliser toute la période de consensus pour traiter le bloc suivant.

Figure 12 : Comparaison de l'exécution différée de Monad et de la phase d'exécution-consensus d'Ethereum. La fenêtre de temps d'opération est également présentée du point de vue de la conception MEVA.

Nous définissons la fenêtre de temps opérationnelle comme le délai qui permet à MEVA de réaliser une proposition de construction de blocs sur la Monade qui soit viable et rentable par rapport à la méthode de construction de blocs par défaut. Le modèle d'exécution différée a deux conséquences directes :

• Lorsque MEVA est construit pour le Nième bloc dans la fenêtre de temps d'opération, les validateurs parviennent simultanément à un consensus sur la liste de transactions du Nième bloc tout en essayant de terminer l'exécution du N-1ième bloc. Par conséquent, dans la fenêtre de temps d'opération N, l'état disponible peut toujours être dans le N-2ième. Cela signifie que dans cette architecture d'exécution différée, il n'y a aucune garantie que le relais ou le constructeur dispose de l'état le plus récent. Par conséquent, il est impossible de simuler par rapport au dernier bloc avant que le bloc suivant ne soit généré, ce qui entraîne une incertitude.

• Étant donné le temps de bloc de 1 seconde de Monads, la fenêtre de temps de fonctionnement de MEVAs est extrêmement limitée. Cela signifie que les constructeurs peuvent ne pas avoir suffisamment de temps pour simuler un bloc complet de transactions et de bundles en séquence, comme cela se fait généralement sur Ethereum. De nombreuses variables peuvent affecter le temps nécessaire pour simuler une transaction sur l'EVM. Cependant, en supposant que la simulation d'une transaction prend 10^1 à 10^2 microsecondes (une estimation approximative) et que Monad vise 10^4 transactions par seconde, la simulation d'un bloc complet dans la seule fenêtre de temps de fonctionnement peut prendre environ 1 seconde. Étant donné le temps de bloc de 1 seconde de Monads, il serait difficile pour un constructeur ou un relais d'effectuer plusieurs simulations de blocs complets pour optimiser la construction d'un bloc.

Stratégies de création et de recherche de probabilités

Compte tenu de ces contraintes, il est impossible de réaliser des simulations de blocs complets dans la fenêtre de temps opérationnelle et de simuler par rapport à l'état le plus récent. Étant donné que les constructeurs n'ont désormais ni le temps ni l'état le plus récent pour connaître le sommet exact de chaque transaction, ils doivent déduire le sommet du chercheur en fonction de la probabilité d'annulation de la transaction, en s'appuyant sur la réputation ou (probablement au mieux) en simulant par rapport à l'état N-2. Cela rend les évaluations de blocs moins certaines.

En raison du manque de garanties théoriques sur les annulations de transactions, les chercheurs sont confrontés à une plus grande incertitude d'exécution une fois que les validateurs acceptent un bloc construit par un constructeur. Cela contraste avec Ethereum, où les chercheurs rivalisent dans des canaux privés dédiés de flux d'ordres vers les constructeurs pour exécuter des stratégies relativement déterministes. Dans ce cadre relativement probabiliste sur Monad, les chercheurs sont désormais confrontés à un risque plus élevé d'annulation de paquets, ce qui entraîne un profil PnL d'exécution plus incertain. Cela est similaire aux traders à haute fréquence qui exécutent des transactions sur la base de signaux probabilistes et obtiennent des rendements attendus légèrement plus élevés au fil du temps.

Figure 13 : Un spectre conceptuel montrant différents paradigmes de conception MEVA, classés en fonction du degré auquel les blocs proposés sont vérifiés ou simulés.

Comme le montre la figure 13, le degré de vérification préalable des bundles/blocs de la part du constructeur crée un spectre d'incertitude dans la tarification ou la valorisation des blocs proposés. À une extrémité se trouve le modèle PBS de style Ethereum avec une tarification précise, où les constructeurs doivent simuler des transactions dans les blocs proposés à l'aide d'un client de couche d'exécution (EL). Ils doivent parcourir une large gamme de combinaisons dans les bundles qu'ils soumettent. À l'autre extrémité se trouve le modèle de constructeur optimiste [16] avec vérification de bloc asynchrone. Dans ce modèle, les constructeurs contournent le temps requis pour toute simulation dans la fenêtre de temps de fonctionnement et honorent les conseils montrés aux validateurs ou aux relais en déposant des garanties (qui peuvent être réduites). L'approche de vérification probabiliste ou de simulation partielle proposée ici sur Monad se situe au milieu, augmentant la probabilité que le chercheur exécute avec succès sa stratégie malgré une certaine incertitude.

Par exemple, un teneur de marché sur un DEX à carnet d'ordres en chaîne peut déplacer ses positions de manière préventive via MEVA dès qu'il détecte des mouvements de prix unidirectionnels majeurs afin d'éviter une sélection adverse. Cette stratégie probabiliste leur permet d'agir rapidement, même sans les dernières informations sur l'état, en équilibrant le risque et la récompense dans un environnement de trading dynamique.

Conclusion

MEVA joue un rôle clé dans l'optimisation de la production de blocs, l'atténuation des influences externes et l'amélioration de la stabilité du système. Avec le développement continu du framework MEVA, comme Jito sur Solana et diverses implémentations sur Ethereum, il a grandement contribué à résoudre les problèmes d'évolutivité et à rendre le mécanisme d'incitation des participants au réseau plus cohérent.

Monad est un réseau prometteur qui en est à ses débuts et qui offre à la communauté une opportunité unique de concevoir le meilleur MEVA possible. Compte tenu de la séparation unique de l'exécution et du consensus de Monad, nous invitons les chercheurs, les développeurs et les validateurs à collaborer et à partager leurs idées. Cette collaboration contribuera à créer un processus de production de blocs robuste et efficace, aidant ainsi Monad à concrétiser sa promesse en tant que réseau blockchain à haut débit.

Cet article provient d'Internet : L'ère de l'exécution parallèle arrive et le modèle MEV sur Monad est expliqué en détail

En relation : Observation hebdomadaire d'EMC Bitcoin (du 10 au 16 juin) : La période d'attente pour les baisses de taux d'intérêt pourrait être prolongée, et il y a

Rédigé par : Shang2046 Les informations, opinions et jugements sur les marchés, projets, devises, etc. mentionnés dans ce rapport sont fournis à titre indicatif uniquement et ne constituent aucun conseil d'investissement. L'offre et la demande du marché sont fragiles et le BTC est confronté à la liquidation des mineurs Résumé du marché : La réunion de la Fed sur les taux d'intérêt du 12 juin et les données de l'IPC américain pour mai sont en effet devenus les facteurs dominants de la tendance du BTC la semaine dernière. Stimulé par la tendance à la baisse des données de l'IPC, le BTC a de nouveau atteint la barre des $70 000, mais a ensuite chuté rapidement en raison des remarques agressives de la Fed. Le BTC a chuté de 4,32% sur toute la semaine, avec une amplitude de 7,44%. Le graphique à points de la baisse des taux d'intérêt montre que la plupart des attentes du marché sont que la baisse des taux d'intérêt sera reportée à la fin de la…