Auteurs : Quintus Kilbourn, Georgios Konstantopoulos, Paradigm ; Traduction : Golden Finance 0xxz
Introduction
Les discussions autour des "intentions" et de leurs applications sont récemment devenues un sujet brûlant dans la communauté Ethereum.
Là où les transactions se réfèrent spécifiquement à "comment" une action doit être effectuée, les intentions se réfèrent à "quel" devrait être le résultat attendu de cette action. Si une transaction dit "faites A d'abord, puis B, payez C en totalité pour obtenir X", les intentions disent "je veux X, et je suis prêt à payer jusqu'à C".
Ce paradigme déclaratif débloque une expérience utilisateur passionnante et des améliorations d'efficacité. Grâce aux intentions, les utilisateurs peuvent simplement exprimer un résultat souhaité tout en externalisant la tâche optimale d'atteindre ce résultat à un tiers expérimenté. Le concept d'intentions contraste avec le paradigme actuel des transactions impératives, où chaque paramètre est explicitement spécifié par l'utilisateur.
Bien que ces promesses d'améliorations fournissent des étapes indispensables pour l'écosystème, la conception basée sur l'intention d'Ethereum pourrait également avoir des implications importantes pour l'infrastructure hors chaîne. En particulier, il existe des liens importants avec les activités liées aux MEV et le contrôle du marché. Cet article vise à fournir une brève définition des intentions et de leurs avantages, une exploration des risques liés à leur mise en œuvre et une discussion sur les atténuations potentielles.
Que sont les intentions ?
La manière standard actuelle pour les utilisateurs d'interagir avec Ethereum est de créer et de signer une transaction, un message dans un format spécifique qui fournit toutes les informations nécessaires à la machine virtuelle Ethereum (EVM) pour effectuer des transitions d'état. Cependant, la création de transactions peut être une affaire compliquée. La création d'une transaction nécessite de raisonner sur des détails tels qu'un vaste réseau de contrats intelligents et une gestion nonce, tout en détenant des actifs spécifiques pour payer les frais de gaz. Cette complexité se traduit par une expérience utilisateur sous-optimale et une perte d'efficacité, car les utilisateurs sont obligés de prendre des décisions sans un accès adéquat aux informations ou des politiques d'application complexes.
Les intentions sont conçues pour alléger ces charges pour l'utilisateur. De manière informelle, les intentions signent un ensemble de contraintes déclaratives qui permettent aux utilisateurs d'externaliser la création de transactions à des tiers sans renoncer au contrôle total des parties à la transaction.
Dans les processus standard basés sur les transactions, les signatures de transaction permettent aux vérificateurs de suivre exactement un chemin de calcul pour un état particulier, et les conseils incitent les vérificateurs à le faire. Les intentions, en revanche, ne spécifient pas explicitement le chemin de calcul qui doit être emprunté, mais autorisent tout chemin de calcul qui satisfait à certaines contraintes. En signant et en partageant des intentions (intents), les utilisateurs accordent effectivement aux destinataires l'autorisation de choisir les chemins de calcul en leur nom (voir le schéma ci-dessous). Cette distinction permet une définition un peu plus stricte des intentions en tant que messages signés qui permettent un ensemble de transitions d'état à partir d'un état de départ donné, un cas particulier étant les transactions qui permettent des transitions uniques. Cela dit, nous continuerons de distinguer les "intentions" des transactions.
*Figure 1 : Lors de la soumission d'une transaction, l'utilisateur spécifie le chemin de calcul exact. Lors de la soumission d'intentions, l'utilisateur spécifie un objectif et certaines contraintes, et le processus de mise en correspondance détermine le chemin de calcul à suivre. *
Il est important de noter que de nombreuses intentions (intentions) peuvent être incluses dans une seule transaction, ce qui permet de faire correspondre les intentions (intentions) qui se chevauchent, d'augmenter l'efficacité énergétique et économique, par exemple dans le carnet de commandes tenu par le constructeur, deux commandes peuvent être mutuellement échangées avant d'entrer dans le compensation du marché. D'autres applications incluent les intentions inter-domaines (intentions) - signer un message au lieu de plusieurs transactions sur différents domaines - en utilisant différents schémas de résistance à la relecture (résistance à la relecture) et des paiements de gaz d'utilisateur plus flexibles, comme permettre aux 3 premières parties de sponsoriser du gaz ou de payer dans différents jetons.
passé et futur des intentions
Des intentions ont été créées pour externaliser la complexité de l'interaction avec la blockchain, tout en permettant aux utilisateurs de conserver la garde de leurs actifs et de leurs identités cryptographiques.
Vous remarquerez peut-être que bon nombre de ces idées correspondent à des systèmes qui fonctionnent depuis de nombreuses années :
Ordre à cours limité : Peut retirer 100X de mon compte si je reçois au moins 200Y.
Enchères de style CowSwap : comme ci-dessus, mais s'appuie sur un tiers ou un mécanisme pour faire correspondre de nombreuses commandes afin de maximiser la qualité d'exécution.
** Parrainage d'essence : ** Payez l'essence en USDC au lieu d'ETH. Les intentions (intentions) ne peuvent être réalisées qu'en faisant correspondre les intentions, et les frais sont payés en ETH.
* Délégation : autorisez uniquement l'interaction avec certains comptes de certaines manières pré-autorisées. Les intentions ne peuvent être implémentées que si la transaction résultante respecte la liste de contrôle d'accès spécifiée dans l'intention.
** Transaction par lots : ** Autorise le traitement par lots des intentions pour améliorer l'efficacité du gaz.
** Agrégateurs : ** Fonctionnent uniquement avec le "meilleur" prix/rendement. Cette intention peut être atteinte en prouvant que l'agrégation de plusieurs sites est effectuée et que le meilleur chemin est emprunté.
À l'avenir, dans le contexte des MEV inter-chaînes (tels que SUAVE), des abstractions de compte de type ERC4337 et même des commandes de port maritime, les intentions des gens sont revigorées ! Alors que l'ERC4337 progresse à toute vitesse, d'autres nouvelles applications telles que les intentions inter-domaines nécessitent encore des recherches supplémentaires.
Fondamentalement, dans toutes les applications basées sur l'intention, anciennes et nouvelles, il doit y avoir au moins une autre partie qui comprend l'intention, est motivée pour exécuter l'intention et est capable de le faire en temps opportun. Des questions sur qui sont ces parties, comment elles fonctionnent et quelles sont leurs motivations doivent être posées pour déterminer l'efficacité, les hypothèses de confiance et les implications plus larges des systèmes axés sur l'intention.
L'intermédiaire et son mempool
Le canal le plus évident pour les intentions d'entrer entre les mains d'intermédiaires est le mempool Ethereum. Malheureusement, la conception actuelle ne prend pas en charge la propagation des intentions. Les inquiétudes concernant les attaques DoS peuvent signifier que la prise en charge universelle d'intentions entièrement génériques dans le mempool Ethereum est impossible, même à long terme. Comme nous le verrons ci-dessous, la nature ouverte et sans autorisation des mempools Ethereum crée des obstacles supplémentaires à l'adoption des intentions.
En l'absence d'un mempool Ethereum, les concepteurs de systèmes d'intentions sont désormais confrontés à des problèmes de conception. Une décision de haut niveau est de savoir s'il faut propager les intentions à l'ensemble d'autorisations ou les fournir sans autorisation afin que l'une ou l'autre des parties puisse exécuter les intentions.
Figure 2 : Les intentions circulent des utilisateurs vers des pools d'intentions autorisées/non autorisées et publiques/privées (intentions), converties en transactions par des intermédiaires, et enfin entrent dans le pool de mémoire publique ou vont directement à la chaîne via des enchères de type MEVBoost
** Mempool sans autorisation **
Une conception que l'on pourrait rechercher est une API décentralisée qui permet aux intentions d'être propagées à travers les nœuds du système, offrant un accès sans autorisation aux acteurs. Cela a déjà été fait. Par exemple, limiter les commandes de potins entre les relais de protocole 0x et les mettre en chaîne lorsqu'ils correspondent. Cette idée est également explorée dans le cadre d'un mempool ERC4337 partagé pour lutter contre les risques de centralisation et de censure. Cependant, la conception d'un tel « pool d'intentions » sans autorisation est confrontée à des défis importants :
** Anti-DoS : ** Il peut être nécessaire de limiter la fonctionnalité des intents (intent) pour éviter les attaques.
Propagation des incitations : Pour de nombreuses applications, l'exécution d'intents est une activité rentable. Par conséquent, les nœuds exploitant un pool d'intentions sont incités à ne pas se propager, afin de réduire les conflits lors de l'exécution des intentions.
**MEV : ** les intentions reposent sur le bon comportement des acteurs hors chaîne pour améliorer la qualité d'exécution, et l'utilisation d'un pool d'intentions public et sans autorisation peut rencontrer des difficultés. Si une mauvaise exécution est rentable, un pool d'intentions non autorisées est susceptible de conduire à ce résultat. Cela revient à être pris dans le mempool Ethereum aujourd'hui et devrait être un problème courant pour les intentions liées à DeFi. Un chemin possible vers l'avant pourrait être des pools d'intentions sans autorisation mais chiffrés.
** "pool de mémoire" autorisé **
Les API centralisées de confiance sont plus résistantes au DoS et n'ont pas besoin de propager les intentions. Des modèles crédibles fournissent également une base pour les problèmes de MEV. Tant que l'hypothèse de confiance tient, la qualité de l'exécution doit être garantie. Un intermédiaire de confiance peut également avoir une réputation qui lui est associée, ce qui incite à assurer une bonne exécution. Pour cette raison, les pools d'intentions autorisés sont attrayants pour les développeurs d'applications basées sur l'intention à court terme. Cependant, comme nous le savons tous, l'hypothèse de confiance forte est imparfaite et quelque peu antithétique à une grande partie de l'éthique de la blockchain. Ces questions seront traitées ci-dessous.
solution mixte
Certaines solutions sont des mélanges de ce qui précède. Par exemple, il peut y avoir une autorisation de propagation, mais pas d'autorisation d'exécution (en supposant que l'hypothèse de confiance soit vérifiée), et vice versa. Un exemple courant de solution hybride est une enchère de flux d'ordres.
L'idée de haut niveau derrière ces conceptions est qu'un utilisateur qui a besoin d'une contrepartie peut avoir besoin de faire la distinction entre les meilleures et les pires contreparties (par exemple, l'autre partie qui accepte une transaction à un prix favorable). Le processus de conception comprend généralement une partie de confiance qui reçoit l'intention de l'utilisateur (ou les transactions) et facilite l'enchère en son nom. La participation aux enchères est (parfois) non autorisée.
Ces types de conceptions ont leurs propres inconvénients et sont susceptibles de souffrir de nombreuses préoccupations concernant les pools d'intention autorisés, mais il existe des distinctions importantes qui deviendront apparentes plus tard.
Conclusion : les applications basées sur les intentions impliquent non seulement de nouveaux formats de message pour interagir avec les contrats intelligents, mais également des mécanismes alternatifs de propagation de type mempool et de découverte de contreparties. Concevoir un mécanisme de découverte et d'appariement d'intentions qui soit à la fois compatible avec les incitations et décentralisé n'est pas trivial.
Où puis-je me tromper ?
Bien que les intentions soient un nouveau paradigme de transaction passionnant, leur adoption généralisée pourrait signifier que la tendance plus large de l'activité des utilisateurs à se déplacer vers des mempools alternatifs s'accélère. S'il n'est pas géré correctement, ce changement pourrait conduire à la centralisation et à l'enracinement d'intermédiaires à la recherche de rentes.
Flux de commandes
La migration depuis le mempool public pourrait conduire à la centralisation de la production de blocs Ethereum si les intentions s'exécutent avec autorisation, mais que l'ensemble d'autorisations n'est pas choisi avec soin. *
La grande majorité de la production de blocs sur Ethereum se produit actuellement via MEV-Boost, une implémentation hors protocole de la séparation proposant-constructeur (PBS), et la feuille de route actuelle ne donne aucune indication que cette interface sera bientôt modifiée. PBS s'appuie sur l'existence d'un marché concurrentiel pour les constructeurs de blocs pour diriger le MEV vers l'ensemble de validateurs. Un problème majeur dans PBS est la capacité des constructeurs de blocs à obtenir un accès exclusif aux matières premières nécessaires pour produire des blocs de valeur - transactions et intentions, également appelées « flux de commandes ». Dans le jargon PBS, l'accès autorisé aux intentions sera appelé "Exclusive Order Flow" (EOF). Comme indiqué dans cet article, EOF entre de mauvaises mains menace la structure du marché sur laquelle s'appuie PBS, car l'exclusivité dans le flux d'ordres signifie un fossé contre les forces concurrentielles.
Les constructeurs de blocs (ou entités collaboratrices) qui contrôlent la majorité du flux de commandes d'Ethereum pourront produire la majorité des blocs du réseau principal, ouvrant ainsi un vecteur de censure. Étant donné que le réseau repose sur la concurrence entre les constructeurs pour transmettre de la valeur aux validateurs (ou être détruit à l'avenir), la domination d'un seul constructeur constituera un transfert de valeur d'Ethereum vers les constructeurs. La recherche de rente et la censure sont sans aucun doute des menaces importantes pour le protocole.
confiance
Comme de nombreuses solutions nécessitent la confiance dans les intermédiaires, le développement de nouvelles architectures basées sur les intentions est entravé par des barrières à l'entrée élevées, ce qui signifie des taux d'innovation et de concurrence plus faibles pour assurer la qualité de l'exécution. *
Dans le pire des cas, les utilisateurs peuvent se retrouver dans une position où une seule partie exécute les intentions, comme le monopole de construction de blocs dans la section précédente. Dans un tel monde, les monopoles de la construction de blocs seraient en mesure d'extraire des rentes, et toute nouvelle proposition sur la façon de gérer les intentions serait rejetée si elle n'était pas adoptée par les constructeurs. Les utilisateurs individuels perdent leur pouvoir de négociation face à un monopole, un effet qui est exacerbé lorsque les utilisateurs utilisent des intentions pour fournir des degrés de liberté supplémentaires aux intermédiaires.
Malheureusement, la stagnation du marché due à l'infrastructure centralisée n'inclut pas les préoccupations concernant un marché pour les constructeurs. Même pour les entreprises de construction autres que les blocs, les barrières élevées à l'entrée placent les intermédiaires en position de force, car ils font face à peu de concurrence. Par exemple, considérons l'état actuel du marché des enchères de flux d'ordres. Quelques entités telles que Flashbots et CoWswap reçoivent la majeure partie du flux de commandes vers OFA. Le flux de commandes est distribué en grande partie parce que ces entités existent depuis des années ou sont associées à des entités réputées, ce qui signifie qu'elles ont réussi à gagner un certain niveau de confiance du public. Si une nouvelle conception OFA tente d'entrer sur le marché, celui qui gère le nouvel OFA devra passer beaucoup de temps à convaincre les utilisateurs et les portefeuilles qu'ils sont dignes de confiance et qu'ils n'abuseront pas de leur pouvoir. La nécessité d'une telle campagne crédible constitue certainement une barrière substantielle à l'entrée.
Le marché des enchères par flux d'ordres n'a commencé que récemment à gagner du terrain, et il reste à voir comment la concurrence se développera, mais le marché fournit un exemple illustratif où des mempools autorisés et de confiance peuvent enchâsser un petit nombre de participants puissants, nuisant ainsi à la meilleurs intérêts des utilisateurs.
Le format d'intention EIP4337 fournit un autre exemple de mécanisme qui nous est possible. Imaginez un monde où une architecture de confiance est déjà en place pour prendre en charge 4337 intentions. Si un autre format d'intentions est proposé - peut-être servant des cas d'utilisation supplémentaires comme la fonctionnalité d'origine croisée - mais que les intermédiaires de confiance établis n'adoptent pas ce nouveau format (après tout, il n'a pas beaucoup d'adoption et n'est pas pertinent pour la concurrence de leur modèle commercial ), la mise en place de nouveaux formats nécessite d'instaurer la confiance dans de nouvelles entités. De même, nous nous trouvons en position d'innover et de remettre en question le statu quo, mais rencontrons des barrières à l'entrée basées sur la confiance.
Opacité
Étant donné que de nombreuses architectures d'intentions exigent que les utilisateurs renoncent à un certain contrôle sur leurs actifs en chaîne et que les mempools autorisés impliquent un degré d'impénétrabilité externe, nous courons le risque de construire un système opaque où, il n'est pas clair comment ou si les attentes des utilisateurs seront atteint, et la menace pour l'écosystème reste non découverte. *
Les sections ci-dessus traitent des risques pour les utilisateurs et les protocoles que posent les déséquilibres de pouvoir sur le marché des flux d'ordres. Un problème connexe est que l'écosystème de middleware et de mempools qui se développe entre les utilisateurs et la blockchain devient opaque, même pour les observateurs avisés. Cette préoccupation est particulièrement pertinente pour les applications basées sur les intentions qui cherchent à permettre aux utilisateurs d'externaliser des décisions importantes telles que l'acheminement des commandes.
Les situations où le MEV a un impact négatif sur l'exécution des utilisateurs sont souvent dues au fait que les responsables de l'application renoncent à un degré élevé de liberté dans le commerce (par exemple, les limites de glissement). Ce n'est donc pas un énorme saut de logique d'affirmer que les applications basées sur les intentions qui renoncent à de plus grands degrés de liberté devraient concevoir leurs systèmes d'exécution avec plus de soin. Le pire résultat à cet égard est un monde où l'utilisation d'une application basée sur l'intention nécessite de signer une intention de disparition (dans une forêt sombre, si vous voulez) puis d'une manière ou d'une autre implémentée en tant que transactions, mais on ne sait pas comment ni par qui les transactions sont créées. Bien sûr, la capacité de surveiller ces écosystèmes est également liée aux préoccupations concernant l'EOF et les défenses basées sur la confiance.
Atténuer le risque
Le mempool Ethereum est limité. Pour certaines applications, cela est dû à son manque de confidentialité (clips sandwich), pour d'autres, à son incapacité à prendre en charge une plus large gamme de formats de messages. Cela met les développeurs de portefeuilles et d'applications dans une impasse, car ils doivent trouver un moyen de connecter les utilisateurs à la blockchain tout en évitant les dangers susmentionnés.
En examinant les questions ci-dessus, nous pouvons déduire certaines propriétés des systèmes idéaux. Un tel système doit être sans autorisation, afin que n'importe qui puisse faire correspondre et exécuter des intentions sans sacrifier trop de qualité d'exécution ; générique, afin que le déploiement de nouvelles applications ne nécessite pas la création de nouveaux pools de mémoire ; transparent, afin qu'il soit public Rapport sur le processus d'exécution intentions et, lorsque les garanties de confidentialité le permettent, fournir des données pour effectuer des audits de qualité.
Alors que des équipes comme Flashbots et Anoma travaillent sur des solutions générales qui répondent aux exigences ci-dessus en combinant confidentialité et absence de permission, le système idéal pourrait ne pas être prêt de sitôt. Ainsi, différentes solutions faisant leurs propres compromis peuvent mieux servir différentes applications. Alors que des mécanismes comme les crlists sont apparus en réponse à bon nombre des mêmes problèmes entourant les applications basées sur les transactions, peut-être pas pour des intentions, des gadgets qui permettent aux utilisateurs de revenir aux transactions chaque fois que possible seraient bien Améliorer les pires scénarios Encore une fois, les applications qui cherchent à démarrer des pools des intentions font mieux de rechercher la généralité lorsqu'elles ne sont pas autorisées et de choisir un intermédiaire avec soin lorsqu'elles sont autorisées.
D'une manière générale, nous demandons aux concepteurs d'applications basées sur les intentions d'examiner attentivement l'impact hors chaîne de leurs applications, car celles-ci peuvent toucher des communautés plus larges que leur simple base d'utilisateurs, nous demandons que la communauté accorde une attention particulière à l'écosystème hors chaîne qui entoure Ethereum.
en conclusion
L'adoption des intentions représente un passage des paradigmes impératifs aux paradigmes déclaratifs, ce qui promet d'améliorer considérablement l'expérience utilisateur et les pertes d'efficacité dues au MEV. Le besoin de ces applications est clair et de nombreuses applications basées sur l'intention sont largement utilisées depuis de nombreuses années.
L'adoption accrue des intentions, entraînée par ERC4337, peut accélérer le passage des mempools Ethereum à de nouveaux sites. Bien que cette décision soit raisonnable et inévitable, les concepteurs d'applications basées sur les intentions ont de bonnes raisons d'être prudents lors de la conception des composants hors chaîne de leurs systèmes lors du développement d'une infrastructure robuste.
Il y a encore beaucoup de recherche et d'ingénierie à faire dans ce paradigme de transaction naissant et dans des domaines que nous n'avons pas couverts dans cet article, comme la conception d'un langage d'expression pour les intentions qui permet la confidentialité.
Un grand merci à DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun et ElijahFox pour leurs commentaires sur cet article, et AchalSrinivasan pour l'article.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Paradigme : Le paradigme des intentions des transactions Ethereum - architecture et risques
Auteurs : Quintus Kilbourn, Georgios Konstantopoulos, Paradigm ; Traduction : Golden Finance 0xxz
Introduction
Les discussions autour des "intentions" et de leurs applications sont récemment devenues un sujet brûlant dans la communauté Ethereum.
Là où les transactions se réfèrent spécifiquement à "comment" une action doit être effectuée, les intentions se réfèrent à "quel" devrait être le résultat attendu de cette action. Si une transaction dit "faites A d'abord, puis B, payez C en totalité pour obtenir X", les intentions disent "je veux X, et je suis prêt à payer jusqu'à C".
Ce paradigme déclaratif débloque une expérience utilisateur passionnante et des améliorations d'efficacité. Grâce aux intentions, les utilisateurs peuvent simplement exprimer un résultat souhaité tout en externalisant la tâche optimale d'atteindre ce résultat à un tiers expérimenté. Le concept d'intentions contraste avec le paradigme actuel des transactions impératives, où chaque paramètre est explicitement spécifié par l'utilisateur.
Bien que ces promesses d'améliorations fournissent des étapes indispensables pour l'écosystème, la conception basée sur l'intention d'Ethereum pourrait également avoir des implications importantes pour l'infrastructure hors chaîne. En particulier, il existe des liens importants avec les activités liées aux MEV et le contrôle du marché. Cet article vise à fournir une brève définition des intentions et de leurs avantages, une exploration des risques liés à leur mise en œuvre et une discussion sur les atténuations potentielles.
Que sont les intentions ?
La manière standard actuelle pour les utilisateurs d'interagir avec Ethereum est de créer et de signer une transaction, un message dans un format spécifique qui fournit toutes les informations nécessaires à la machine virtuelle Ethereum (EVM) pour effectuer des transitions d'état. Cependant, la création de transactions peut être une affaire compliquée. La création d'une transaction nécessite de raisonner sur des détails tels qu'un vaste réseau de contrats intelligents et une gestion nonce, tout en détenant des actifs spécifiques pour payer les frais de gaz. Cette complexité se traduit par une expérience utilisateur sous-optimale et une perte d'efficacité, car les utilisateurs sont obligés de prendre des décisions sans un accès adéquat aux informations ou des politiques d'application complexes.
Les intentions sont conçues pour alléger ces charges pour l'utilisateur. De manière informelle, les intentions signent un ensemble de contraintes déclaratives qui permettent aux utilisateurs d'externaliser la création de transactions à des tiers sans renoncer au contrôle total des parties à la transaction.
Dans les processus standard basés sur les transactions, les signatures de transaction permettent aux vérificateurs de suivre exactement un chemin de calcul pour un état particulier, et les conseils incitent les vérificateurs à le faire. Les intentions, en revanche, ne spécifient pas explicitement le chemin de calcul qui doit être emprunté, mais autorisent tout chemin de calcul qui satisfait à certaines contraintes. En signant et en partageant des intentions (intents), les utilisateurs accordent effectivement aux destinataires l'autorisation de choisir les chemins de calcul en leur nom (voir le schéma ci-dessous). Cette distinction permet une définition un peu plus stricte des intentions en tant que messages signés qui permettent un ensemble de transitions d'état à partir d'un état de départ donné, un cas particulier étant les transactions qui permettent des transitions uniques. Cela dit, nous continuerons de distinguer les "intentions" des transactions.
Il est important de noter que de nombreuses intentions (intentions) peuvent être incluses dans une seule transaction, ce qui permet de faire correspondre les intentions (intentions) qui se chevauchent, d'augmenter l'efficacité énergétique et économique, par exemple dans le carnet de commandes tenu par le constructeur, deux commandes peuvent être mutuellement échangées avant d'entrer dans le compensation du marché. D'autres applications incluent les intentions inter-domaines (intentions) - signer un message au lieu de plusieurs transactions sur différents domaines - en utilisant différents schémas de résistance à la relecture (résistance à la relecture) et des paiements de gaz d'utilisateur plus flexibles, comme permettre aux 3 premières parties de sponsoriser du gaz ou de payer dans différents jetons.
passé et futur des intentions
Des intentions ont été créées pour externaliser la complexité de l'interaction avec la blockchain, tout en permettant aux utilisateurs de conserver la garde de leurs actifs et de leurs identités cryptographiques.
Vous remarquerez peut-être que bon nombre de ces idées correspondent à des systèmes qui fonctionnent depuis de nombreuses années :
À l'avenir, dans le contexte des MEV inter-chaînes (tels que SUAVE), des abstractions de compte de type ERC4337 et même des commandes de port maritime, les intentions des gens sont revigorées ! Alors que l'ERC4337 progresse à toute vitesse, d'autres nouvelles applications telles que les intentions inter-domaines nécessitent encore des recherches supplémentaires.
Fondamentalement, dans toutes les applications basées sur l'intention, anciennes et nouvelles, il doit y avoir au moins une autre partie qui comprend l'intention, est motivée pour exécuter l'intention et est capable de le faire en temps opportun. Des questions sur qui sont ces parties, comment elles fonctionnent et quelles sont leurs motivations doivent être posées pour déterminer l'efficacité, les hypothèses de confiance et les implications plus larges des systèmes axés sur l'intention.
L'intermédiaire et son mempool
Le canal le plus évident pour les intentions d'entrer entre les mains d'intermédiaires est le mempool Ethereum. Malheureusement, la conception actuelle ne prend pas en charge la propagation des intentions. Les inquiétudes concernant les attaques DoS peuvent signifier que la prise en charge universelle d'intentions entièrement génériques dans le mempool Ethereum est impossible, même à long terme. Comme nous le verrons ci-dessous, la nature ouverte et sans autorisation des mempools Ethereum crée des obstacles supplémentaires à l'adoption des intentions.
En l'absence d'un mempool Ethereum, les concepteurs de systèmes d'intentions sont désormais confrontés à des problèmes de conception. Une décision de haut niveau est de savoir s'il faut propager les intentions à l'ensemble d'autorisations ou les fournir sans autorisation afin que l'une ou l'autre des parties puisse exécuter les intentions.
Figure 2 : Les intentions circulent des utilisateurs vers des pools d'intentions autorisées/non autorisées et publiques/privées (intentions), converties en transactions par des intermédiaires, et enfin entrent dans le pool de mémoire publique ou vont directement à la chaîne via des enchères de type MEVBoost
** Mempool sans autorisation **
Une conception que l'on pourrait rechercher est une API décentralisée qui permet aux intentions d'être propagées à travers les nœuds du système, offrant un accès sans autorisation aux acteurs. Cela a déjà été fait. Par exemple, limiter les commandes de potins entre les relais de protocole 0x et les mettre en chaîne lorsqu'ils correspondent. Cette idée est également explorée dans le cadre d'un mempool ERC4337 partagé pour lutter contre les risques de centralisation et de censure. Cependant, la conception d'un tel « pool d'intentions » sans autorisation est confrontée à des défis importants :
** "pool de mémoire" autorisé **
Les API centralisées de confiance sont plus résistantes au DoS et n'ont pas besoin de propager les intentions. Des modèles crédibles fournissent également une base pour les problèmes de MEV. Tant que l'hypothèse de confiance tient, la qualité de l'exécution doit être garantie. Un intermédiaire de confiance peut également avoir une réputation qui lui est associée, ce qui incite à assurer une bonne exécution. Pour cette raison, les pools d'intentions autorisés sont attrayants pour les développeurs d'applications basées sur l'intention à court terme. Cependant, comme nous le savons tous, l'hypothèse de confiance forte est imparfaite et quelque peu antithétique à une grande partie de l'éthique de la blockchain. Ces questions seront traitées ci-dessous.
solution mixte
Certaines solutions sont des mélanges de ce qui précède. Par exemple, il peut y avoir une autorisation de propagation, mais pas d'autorisation d'exécution (en supposant que l'hypothèse de confiance soit vérifiée), et vice versa. Un exemple courant de solution hybride est une enchère de flux d'ordres.
L'idée de haut niveau derrière ces conceptions est qu'un utilisateur qui a besoin d'une contrepartie peut avoir besoin de faire la distinction entre les meilleures et les pires contreparties (par exemple, l'autre partie qui accepte une transaction à un prix favorable). Le processus de conception comprend généralement une partie de confiance qui reçoit l'intention de l'utilisateur (ou les transactions) et facilite l'enchère en son nom. La participation aux enchères est (parfois) non autorisée.
Ces types de conceptions ont leurs propres inconvénients et sont susceptibles de souffrir de nombreuses préoccupations concernant les pools d'intention autorisés, mais il existe des distinctions importantes qui deviendront apparentes plus tard.
Conclusion : les applications basées sur les intentions impliquent non seulement de nouveaux formats de message pour interagir avec les contrats intelligents, mais également des mécanismes alternatifs de propagation de type mempool et de découverte de contreparties. Concevoir un mécanisme de découverte et d'appariement d'intentions qui soit à la fois compatible avec les incitations et décentralisé n'est pas trivial.
Où puis-je me tromper ?
Bien que les intentions soient un nouveau paradigme de transaction passionnant, leur adoption généralisée pourrait signifier que la tendance plus large de l'activité des utilisateurs à se déplacer vers des mempools alternatifs s'accélère. S'il n'est pas géré correctement, ce changement pourrait conduire à la centralisation et à l'enracinement d'intermédiaires à la recherche de rentes.
Flux de commandes
La grande majorité de la production de blocs sur Ethereum se produit actuellement via MEV-Boost, une implémentation hors protocole de la séparation proposant-constructeur (PBS), et la feuille de route actuelle ne donne aucune indication que cette interface sera bientôt modifiée. PBS s'appuie sur l'existence d'un marché concurrentiel pour les constructeurs de blocs pour diriger le MEV vers l'ensemble de validateurs. Un problème majeur dans PBS est la capacité des constructeurs de blocs à obtenir un accès exclusif aux matières premières nécessaires pour produire des blocs de valeur - transactions et intentions, également appelées « flux de commandes ». Dans le jargon PBS, l'accès autorisé aux intentions sera appelé "Exclusive Order Flow" (EOF). Comme indiqué dans cet article, EOF entre de mauvaises mains menace la structure du marché sur laquelle s'appuie PBS, car l'exclusivité dans le flux d'ordres signifie un fossé contre les forces concurrentielles.
Les constructeurs de blocs (ou entités collaboratrices) qui contrôlent la majorité du flux de commandes d'Ethereum pourront produire la majorité des blocs du réseau principal, ouvrant ainsi un vecteur de censure. Étant donné que le réseau repose sur la concurrence entre les constructeurs pour transmettre de la valeur aux validateurs (ou être détruit à l'avenir), la domination d'un seul constructeur constituera un transfert de valeur d'Ethereum vers les constructeurs. La recherche de rente et la censure sont sans aucun doute des menaces importantes pour le protocole.
confiance
Dans le pire des cas, les utilisateurs peuvent se retrouver dans une position où une seule partie exécute les intentions, comme le monopole de construction de blocs dans la section précédente. Dans un tel monde, les monopoles de la construction de blocs seraient en mesure d'extraire des rentes, et toute nouvelle proposition sur la façon de gérer les intentions serait rejetée si elle n'était pas adoptée par les constructeurs. Les utilisateurs individuels perdent leur pouvoir de négociation face à un monopole, un effet qui est exacerbé lorsque les utilisateurs utilisent des intentions pour fournir des degrés de liberté supplémentaires aux intermédiaires.
Malheureusement, la stagnation du marché due à l'infrastructure centralisée n'inclut pas les préoccupations concernant un marché pour les constructeurs. Même pour les entreprises de construction autres que les blocs, les barrières élevées à l'entrée placent les intermédiaires en position de force, car ils font face à peu de concurrence. Par exemple, considérons l'état actuel du marché des enchères de flux d'ordres. Quelques entités telles que Flashbots et CoWswap reçoivent la majeure partie du flux de commandes vers OFA. Le flux de commandes est distribué en grande partie parce que ces entités existent depuis des années ou sont associées à des entités réputées, ce qui signifie qu'elles ont réussi à gagner un certain niveau de confiance du public. Si une nouvelle conception OFA tente d'entrer sur le marché, celui qui gère le nouvel OFA devra passer beaucoup de temps à convaincre les utilisateurs et les portefeuilles qu'ils sont dignes de confiance et qu'ils n'abuseront pas de leur pouvoir. La nécessité d'une telle campagne crédible constitue certainement une barrière substantielle à l'entrée.
Le marché des enchères par flux d'ordres n'a commencé que récemment à gagner du terrain, et il reste à voir comment la concurrence se développera, mais le marché fournit un exemple illustratif où des mempools autorisés et de confiance peuvent enchâsser un petit nombre de participants puissants, nuisant ainsi à la meilleurs intérêts des utilisateurs.
Le format d'intention EIP4337 fournit un autre exemple de mécanisme qui nous est possible. Imaginez un monde où une architecture de confiance est déjà en place pour prendre en charge 4337 intentions. Si un autre format d'intentions est proposé - peut-être servant des cas d'utilisation supplémentaires comme la fonctionnalité d'origine croisée - mais que les intermédiaires de confiance établis n'adoptent pas ce nouveau format (après tout, il n'a pas beaucoup d'adoption et n'est pas pertinent pour la concurrence de leur modèle commercial ), la mise en place de nouveaux formats nécessite d'instaurer la confiance dans de nouvelles entités. De même, nous nous trouvons en position d'innover et de remettre en question le statu quo, mais rencontrons des barrières à l'entrée basées sur la confiance.
Opacité
Les sections ci-dessus traitent des risques pour les utilisateurs et les protocoles que posent les déséquilibres de pouvoir sur le marché des flux d'ordres. Un problème connexe est que l'écosystème de middleware et de mempools qui se développe entre les utilisateurs et la blockchain devient opaque, même pour les observateurs avisés. Cette préoccupation est particulièrement pertinente pour les applications basées sur les intentions qui cherchent à permettre aux utilisateurs d'externaliser des décisions importantes telles que l'acheminement des commandes.
Les situations où le MEV a un impact négatif sur l'exécution des utilisateurs sont souvent dues au fait que les responsables de l'application renoncent à un degré élevé de liberté dans le commerce (par exemple, les limites de glissement). Ce n'est donc pas un énorme saut de logique d'affirmer que les applications basées sur les intentions qui renoncent à de plus grands degrés de liberté devraient concevoir leurs systèmes d'exécution avec plus de soin. Le pire résultat à cet égard est un monde où l'utilisation d'une application basée sur l'intention nécessite de signer une intention de disparition (dans une forêt sombre, si vous voulez) puis d'une manière ou d'une autre implémentée en tant que transactions, mais on ne sait pas comment ni par qui les transactions sont créées. Bien sûr, la capacité de surveiller ces écosystèmes est également liée aux préoccupations concernant l'EOF et les défenses basées sur la confiance.
Atténuer le risque
Le mempool Ethereum est limité. Pour certaines applications, cela est dû à son manque de confidentialité (clips sandwich), pour d'autres, à son incapacité à prendre en charge une plus large gamme de formats de messages. Cela met les développeurs de portefeuilles et d'applications dans une impasse, car ils doivent trouver un moyen de connecter les utilisateurs à la blockchain tout en évitant les dangers susmentionnés.
En examinant les questions ci-dessus, nous pouvons déduire certaines propriétés des systèmes idéaux. Un tel système doit être sans autorisation, afin que n'importe qui puisse faire correspondre et exécuter des intentions sans sacrifier trop de qualité d'exécution ; générique, afin que le déploiement de nouvelles applications ne nécessite pas la création de nouveaux pools de mémoire ; transparent, afin qu'il soit public Rapport sur le processus d'exécution intentions et, lorsque les garanties de confidentialité le permettent, fournir des données pour effectuer des audits de qualité.
Alors que des équipes comme Flashbots et Anoma travaillent sur des solutions générales qui répondent aux exigences ci-dessus en combinant confidentialité et absence de permission, le système idéal pourrait ne pas être prêt de sitôt. Ainsi, différentes solutions faisant leurs propres compromis peuvent mieux servir différentes applications. Alors que des mécanismes comme les crlists sont apparus en réponse à bon nombre des mêmes problèmes entourant les applications basées sur les transactions, peut-être pas pour des intentions, des gadgets qui permettent aux utilisateurs de revenir aux transactions chaque fois que possible seraient bien Améliorer les pires scénarios Encore une fois, les applications qui cherchent à démarrer des pools des intentions font mieux de rechercher la généralité lorsqu'elles ne sont pas autorisées et de choisir un intermédiaire avec soin lorsqu'elles sont autorisées.
D'une manière générale, nous demandons aux concepteurs d'applications basées sur les intentions d'examiner attentivement l'impact hors chaîne de leurs applications, car celles-ci peuvent toucher des communautés plus larges que leur simple base d'utilisateurs, nous demandons que la communauté accorde une attention particulière à l'écosystème hors chaîne qui entoure Ethereum.
en conclusion
L'adoption des intentions représente un passage des paradigmes impératifs aux paradigmes déclaratifs, ce qui promet d'améliorer considérablement l'expérience utilisateur et les pertes d'efficacité dues au MEV. Le besoin de ces applications est clair et de nombreuses applications basées sur l'intention sont largement utilisées depuis de nombreuses années.
L'adoption accrue des intentions, entraînée par ERC4337, peut accélérer le passage des mempools Ethereum à de nouveaux sites. Bien que cette décision soit raisonnable et inévitable, les concepteurs d'applications basées sur les intentions ont de bonnes raisons d'être prudents lors de la conception des composants hors chaîne de leurs systèmes lors du développement d'une infrastructure robuste.
Il y a encore beaucoup de recherche et d'ingénierie à faire dans ce paradigme de transaction naissant et dans des domaines que nous n'avons pas couverts dans cet article, comme la conception d'un langage d'expression pour les intentions qui permet la confidentialité.
Un grand merci à DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun et ElijahFox pour leurs commentaires sur cet article, et AchalSrinivasan pour l'article.