Auteur : Quintus Kilbourn, Georgios Konstantopoulos, Paradigm Traduction : Golden Finance 0xxz ;
introduction
Récemment, les discussions autour des « intentions » et de leurs applications sont devenues un sujet brûlant dans la communauté Ethereum.
Si les transactions font explicitement référence à « comment » une action doit être effectuée, les intentions font référence à « quels » devraient être les résultats attendus de l'action. Si une transaction dit "Faites d'abord A, puis faites B, payez entièrement C pour obtenir X", alors les intentions disent "Je veux X, 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 sous-traitant les meilleures tâches pour atteindre ce résultat à un tiers expérimenté. Le concept d'intentions contraste avec le paradigme de transaction impératif actuel, où chaque paramètre est explicitement spécifié par l'utilisateur.
Bien que la promesse de ces améliorations constitue une étape indispensable pour l’écosystème, la conception basée sur l’intention sur Ethereum pourrait également avoir un impact significatif sur l’infrastructure hors chaîne. Il existe en particulier des liens importants avec les activités liées au MEV et aux contrôles du marché. Cet article vise à fournir une brève définition des intentions et de leurs avantages, une exploration des risques impliqués dans leur mise en œuvre et une discussion sur les atténuations potentielles.
Que sont les intentions ?
La méthode standard actuelle permettant aux utilisateurs d'interagir avec Ethereum consiste à effectuer et à signer des transactions, un message spécifiquement formaté qui fournit toutes les informations nécessaires à la machine virtuelle Ethereum (EVM) pour effectuer des transitions d'état. Cependant, créer une transaction peut être une affaire compliquée. La création de transactions nécessite de raisonner sur des détails tels qu'un vaste réseau de contrats intelligents et la gestion de nombres aléatoires, tout en détenant des actifs spécifiques pour payer les frais de gaz. Cette complexité conduit à une expérience utilisateur sous-optimale et à une efficacité réduite, car les utilisateurs sont obligés de prendre des décisions sans accès adéquat aux informations ni stratégies d'exécution complexes.
Les intentions sont conçues pour soulager les utilisateurs de ces fardeaux. De manière informelle, les intentions signent un ensemble de contraintes déclaratives qui permettent aux utilisateurs de sous-traiter la création de transactions à un tiers sans renoncer au contrôle total des parties à la transaction.
Dans un processus standard basé sur les transactions, les signatures de transaction permettent aux validateurs de suivre exactement un chemin de calcul pour un état spécifique, tandis que les indices incitent les validateurs à le faire. Les intentions, en revanche, ne spécifient pas explicitement un chemin de calcul à emprunter, mais autorisent tout chemin de calcul satisfaisant certaines contraintes. En signant et en partageant les intentions, les utilisateurs accordent effectivement aux destinataires la permission de choisir des chemins de calcul en leur nom (voir l'image ci-dessous). Cette distinction permet de définir les intentions de manière légèrement plus stricte en tant que messages signés, autorisant un ensemble de transitions d'état à partir d'un état de départ donné, un cas particulier étant les transactions qui autorisent des transitions uniques. Cela dit, nous continuerons de distinguer les « intentions » des transactions.
Figure 1 : Lors de la soumission d'une transaction, l'utilisateur précise le chemin de calcul exact. Lors de la soumission des intentions, l'utilisateur spécifie l'objectif et certaines contraintes, et le processus de correspondance détermine le chemin de calcul à emprunter.
Il est important de noter que de nombreuses intentions peuvent être incluses dans une seule transaction, ce qui permet de faire correspondre des intentions qui se chevauchent, augmentant ainsi l'efficacité énergétique et économique. Par exemple, dans un carnet de commandes tenu par un constructeur, deux commandes peuvent être comparées avant d'entrer sur le marché. D'autres applications incluent des intentions inter-domaines - signature d'un message au lieu de plusieurs transactions sur différents domaines - utilisant différents schémas de résistance à la relecture et des paiements de gaz utilisateur plus flexibles, comme autoriser un deuxième sponsor de gaz à 3 parties ou payer avec différents jetons.
Le passé et le 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 limité : si je reçois au moins 200 Y, 100 X peuvent être retirés de mon compte.
Enchères de style CowSwap : comme ci-dessus, mais s'appuie sur un tiers ou un mécanisme pour faire correspondre de nombreux ordres afin de maximiser la qualité d'exécution.
Parrainage de gaz : payez le gaz en USDC au lieu d’ETH. Les intentions ne peuvent être réalisées que par des intentions correspondantes, avec des frais payés en ETH.
Délégation : autorisez uniquement l'interaction avec certains comptes de certaines manières préautorisées. Les intentions ne sont remplies que si la transaction finale respecte la liste de contrôle d'accès spécifiée dans l'intention.
Transactions par lots : permet le traitement par lots des intentions pour améliorer l’efficacité du gaz.
Agrégateurs : fonctionnent en utilisant uniquement le "meilleur" rapport prix/rendement. Cet objectif peut être atteint en démontrant que l'agrégation de plusieurs emplacements a été réalisée et que le meilleur chemin a été emprunté.
En regardant vers l’avenir, les intentions des gens sont revitalisées dans le contexte des MEV inter-chaînes (comme SUAVE), des abstractions de comptes de style ERC4337 et même des commandes de ports maritimes ! Alors que l'ERC4337 avance à toute vapeur, d'autres nouvelles applications telles que les intentions inter-domaines nécessitent encore des recherches plus approfondies.
Fondamentalement, dans toutes les applications basées sur les intentions, anciennes et nouvelles, il doit y avoir au moins une autre partie qui comprend les intentions, est motivée pour exécuter les intentions et est capable de les exécuter en temps opportun. Des questions telles que 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 l'impact plus large des systèmes axés sur l'intention.
L'intermédiaire et son pool de mémoire
Le canal le plus évident pour que les intentions tombent entre les mains des intermédiaires est le pool de mémoire 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 universelles dans le pool de mémoire Ethereum est peu probable, même à long terme. Comme nous le verrons ci-dessous, la nature ouverte et sans autorisation du pool de mémoire d’Ethereum crée des obstacles supplémentaires à l’adoption des intentions.
En l’absence d’un pool de mémoire Ethereum, les concepteurs de systèmes d’intention sont désormais confrontés à plusieurs problèmes de conception. Une décision de haut niveau est prise quant à savoir s'il convient de propager les intentions vers un ensemble d'autorisations ou de les fournir sans autorisation afin que n'importe quelle partie puisse exécuter l'intention.
Figure 2 : Les intentions circulent des utilisateurs vers des pools d'intentions autorisés/non autorisés et publics/privés, convertis en transactions par des intermédiaires, et finalement vers des pools de mémoire publics ou directement sur la chaîne via des enchères de type MEV Boost.
Pool de mémoire sans autorisation
Une conception que l’on pourrait rechercher est une API décentralisée qui permet aux intentions de se propager entre différents nœuds du système, offrant ainsi un accès sans autorisation aux acteurs. Cela a déjà été fait. Par exemple, bavarder sur des ordres limités entre des relais de protocole 0x et les placer en chaîne lorsqu'ils correspondent. Cette idée est également explorée dans le cadre d’un pool de mémoire partagée ERC4337 pour lutter contre les risques de centralisation et de censure. Cependant, la conception d’un tel pool d’intentions sans autorisation se heurte à des défis importants :
Anti-DoS : la fonctionnalité des intentions peut devoir être restreinte pour éviter les attaques.
Diffusez des incitations : pour de nombreuses applications, l’exécution d’intentions 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 participants hors chaîne pour améliorer la qualité d'exécution, et des difficultés peuvent être rencontrées lors de l'utilisation d'un pool d'intentions public et sans autorisation. Si une mauvaise exécution est rentable, alors la mise en commun des intentions sans autorisation est susceptible de conduire à ce résultat. Ceci est similaire à ce qui est détecté dans le pool de mémoire Ethereum aujourd'hui et devrait devenir un problème courant pour les intentions liées à DeFi. Une voie possible à suivre pourrait être des pools d’intentions sans autorisation mais cryptés.
"pool de mémoire" autorisé
Les API centralisées de confiance sont plus résistantes au DoS et ne nécessitent pas de propagation d'intentions. Les modèles fiables fournissent également une certaine base pour résoudre le problème MEV. Tant que l’hypothèse de confiance est valable, la qualité de l’exécution doit être garantie. Un intermédiaire digne de confiance peut également avoir une réputation qui lui est associée, ce qui l'incite dans une certaine mesure à assurer une bonne exécution. Pour cette raison, les pools d’intentions autorisés seront attrayants pour les développeurs d’applications basées sur l’intention à court terme. Cependant, comme nous le savons tous, l’hypothèse d’une forte confiance est erronée et quelque peu contraire à une grande partie de la philosophie de la blockchain. Ces questions sont abordées ci-dessous.
Solution hybride
Certaines solutions sont un mélange de ce qui précède. Par exemple, il est possible de se propager avec autorisation mais de s'exécuter sans autorisation (en supposant que l'hypothèse de confiance soit vérifiée), ou vice versa. Un exemple courant de solution hybride est une vente aux enchères de flux d’ordres.
L’idée générale derrière ces conceptions est que les utilisateurs ayant besoin de contreparties peuvent 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 inclut généralement une partie de confiance qui reçoit l'intention (ou la transaction) de l'utilisateur 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 peuvent être soumis à de nombreuses préoccupations liées au regroupement d'intentions autorisé, mais certaines différences importantes apparaîtront plus tard.
En résumé : les applications basées sur l'intention impliquent non seulement de nouveaux formats de messages pour interagir avec les contrats intelligents, mais elles impliquent également des mécanismes alternatifs de propagation et de découverte de contreparties de type mempool. Concevoir un mécanisme de découverte et de mise en correspondance d'intentions qui soit à la fois compatible avec les incitations et décentralisé n'est pas une tâche facile.
Qu'est-ce qui pourrait mal se passer ?
Bien que les intentions constituent un nouveau paradigme de transaction passionnant, leur adoption généralisée pourrait signifier que la tendance plus large de l'activité des utilisateurs vers des pools de mémoire 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 en quête de rente.
flux de commandes
Si les intentions sont autorisées à s’exécuter, mais que l’ensemble des autorisations n’est pas choisi avec soin, la migration hors du pool de mémoire publique pourrait conduire à une concentration de la production de blocs Ethereum.
La grande majorité de la production de blocs sur Ethereum se fait actuellement via MEV-Boost, une implémentation hors protocole de Proposer-Builder Separation (PBS), et la feuille de route actuelle ne donne aucune indication sur la mise en œuvre prochaine de cette interface. PBS s'appuie sur l'existence d'un marché concurrentiel pour les constructeurs de blocs pour diriger MEV vers l'ensemble des validateurs. Un problème majeur dans PBS est que les constructeurs de blocs peuvent obtenir un accès exclusif aux matières premières nécessaires à la production de blocs de valeur – transactions et intentions, également connues sous le nom de « flux de commandes ». Dans le langage de PBS, l'accès autorisé aux intentions sera appelé « Flux de commandes exclusif » (EOF). Comme indiqué dans cet article, le fait qu’EOF soit entre les mains de la mauvaise partie menace la structure du marché sur laquelle repose PBS, car l’exclusivité du flux d’ordres constitue un fossé contre les forces concurrentielles.
Les constructeurs de blocs (ou entités coopératives) qui contrôlent la majorité du flux de commandes d’Ethereum seront en mesure de 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 apporter de la valeur aux validateurs (sous peine d’être détruit à l’avenir), la domination d’un seul constructeur constituera un transfert de valeur d’Ethereum vers le constructeur. La recherche de rente et la censure constituent sans aucun doute des menaces importantes pour l’accord.
confiance
Étant donné que de nombreuses solutions nécessitent la confiance dans des intermédiaires, le développement de nouvelles architectures basées sur l'intention est entravé par des barrières à l'entrée élevées, ce qui signifie des taux d'innovation et de concurrence plus faibles pour garantir 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 dans le cas du monopole de construction de blocs décrit dans la section précédente. Dans un tel monde, les monopoles de construction de blocs seraient en mesure d’extraire des rentes, et toute nouvelle proposition sur la manière de gérer les intentions serait rejetée si les constructeurs ne les adoptaient pas. Les utilisateurs individuels perdent leur pouvoir de négociation face à un monopole – un effet qui est exacerbé lorsque les utilisateurs utilisent leurs intentions pour offrir aux intermédiaires des degrés de liberté supplémentaires.
Malheureusement, la stagnation du marché due à la centralisation des infrastructures n’inclut pas les inquiétudes concernant le marché des constructeurs. Même pour les entreprises qui ne construisent pas de blocs, des barrières à l’entrée plus élevées confèrent un avantage aux intermédiaires car ils sont confrontés à peu de concurrence. Par exemple, considérons l’état actuel du marché des enchères de flux d’ordres. Plusieurs entités telles que Flashbots et CoWswap reçoivent la majorité des flux de commandes vers OFA. La répartition des flux de commandes est largement due au fait que ces entités existent depuis de nombreuses 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 un nouveau design 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 réputés et qu'ils n'abuseront pas de leur pouvoir. La nécessité de cette campagne visant à gagner la confiance constitue certainement une barrière importante à l’entrée.
Le marché des enchères de 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 dans lequel un pool de mémoire autorisé et fiable peut servir un petit nombre de participants puissants, nuisant ainsi à le meilleur intérêt des utilisateurs.
Le format d'intention EIP4337 fournit un autre exemple de mécanisme possible. Imaginons un monde dans lequel une architecture fiable est en place pour prendre en charge les intentions 4 337. Et si un autre format d'intentions était proposé - peut-être pour servir des cas d'utilisation supplémentaires tels que des fonctionnalités inter-domaines - mais que les intermédiaires de confiance établis n'adoptaient pas ce nouveau format (après tout, il n'a pas beaucoup d'adoption et de pertinence pour leur entreprise) concours de modèles), la mise en œuvre du nouveau format nécessite d'établir la confiance dans la nouvelle entité. De même, nous nous trouvons dans des situations où nous innovons et remettons en question le statu quo, mais où nous 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 abandonnent un certain contrôle sur leurs actifs en chaîne et que les pools de mémoire autorisés impliquent un certain degré d'impénétrabilité externe, nous courons le risque de construire un système opaque dans lequel personne ne sait comment ou si les attentes des utilisateurs sont satisfaites et Les menaces qui pèsent sur l’écosystème restent inconnues.
La section ci-dessus traite des risques que les déséquilibres de pouvoir sur le marché des flux d’ordres posent aux utilisateurs et aux protocoles. Un problème connexe est que l’écosystème de middleware et de mempools qui se développe entre les utilisateurs et la blockchain est devenu opaque, même pour les observateurs avisés. Cette préoccupation est particulièrement pertinente pour les applications basées sur l'intention qui cherchent à permettre aux utilisateurs d'externaliser des décisions importantes telles que le routage des commandes.
Les situations dans lesquelles MEV a un impact négatif sur l'exécution de l'utilisateur sont généralement dues au fait que le bourreau abandonne des transactions très libérales (par exemple, les limites de glissement). Il n’est donc pas très logique d’affirmer que les applications basées sur l’intention qui renoncent à une plus grande liberté devraient concevoir leurs systèmes d’exécution avec plus de soin. Le pire résultat à cet égard est un monde dans lequel l'utilisation d'applications basées sur l'intention nécessite de signer une intention qui disparaît (une forêt sombre, si vous préférez), puis implémentée d'une manière ou d'une autre en tant que transaction, mais il n'est pas clair comment ni qui a créé la transaction. Bien entendu, la capacité de surveiller de tels écosystèmes est également liée aux préoccupations concernant l’EOF et les défenses basées sur la confiance.
Atténuer les risques
Le pool de mémoire Ethereum est limité. Pour certaines applications, cela est dû à leur manque de confidentialité (prise en sandwich), tandis que pour d'autres, cela est dû à leur incapacité à prendre en charge un plus large éventail de formats de messages. Cela met les développeurs de portefeuilles et d’applications dans une position difficile, car ils doivent trouver un moyen de connecter les utilisateurs à la blockchain tout en évitant les dangers mentionnés ci-dessus.
En examinant les questions ci-dessus, nous pouvons déduire certaines propriétés d’un système idéal. Un tel système doit être sans autorisation afin que n'importe qui puisse faire correspondre et exécuter des intentions sans trop sacrifier la qualité d'exécution ; universel afin que le déploiement de nouvelles applications ne nécessite pas la création de nouveaux pools de mémoire et transparent afin qu'il soit public. Rapports sur le processus d'exécution ; intentions et fournit des données pour effectuer des audits de qualité lorsque les garanties de confidentialité le permettent.
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 n'est peut-être pas prêt de si tôt. Par conséquent, différentes solutions peuvent mieux servir différentes applications avec leurs propres compromis. Même si des mécanismes tels que les crlists, apparus en réponse à bon nombre des mêmes problèmes liés aux applications basées sur les transactions, peuvent ne pas fonctionner correctement avec les intentions, les gadgets qui permettent aux utilisateurs de revenir aux transactions lorsque cela est possible peuvent bien fonctionner, améliorant ainsi le pire des cas. , une application souhaitant lancer un pool d'intentions ferait mieux de rechercher des généralités sans autorisation et de choisir soigneusement un intermédiaire avec autorisation.
D’une manière générale, nous demandons aux concepteurs d’applications basées sur l’intention de réfléchir attentivement à l’impact hors chaîne de leurs applications, car celles-ci peuvent toucher une communauté plus large que la simple base d’utilisateurs. La communauté accorde une attention particulière à l’écosystème hors chaîne entourant Ethereum.
en conclusion
L'adoption des intentions représente un passage du paradigme impératif au paradigme déclaratif, qui devrait améliorer considérablement l'expérience utilisateur et les pertes d'efficacité dues au MEV. La nécessité de ces applications est claire et de nombreuses applications basées sur l'intention sont largement utilisées depuis de nombreuses années.
L’adoption croissante des intentions, motivée par ERC4337, pourrait accélérer le passage du mempool Ethereum vers de nouveaux sites. Bien que cette décision soit raisonnable et inévitable, les concepteurs d'applications basées sur l'intention ont de bonnes raisons de concevoir soigneusement les composants hors chaîne de leurs systèmes tout en développant une infrastructure robuste.
Il reste encore beaucoup de recherche et d’ingénierie à faire dans ce paradigme transactionnel naissant et dans des domaines que nous n’avons pas abordés dans cet article, comme la conception d’un langage d’expression d’intention qui permet la confidentialité.
Un grand merci à Dan Robinson, Charlie Noyes, Matt Huang, John Guibas, Xinyuan Sun et Elijah Fox pour leurs commentaires sur cet article, ainsi qu'à Achal Srinivasan pour sa conception.
