Décryptage du MEV modulaire : comment réaliser un classement équitable des transactions ?
TechFlow SélectionTechFlow Sélection
Décryptage du MEV modulaire : comment réaliser un classement équitable des transactions ?
La raison pour laquelle on devrait adopter une architecture modulaire ne devrait pas simplement être de suivre une tendance, mais plutôt qu'elle permet de créer des applications meilleures, plus efficaces et plus personnalisables.
Dédié à des analyses Web3 approfondiesRédaction : Maven11
Traduction : Luffy, Foresight News
Dans les deux premières parties de cette série d'articles, nous nous sommes principalement concentrés sur les problèmes techniques liés à la décomposition de la pile et sur les améliorations nécessaires dans un monde modulaire. Nous avons déjà présenté de nombreux travaux en cours visant à résoudre les problèmes naturellement posés par les configurations inter-domaines. Toutefois, dans cette dernière partie de la série, nous souhaitons davantage nous attacher à l'expérience utilisateur. Nous voulons étudier comment la modularité, la personnalisation et la spécialisation peuvent aider à créer de meilleures applications. Ce dernier chapitre explorera les créations et possibilités passionnantes et uniques offertes par la modularité, permettant aux développeurs de concevoir des expériences utilisateur Web2 dotées de la vérifiabilité Web3.
La raison de construire autour de la modularité ne devrait pas être simplement de suivre une narration ou de faire de la modularité pour elle-même, mais parce qu'elle nous permet de construire des applications meilleures, plus efficaces et plus personnalisables. De nombreuses fonctionnalités uniques émergent lors de la construction de systèmes modulaires et spécialisés. Certaines sont évidentes, d'autres moins. Notre objectif est donc de présenter un aperçu des capacités des systèmes modulaires que vous ne connaissiez peut-être pas, comme l'évolutivité.
Nous pensons que l'une des capacités offertes aux développeurs par la modularité est la possibilité de construire des applications spécialisées hautement personnalisables, offrant ainsi une meilleure expérience aux utilisateurs finaux. Nous avons déjà discuté précédemment de la capacité à définir des règles ou à réorganiser l'ordre d'exécution des transactions.
Les règles de tri vérifiables (VSR) constituent l'une des opportunités intéressantes offertes par le contrôle du tri, notamment pour les développeurs souhaitant concevoir des systèmes de transactions « plus justes » en matière d'exécution. Bien entendu, la relation entre la perte face au fournisseur de liquidités et le rééquilibrage (LVR) dépasse le cadre de cet article, et nous éviterons donc d'aborder ce sujet en détail. Gardez à l'esprit que les mécanismes que nous allons expliquer concernent principalement les AMM plutôt que les modèles basés sur les carnets d'ordres. Par ailleurs, les CLOB (et même les CEX) bénéficieraient grandement de l'utilisation de règles de tri vérifiables adaptées à leurs configurations spécifiques. Dans un cadre hors chaîne, il faudrait clairement intégrer un concept d'exécution zéro-connaissance ou optimiste soutenu par une sécurité cryptoeconomique.
Le VSR devient particulièrement intéressant lorsque l'on considère que la majorité des investisseurs individuels n'ont pas encore (ni ne sont susceptibles de) recourir à des méthodes de protection. La plupart des portefeuilles et DEX n'ont pas non plus mis en œuvre de mempools privés, de RPC ou de solutions similaires. La plupart des transactions sont directement soumises via les interfaces frontales (qu'il s'agisse d'agrégateurs ou de l'interface d'un DEX). Ainsi, sauf si l'application interfère directement avec le traitement de ces flux et ordres, l'exécution obtenue par l'utilisateur final risque d'être loin d'être optimale.
Lorsque l'on examine où se situe le tri dans la chaîne d'approvisionnement des transactions, le rôle du VSR devient évident. Il intervient là où des acteurs spécialisés trient (ou incluent) les transactions, généralement selon une enchère ou des frais de base. Ce tri est crucial car il détermine quelles transactions seront exécutées et quand. En substance, celui qui détient le pouvoir de tri peut extraire de la MEV, généralement sous forme de frais prioritaires (ou « tips »).
Il pourrait donc être intéressant d'écrire des règles régissant le traitement du tri afin d'offrir aux utilisateurs finaux une exécution plus équitable des transactions (dans un contexte DEX). Toutefois, si vous développez un réseau généraliste, vous devriez éviter autant que possible de respecter de telles règles.
En outre, certaines formes de MEV sont importantes, comme l'arbitrage ou les liquidations. Une idée consiste à créer une voie rapide au sommet du bloc, réservée exclusivement aux arbitragistes et liquidateurs préautorisés, qui paient des frais plus élevés et partagent une partie de leurs revenus avec le protocole.
Dans l'article intitulé « Conception crédible d’échanges décentralisés via des règles de tri vérifiables », Matheus V., X. Ferreira et David C. Parkes proposent un modèle dans lequel le séquenceur du bloc est contraint par une série de règles d'exécution du tri (et ces contraintes sont vérifiables). En cas de non-respect de ces règles, un observateur peut générer une preuve de défaut (ou, puisque les contraintes sont mathématiquement vérifiables, on peut imaginer un circuit ZK intégrant ces contraintes, utilisant une preuve de connaissance nulle - ZKP - comme preuve de validité). L'idée principale est essentiellement d'offrir aux utilisateurs finaux (traders) une garantie sur le prix d'exécution. Cette garantie assure que le prix d’exécution de la transaction sera aussi bon que s’il était le seul dans le bloc (bien sûr, cela suppose un tri du type « premier arrivé, premier servi » pour achat/vente/achat/vente, impliquant un certain niveau de latence). L'idée fondamentale de la proposition dans l'article est que, si les prix d'exécution sont meilleurs que ceux disponibles au sommet du bloc, les règles de tri limiteront les validateurs (dans un scénario PBS) ou les séquenceurs à inclure uniquement des transactions dans la même direction (par exemple vente/vente). De plus, si une vente intervient à la fin d'une série d'achats (par exemple achat, achat, achat, vente), alors la vente ne sera pas exécutée, ce qui pourrait indiquer qu’un trader (ou un validateur/séquenceur) exploite ces achats pour faire évoluer le prix à son avantage. Cela signifie essentiellement que les règles du protocole garantissent que l'utilisateur ne sera pas utilisé pour offrir de meilleurs prix à d'autres (c'est-à-dire MEV), ni subir de glissement de prix dû aux frais prioritaires. Bien sûr, un inconvénient de ces règles (dans les cas où il y a plus de ventes que d'achats, ou inversement) est que l'utilisateur pourrait obtenir un prix relativement mauvais en queue de distribution.
Pour une plateforme de contrats intelligents générale, imposer ces règles comme contraintes purement internes à la chaîne est presque impossible, car vous ne pouvez pas contrôler l'exécution ni le tri. En outre, vous êtes en concurrence avec de nombreux autres participants, donc tenter de forcer ceux situés au sommet du bloc à payer des frais prioritaires serait inutilement coûteux. L'un des avantages de la configuration modulaire est qu'elle permet aux développeurs d'applications de personnaliser le fonctionnement de leur environnement d'exécution. Que ce soit les règles de tri, l'utilisation de machines virtuelles différentes ou des modifications personnalisées apportées aux machines existantes (comme ajouter de nouveaux opcodes ou modifier les limites de gaz), tout dépend en réalité du développeur et de son produit.
Dans un cas où un Rollup utilise une couche de disponibilité des données, une couche de consensus et une couche de règlement liquide, la configuration possible serait la suivante :
Une autre idée envisageable est la fragmentation des transactions. Imaginons un pool de transactions : comment exécuter efficacement une grosse commande (qui entraînerait un fort glissement) ? Si cette transaction est exécutée sur plusieurs blocs consécutifs (ou exécutée à la fin du bloc si conforme aux VSR), est-ce équitable pour l'utilisateur final ?
Si l'utilisateur final est sensible à la latence, il risque de ne pas vouloir que sa commande soit fragmentée. Toutefois, ce cas est rare, et optimiser la fragmentation des grandes commandes pourrait offrir une exécution bien plus efficace à la grande majorité des utilisateurs. Quoi qu’il en soit, un risque demeure : les chercheurs de MEV pourraient repérer ces transactions continues et chercher à placer leurs propres transactions juste avant ou après celles-ci. Néanmoins, en raison de la fragmentation en petites quantités sur plusieurs blocs, la valeur totale de MEV extraite pourrait être nettement réduite.
Un autre concept intéressant mentionné précédemment dans nos publications est l’utilisation des enchères fréquentes par lots (FBA), promues par Eric Budish et ses collègues, qui traitent les transactions par lots plutôt que de manière sérielle. Cela vise à faciliter la découverte de la convergence de la demande (CoW) et à intégrer les opportunités d’arbitrage dans la conception du mécanisme de marché. Cela contribue également à « contrer » les jeux de latence inhérents à la construction séquentielle de blocs (ou aux guerres de frais prioritaires dans les blocs sériels). Merci à Michael Jordan (DBA) d’avoir attiré notre attention sur cet article, ainsi que pour son travail dans l’atténuation de Latency Roast. Implémenter cela comme partie intégrante de la règle de sélection de fourchette et de tri d’un Rollup constitue également une configuration intéressante dont les développeurs peuvent se servir. Nous avons constaté un attrait marqué pour cette approche au cours de l’année écoulée, notamment chez Penumbra et CoWSwap. Une configuration possible serait la suivante :
Dans ce cadre, il n’y a ni priorité au « premier arrivé, premier servi » ni guerre de frais prioritaires ; au lieu de cela, un appel d’offres par lot est effectué à la fin de chaque intervalle de bloc selon les commandes accumulées.
De manière générale, dans un contexte où la majeure partie des transactions s’est déplacée vers un monde « on-chain » non gardé, les FBA pourraient représenter l’une des méthodes les plus efficaces de « vraie » découverte des prix, selon le temps de bloc. Utiliser les FBA signifie également que, puisque toutes les grosses commandes sont traitées par lots et ne sont pas divulguées avant la fin de l’enchère (sous réserve d’un dispositif cryptographique), le frontrunning est fortement réduit. Le prix de compensation uniforme est ici essentiel, car le réordonnancement des transactions n’a aucun sens.
Il convient également de noter qu’aussi tôt qu’en 2018, des conceptions similaires à celles que nous venons de présenter ont été discutées sur le forum Ethresear.ch (voir ici). Dans ce post, ils mentionnaient deux articles proposant un mécanisme d’enchères par lots sur Plasma (une sorte de prédécesseur des Rollups modernes), où chaque lot accepte des ordres d’achat d’autres jetons ERC20 à un prix maximum fixé. Ces ordres sont collectés pendant un intervalle de temps donné et un prix de compensation unique est établi pour toutes les paires de jetons. L’idée générale derrière ce modèle est qu’il permettrait d’éliminer le frontrunning courant dans les AMM populaires.
Un autre point important à souligner est que, dans ces configurations, les séquenceurs peuvent avoir besoin d’incitations pour exécuter (et appliquer) les règles susmentionnées. Ce point est souvent négligé, mais une grande partie de l’infrastructure des réseaux blockchain est exploitée par des entreprises spécialisées, dont les coûts sont très différents de ceux d’un participant domestique lambda. En général, les incitations constituent une composante essentielle de la mise en œuvre d’infrastructures sécurisées. Lorsque les incitations sont alignées avec les règles appliquées, les séquenceurs et validateurs sont plus enclins à fournir des efforts supplémentaires. Cela signifie que ces configurations devraient également comporter un marché actif. Bien sûr, ce genre de marché tend à la centralisation, car le coût de la spécialisation peut être élevé. Ainsi, les personnes les plus intelligentes (et les plus riches) pourraient s’unifier et se spécialiser afin de capter un maximum de valeur. Ici, l’accès exclusif au flux d’ordres peut devenir une flèche au genou pour certains participants, accentuant la centralisation. Des frais de base standards peuvent suffire, mais ils ne poussent pas vraiment les participants au tri vers la spécialisation. Vous pouvez donc envisager d’introduire des mécanismes d’incitation adaptés à votre cas spécifique, afin d’assurer la satisfaction des traders quant aux résultats.
Cela est assez clair pour la plupart, mais il est nécessaire de le mentionner lorsqu’on aborde le tri au niveau des Rollups. Si vous pouvez contrôler le tri, il devient plus facile de « capturer » la valeur du protocole. Cela découle du fait que vous contrôlez le pouvoir de réordonnancer les transactions, généralement basé sur les frais prioritaires (configuration similaire à MEV-boost) présents sur la plupart des L1. Cela vous donne accès aux frais prioritaires payés par des acteurs complexes sur la chaîne pour extraire de la valeur. Ces acteurs sont généralement prêts à payer des montants substantiels (jusqu’à ce que cela ne soit plus rentable). Pourtant, la plupart des Rollups utilisent actuellement un mécanisme « premier arrivé, premier servi ». La majorité de l’extraction de MEV s’effectue par guerre de latence, ce qui exerce une pression grave sur l’infrastructure des Rollups. Pour ces raisons, nous risquons d’observer de plus en plus de Rollups mettant en place des structures de tri intégrant des frais prioritaires (comme le mécanisme Time Boost d’Arbitrum).
Un autre exemple que nous apprécions est Uniswap. Actuellement, en tant que protocole, Uniswap « crée » une grande quantité d’inefficacités. Ces inefficacités sont exploitées par des acteurs cherchant à extraire de la MEV (via l’arbitrage, au détriment des fournisseurs de liquidité). Parallèlement, ces acteurs paient des frais importants pour extraire cette valeur, mais aucune de cette valeur ne revient au protocole Uniswap ni à ses détenteurs de jetons. Au contraire, une grande partie de cette valeur extraite est transférée aux validateurs d’Ethereum (proposers) via MEV-Boost sous forme de frais prioritaires, en échange du droit d’être inclus dans un bloc permettant de capter cette valeur. Ainsi, bien qu’il existe de nombreuses opportunités de MEV dans le flux d’ordres Uniswap, aucune n’est capturée par Uniswap lui-même.
Si Uniswap pouvait contrôler le tri au sein du protocole (ainsi que la capacité d’extraire des frais prioritaires auprès des chercheurs), il pourrait commercialiser cela, voire redistribuer une partie de ces profits aux détenteurs de jetons, aux fournisseurs de liquidité ou à d'autres parties. À mesure que Uniswap évolue (par exemple avec UniswapX) vers une exécution hors chaîne (et en utilisant Ethereum comme couche de règlement), un tel mécanisme semble de plus en plus probable.
En supposant un Rollup doté d’un mécanisme PBS partiel, le flux d’ordres et le processus de monétisation pourraient ressembler à ceci :
Ainsi, la monétisation du séquenceur et du validateur du Rollup pourrait suivre la formule suivante :
Production (PoS) + Revenus des frais (+priorité) – Coût de la DA, publication d’état, stockage
Un excellent moyen de visualiser la quantité de valeur actuellement extraite sur Ethereum (en particulier via l’arbitrage) est disponible sur Mevboost.pics, qui donne une bonne vue d’ensemble de la valeur réellement extractible à partir des inefficacités.
En outre, en séparant la guerre des frais prioritaires des structures hors chaîne, on isole l’extraction de MEV dans l’environnement d’exécution, ce qui aide à contenir les perturbations de la chaîne d’approvisionnement. Toutefois, si l’élection des leaders a lieu au niveau du Rollup, la majorité de la MEV sera extraite sur le Rollup, laissant peu de place à la couche inférieure, sauf si la couche DA inclut, ou si les frais prioritaires de la couche de règlement proviennent de l’intégration de liquidités ou d’autres économies d’échelle.
Il convient de préciser que bon nombre de ces structures peuvent fonctionner comme des entités purement hors chaîne, sans pont de validation ni garantie de sécurité forte. Toutefois, des compromis doivent être faits à cet endroit. Nous commençons à voir émerger davantage de ces solutions, qu’elles soient existantes ou invisibles. Je tiens à souligner un point : la configuration modulaire n’implique pas nécessairement un Rollup.
Les règles de tri susmentionnées illustrent un exemple où l’ajustement fin de l’infrastructure peut améliorer considérablement les applications construites dessus.
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
