Introduction

La prise en charge de la valeur extractible maximale (MEV) est un défi permanent pour Ethereum ; la chaîne d'approvisionnement de valeur incite les arbitragistes à une activité constante avec des stratégies diverses de niveaux de sophistication variables, souvent au détriment des utilisateurs de détail. Bien que de nombreux chercheurs aient tenté de résoudre le problème du MEV par le biais de modifications au niveau du protocole, ces efforts n'ont pas encore fourni de solution satisfaisante. Les infrastructures canoniques et les mécanismes d'enchères actuellement utilisés sont capables de capturer de manière compétitive la valeur MEV en bloc, mais la capture sans redistribution équitable est insuffisante : pourquoi la valeur MEV devrait-elle revenir aux validateurs du réseau alors qu'elle peut être capturée et internalisée de manière plus efficace sur une base d'application par application ?

Entrer dans le Séquençage Spécifique à l'Application (ASS). Plutôt que d'essayer de réécrire les règles au niveau du protocole, ASS donne aux applications individuelles le pouvoir de prendre le contrôle de la séquence de leurs transactions. Ce faisant, ASS permet aux applications onchain de protéger leurs utilisateurs et leur liquidité des effets nocifs du MEV tout en leur offrant également la possibilité de capturer de la valeur qui serait autrement perdue pour les validateurs d'Ethereum.

Imaginez le potentiel : au lieu que des traders à haute fréquence se disputent pour arbitrer au maximum chaque utilisateur (avec presque toute la valeur arbitrée fuyant vers les validateurs et donc les chaînes sous-jacentes), chaque application pourrait définir ses propres règles pour l'ordonnancement des transactions, créant ainsi un système plus adapté, efficace et équitable pour ses propres utilisateurs. Cela marque un changement, passant de la tentative de résoudre le MEV au niveau du réseau à son traitement là où cela importe le plus—l'application elle-même.

Contexte

Le concept de séquençage spécifique à l'application (ASS) est issu des travaux de Matheus sur le Règle de séquençage vérifiable (VSR) pour les échanges décentralisés (DEXes). Matheus a démontré que VSR pouvait améliorer l’exécution des transactions et mitiGate MEV en réduisant l’influence des mineurs sur l’ordre des transactions. Tarun plus tard développé cette idéeen montrant comment les règles de séquençage spécifiques à une application pourraient affecter significativement les fonctions de rémunération pour les participants du protocole, tels que les utilisateurs, les validateurs et les séquenceurs.

Ici, la fonction de gain représente la valeur économique d’un ordre de transaction particulier. Cette valeur reflète le profit ou l’utilité gagnée par les participants au protocole, ce qui montre l’impact de l’ordre des transactions sur leurs résultats financiers. Il y a deux caractéristiques essentielles des fonctions de paiement :

1. Payoffs non lisses : De petits changements d'ordre peuvent entraîner de grands changements dans la MEV.
2. Les retours non monotones : De petits changements dans l'ordre peuvent soit augmenter soit diminuer MEV, mais pas de manière cohérente dans une direction.

Lorsque les fonctions de paiement présentent ces deux caractéristiques, l'optimisation de la stratégie de séquençage devient très complexe. Dans de tels cas, des approches plus sophistiquées et sur mesure sont nécessaires, au niveau de l'application, pour garantir des résultats équitables pour les utilisateurs et un écosystème DeFi durable.

Comment fonctionne ASS ?

Pour comprendre ASS, commençons par passer en revue la chaîne d'approvisionnement transactionnelle existante.

Dans le système actuel:

1. Les transactions sont envoyées aux mempools publics ou privés.
2. Les constructeurs collectent ces transactions et les regroupent en blocs.
3. Les constructeurs concourent ensuite lors d'une vente aux enchères de blocs.
4. Le bloc du constructeur gagnant est inclus dans la blockchain et la valeur qu'ils ont enchérie est versée au proposant choisi pour le bloc donné.

La figure ci-dessous illustre ce processus, montrant comment les transactions circulent des mempools vers la blockchain via les constructeurs et les relais de confiance.

Diagramme de la chaîne d'approvisionnement actuelle des transactions

Les applications activées par ASS, en revanche, présentent les propriétés suivantes:

1. Droits de séquençage restreints : cette restriction garantit que seul un séquenceur désigné ou des validateurs jalonnés peuvent interagir avec le contrat de l’application sur la chaîne à laquelle il s’installe, empêchant ainsi le contournement néfaste de la logique de l’application pour la redistribution interne de la valeur.
2. Mempools spécifiques à l'application : Au lieu de soumettre des transactions à un mempool public, les utilisateurs envoient des messages signés exprimant leur intention à un mempool spécifique à l'application. Ces intentions sont ensuite collectées et traitées par le séquenceur spécifique à l'application.
3. Résultats indifférents de l'ordre: Pour appliquer la règle de séquençage et offrir les avantages économiques optimaux aux utilisateurs cibles, les transactions ASS doivent être indifférentes à l'ordre des transactions des constructeurs pour le reste du bloc. Cela est réalisé en veillant à ce que l'état de l'application soit soumis à son mécanisme de consensus. Les commandes ASS sont ensuite regroupées dans un seul ensemble qui est envoyé aux constructeurs pour inclusion. Étant donné que cet ensemble ne pose pas de problème avec l'état consulté par d'autres applications, il est indifférent à sa position dans le bloc.

L’ASS permet aux applications de n’importe quelle chaîne de retrouver la souveraineté sur son état d’exécution et de contrat, ce qui permet aux applications souveraines.

En tenant compte de ces principes fondamentaux, prenons Angstrom comme exemple pratique d'une application souveraine. Angstrom est un crochet UniswapV4 qui protège ses fournisseurs de liquidité contre la sélection adverse des arbitragistes CEX-DEX, tout en protégeant également les échangeurs des attaques sandwich. Un réseau de nœuds Angstrom parvient à un consensus, en parallèle d'Ethereum, sur l'ensemble des transactions à exécuter dans le prochain bloc. Le flux général est le suivant:

1. Les arbitragistes CEX-DEX enchérissent pour avoir le droit d'être la première transaction à échanger via l'AMM (sans frais). Pendant ce temps, les utilisateurs envoient leurs échanges prévus sous forme d'ordres limités signés à la file d'attente de la mémoire Angstrom.
2. Le réseau Angstrom exécute son protocole de consensus et forme un bundle où le premier échange est la transaction d'arbitrage avec l'offre la plus élevée. Le montant de l'offre est ensuite réparti, au prorata, aux fournisseurs de liquidité sous-jacents dans la plage d'échange. Toutes les autres limites d'ordre valides, ainsi que la liquidité sous-jacente de l'AMM, sont exécutées au même prix uniforme de compensation.
3. Ce bundle est ensuite envoyé aux constructeurs Ethereum et à la mempool publique par le nœud Angstrom proposant pour la fente.
4. Les constructeurs incluent le bundle Angstrom à n'importe quelle position dans le bloc. Le bundle doit simplement payer les frais de base pour son inclusion en raison de sa construction non-ordonnée.

Le diagramme suivant illustre l'application souveraine en action.

La chaîne d'approvisionnement de transaction dans Angstrom

Vivacité et présomption de confiance

Au cœur de ASS se trouve une forme de construction de bloc partiel où une application souveraine délègue les droits de séquençage à un réseau décentralisé d'opérateurs suivant une règle de séquençage prescrite. Par conséquent, ASS implique inévitablement des parties externes qui introduisent des hypothèses de vivacité et de confiance supplémentaires.

Hypothèse de vivacité

Les applications souveraines dépendent de séquenceurs spécifiques à l'application pour suivre correctement le protocole et fournir des mises à jour d'état en temps opportun. En cas de violation de la continuité des opérations, telle qu'une partition de réseau, les utilisateurs peuvent être incapables d'interagir avec certaines parties de l'application jusqu'à ce que le consensus valide soit rétabli.

Les applications souveraines peuvent également limiter la portée de l'état du contrat dont les mises à jour dépendent de leurs séquenceurs. Cela aide à minimiser les dépendances externes du contrat de sorte que des états critiques, tels que la liquidité déposée, restent accessibles même en cas de défaillance du séquenceur.

Supposition de confiance

Pour s’assurer que les séquenceurs respectent les règles de séquençage prescrites, les applications souveraines peuvent tirer parti de solutions cryptoéconomiques (telles que PoS) ou de méthodes cryptographiques (telles que TEE ou MPC). L’approche spécifique peut varier considérablement en fonction des besoins de l’application ; Certains peuvent nécessiter un consensus sur l’optimalité de l’exécution, tandis que d’autres peuvent se concentrer sur la garantie de la confidentialité avant l’exécution par le biais de mécanismes cryptographiques. Il existe de nombreux outils permettant de réduire la surcharge de confiance des séquenceurs et de répondre aux objectifs uniques de chaque application souveraine.

Résistance à la censure

Il existe différents types de censure qui affectent l'écosystème Ethereum :

1. Censure réglementaire : Les constructeurs et les relais censurent les transactions en fonction de la liste des sanctions de l'OFAC. Il s'agit de l'une des formes de censure les plus importantes présentes sur Ethereum aujourd'hui.principalement appliquée par des relais.
2. Censure économique: Un attaquant motivé peutsoudoyer le proposant de bloc pour censurer les transactions de la victime.
3. Censure au niveau des nœuds : les nœuds du réseau P2P peuvent refuser de propager les transactions entrantes. Cela peut être un problème majeur si le protocole fonctionne de manière optimale en supposant que la majorité des nœuds partagent la même vue des transactions entrantes. De plus, dans de tels protocoles, un adversaire peut être incité à partitionner les vues locales des nœuds honnêtes (en envoyant une transaction à seulement la moitié des nœuds à la toute fin d’un emplacement) et à arrêter le protocole en conséquence.

De nombreux chercheurs ont exprimé la nécessité d’un meilleur mécanisme de résistance à la censure sur Ethereum. Certaines propositions, comme Multiple Concurrent Proposer (MCP) et Liste d’inclusion appliquée par Fork-Choice (FOCIL), ont fait surface et sont devenus le centre d’une discussion en cours.

La résistance à la censure est également une préoccupation majeure pour l’application souveraine. Les séquenceurs spécifiques à l’application sont probablement des entités externes ayant divers intérêts à recevoir des transactions privées et des flux d’ordres supplémentaires. Par exemple, un validateur spécifique à une application qui est un teneur de marché est incité à censurer les transactions envoyées par des teneurs de marché concurrents. L’application souveraine sur le dessus peut ainsi subir une censure locale même si le protocole de base n’est pas censurant.

Un exemple de mécanisme de résistance à la censure pour ASS est Angstrom. Pour garantir que toutes les commandes valides sont incluses dans le créneau à venir, les nœuds Angstrom doivent diffuser toutes les commandes entrantes vérifiées et parvenir à un consensus sur leur inclusion dans le bundle de transactions proposé. Si le bundle ne contient pas les commandes observées par la majorité du réseau, le proposeur sera pénalisé. Voici une illustration du mécanisme de résistance à la censure pour Angstrom.

Résistance à la censure dans une application souveraine décentralisée

Le dilemme de la composabilité

Un des principaux défis auxquels sont confrontées les applications souveraines est de garantir la compositionnalité avec les transactions qui interagissent avec les états de contrat externes. Le regroupement simple de transactions spécifiques à l'application avec des transactions externes arbitraires compromet la propriété sans ordre qui est nécessaire pour protéger l'application souveraine et ses utilisateurs. Une seule transaction non-ASS invalide, lorsqu'elle est composée avec une transaction spécifique à l'application, peut avoir l'effet de deuxième ordre de revenir sur l'ensemble du lot. Lorsque cela se produit, l'application souveraine ne peut pas exécuter les ordres de ses utilisateurs pendant l'intervalle alloué (malgré un consensus valide), ce qui nuit à l'expérience utilisateur et au bien-être global.

Il existe cependant des solutions potentielles à la question de la composabilité, dont plusieurs sont explorées par diverses équipes. Il s’agit notamment de concepts tels que les préconfirmations d’inclusion, les séquenceurs partagés spécifiques à l’application et les engagements des générateurs, chacun offrant des compromis entre le degré de composabilité et la surcharge de confiance.

Pré-confirmations d'inclusion

Pour expliquer les préconfirmations d'inclusion, il est important de comprendre d'abord comment fonctionnent les préconfirmations basées. Les préconfirmations basées exploitent la sécurité cryptéconomique en veillant à ce que les proposants aient mis en place des garanties pour garantir l'inclusion d'un ensemble spécifique de transactions avant une fente dans l'époque actuelle. Cette garantie est limitée par la taille de la caution déposée par les proposants participants.

Les préconfirmations d'inclusion sont une forme spécialisée de préconfirmations basées, où l'inclusion de la transaction est indépendante de l'état du contrat. Les transactions demandant des préconfirmations d'inclusion doivent être indépendantes de l'état et non controversées, ce qui signifie que leur exécution n'est pas affectée par leur position dans le bloc. En utilisant les préconfirmations d'inclusion, les proposants peuvent s'engager à inclure une transaction non-ASS uniquement si le bundle ASS est inclus dans le même bloc. Cette approche permet une composition cryptéconomiquement appliquée entre les transactions non controversées et les bundles ASS.

Illustration de l'inclusion de la préconférence avec ASS

Cependant, compte tenu de la composition limitée fournie par cette solution, la complexité et la surcharge de confiance ajoutées peuvent l'emporter sur ses avantages pour certaines applications souveraines. Par conséquent, il est important d'explorer des approches alternatives qui pourraient offrir un équilibre plus efficace entre simplicité et fonctionnalité.

Séquenceurs d'application spécifiques partagés et engagements des constructeurs

Au lieu de s’appuyer sur les engagements des proposants, les applications souveraines peuvent utiliser des séquenceurs spécifiques à l’application pour gérer l’ordre des transactions entre plusieurs applications. Par exemple, un séquenceur gérant des transactions pour plusieurs applications souveraines peut faciliter la composabilité atomique entre elles, à condition de suivre les règles de séquençage de chacune. Cette approche de séquenceur partagé spécifique à l’application permet une composabilité et une coordination transparentes entre les applications souveraines.

Cependant, pour les applications non souveraines, une solution différente est nécessaire. Les engagements d'inclusion de transaction des constructeurs de blocs qui participent à la séquence des applications souveraines peuvent créer une composabilité atomique entre les applications non souveraines et souveraines. Le constructeur garantit l'ordre des transactions spécifiées pour les deux types d'applications. Un tel engagement du constructeur peut combler le fossé de composabilité pour ASS.

Illustration de l'engagement du constructeur pour la composition atomique entre les dApps souverains et non souverains (à droite) et du séquenceur spécifique à l'application partagée pour la composition atomique entre les applications souveraines (à gauche)

Bien que des questions subsistent quant à la dynamique économique des engagements des constructeurs, à la faisabilité de la préconfirmation de l’inclusion et aux effets potentiels de second ordre, nous sommes convaincus que les défis de composabilité de l’ASS seront résolus au fil du temps. Des équipes comme Astria et Primev sont activement à la recherche et à l’élaboration de cadres améliorés pour le séquençage partagé et les engagements des constructeurs. Au fur et à mesure de ces avancées, la composabilité ne sera plus un problème pour les applications souveraines.

ASS contre les L2s spécifiques à l'application et les L1s

Actuellement, les dApps doivent construire des chaînes spécifiques à l'application s'ils veulent prendre le contrôle de la séquence de leurs transactions. Des concepts comme Protocol Owned Builder (PoB)permet aux Cosmos L1s d'avoir des règles de séquençage plus expressives qui aident à capturer et redistribuer le MEV à leur application. De même, un séquenceur L2 avec VSR peut également effectuer de telles opérations. Alors que les deux solutions permettent un séquençage plus expressif et la capture du MEV par ses applications, l'ASS est unique en raison des caractéristiques suivantes.

1. Aucune surcharge de confiance liée à l'exécution des transactions - ASS n'exécute ni ne règle la transaction séquentielle. Seul le séquençage est délégué. L'hypothèse de confiance de base s'étend à l'environnement d'exécution natif, tel qu'Ethereum ou d'autres L2.
2. Accès à la liquidité et au flux d’ordres – Les utilisateurs n’ont pas besoin de passer. Les dApps peuvent directement tirer parti du flux et de la liquidité de la chaîne.
3. Les actifs restent dans l’environnement d’exécution natif et ne peuvent pas être gelés : contrairement aux L2, la plupart des ASS n’obligent pas les utilisateurs à verrouiller leurs fonds dans des contrats de transition. Ce choix de conception offre une meilleure sécurité : en cas de défaillance d’un séquenceur spécifique à l’application, les dommages potentiels sont limités puisque le séquenceur ne peut contrôler les transactions que dans les limites fixées par le contrat intelligent. Bien que certaines solutions L2 mettent en œuvre des dispositifs de sécurité, tels que des trappes d’évacuation et des inclusion forcéeces mesures sont souvent difficiles à utiliser en pratique. Les utilisateurs pourraient avoir besoin d'attendre plusieurs jours avant de pouvoir activer une trappe de secours après avoir perdu la connexion aux mises à jour L2. De même, l'inclusion forcée via L1 implique généralement au moins une journéeretard. Peut-être plus important encore, ces mesures de sécurité nécessitent généralement une expertise technique que la plupart des utilisateurs n'ont pas, ce qui les rend impraticables pour la personne moyenne.
4. Hypothèse de vivacité Strong-ASS – La vivacité du L2 dépend des nœuds d’exécution, qui sont généralement le séquenceur de cumul, à moins qu’il ne soit séquencé sur la base. La vivacité de la L1 dépend de l’honnête majorité des nœuds qui réexécutent les fonctions de transition d’état correspondantes. La vivacité d’une application souveraine dépend principalement de l’environnement d’exécution sous-jacent, et les contrats intelligents peuvent spécifier des parties qui doivent s’appuyer sur des séquenceurs spécifiques à l’application.

Table comparant les applications souveraines, L2, L2 basé et L1

Conclusion

ASS donne aux applications une pleine souveraineté sur le séquençage des transactions, leur permettant de définir des règles personnalisées sans la complexité de la gestion de l'exécution. Cette souveraineté permet aux applications de contrôler leur exécution pour optimiser les résultats pour leurs utilisateurs. Par exemple, sur Angstrom, les LP et les échangeurs sont traités comme des participants de première classe, leur gain économique étant directement amélioré par des règles de séquençage personnalisées.

De plus, ASS peut tirer parti d'une gamme d'outils cryptographiques et cryptographiques pour garantir l'optimalité des récompenses des utilisateurs et mettre en œuvre des mécanismes de résistance à la censure robustes. Les solutions cryptographiques, telles que le jalonnement et la réduction, peuvent inciter à un comportement honnête parmi les séquenceurs, tandis que les méthodes cryptographiques telles que TEE et MPC améliorent la confidentialité et la sécurité. Avec ces outils, le potentiel de conception de ASS est immense, permettant la création d'applications souveraines plus sécurisées, efficaces et centrées sur les utilisateurs.

Malgré les opportunités qu'ASS offre, des défis tels que le manque de composabilité native existent toujours. Cependant, des solutions telles que la préconfirmation de l'inclusion, ASS partagé et l'engagement des constructeurs présentent des moyens prometteurs de surmonter ces obstacles. Bien que certaines questions subsistent, nous nous engageons à affiner ces approches pour offrir une expérience ASS plus fluide et plus composable.

Nous sommes là pour rendre DeFi plus durable, un ASS à la fois.

Avis de non-responsabilité :

1. Cet article est repris de [.sœur]. Tous les droits d'auteur appartiennent à l'auteur original [Yuki Yuminaga]. Si vous avez des objections à cette reproduction, veuillez contacter le Porte Apprendrel'é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 interdite.