Paradigme : l'architecture basée sur l'intention et ses risques

Écrit par : Quintus Kilbourn, Georgios Konstantopoulos Compilé par : Kate, Marsbit

introduire

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 font explicitement référence à « comment » une action doit être exécutée, l’intention fait référence au résultat attendu de cette action. Si le contenu de la transaction est « faites A d'abord, puis B, payez C pour obtenir X », alors l'intention est « Je veux X et je suis prêt à payer C ».

Ce paradigme déclaratif apporte des améliorations passionnantes en termes d’expérience utilisateur et d’efficacité. Avec les intentions, les utilisateurs peuvent simplement exprimer un résultat souhaité tout en sous-traitant la tâche visant à obtenir ce résultat de manière optimale à un tiers expérimenté. Le concept d’intention 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 un pas en avant indispensable pour l’écosystème, la conception basée sur l’intention sur Ethereum pourrait également avoir des implications significatives pour l’infrastructure hors chaîne. Il existe notamment des liens importants entre les activités liées au MEV et le contrôle du marché. Cet article vise à fournir une brève définition de l'intention et de ses avantages, à explorer les risques impliqués dans sa mise en œuvre et à discuter des atténuations potentielles.

Qu'est-ce qu'une intention ?

La manière standard actuelle pour les utilisateurs d'interagir avec Ethereum consiste à créer et à signer des transactions qui fournissent toutes les informations nécessaires dans un format spécifique pour que la machine virtuelle Ethereum (EVM) puisse effectuer des transitions d'état. Cependant, créer des transactions peut être une affaire compliquée. Créer une transaction nécessite de raisonner sur des détails tels qu'un vaste réseau de contrats intelligents et une gestion occasionnelle, tout en détenant un actif spécifique 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 accès adéquat aux informations ni politiques d’application complexes.

Il existe une intention d’alléger ces fardeaux. De manière informelle, les intentions sont signées comme un ensemble de contraintes déclaratives qui permettent aux utilisateurs de sous-traiter la création de transactions à des tiers sans renoncer au contrôle total des parties à la transaction.

Dans les processus standards basés sur les transactions, les signatures de transaction permettent aux validateurs de suivre exactement un chemin de calcul pour un état, et des indices incitent les validateurs à le faire. Les intentions, en revanche, ne spécifient pas le 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 l'autorisation de choisir les chemins de calcul en leur nom (voir le schéma ci-dessous). Cette distinction permet une définition légèrement plus stricte des intentions 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 « l’intention » des transactions.

*Figure 1 : Lors de la soumission d'une transaction, l'utilisateur précise le chemin de calcul exact. Lors de la soumission d'une intention, l'utilisateur spécifie un objectif et certaines contraintes, puis le processus de mise en correspondance décide du chemin de calcul à suivre. *

Il est important de noter que de nombreuses intentions peuvent être incluses dans une seule transaction, ce qui permet de faire correspondre les 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 s'annuler avant d'entrer sur le marché. D'autres applications incluent des intentions inter-domaines (signature d'un seul message, plutôt que plusieurs transactions sur différents domaines) en utilisant différents schémas de résistance à la relecture et des paiements de gaz utilisateur plus flexibles, par exemple en permettant à des tiers de sponsoriser du gaz ou de payer du gaz avec différents paiements par jetons. .

le passé et le futur sont des intentions

L'intention a été créée d'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é : 100X peuvent être débités de mon compte si je reçois au moins 200Y.
• Enchères de style CowSwap : comme ci-dessus, mais s'appuient sur un tiers ou un mécanisme pour faire correspondre de nombreux ordres afin de maximiser la qualité d'exécution.
• Parrainage du gaz : payez le gaz avec USDC au lieu d'ETH. Cette intention ne peut être réalisée que par une intention correspondante qui paie des frais à l'ETH.
• Autorisation : autorisez uniquement l'interaction avec certains comptes de certaines manières préautorisées. Une intention ne peut être réalisée que si la transaction résultante obéit à la liste de contrôle d'accès spécifiée dans l'intention.
• Regroupement de transactions : permet le regroupement d'intentions pour améliorer l'efficacité et réduire les frais de gaz.
• Agrégateurs : fonctionnent en utilisant uniquement le « meilleur » rapport prix/rendement. Cet objectif peut être atteint en prouvant que l'agrégation de plusieurs lieux est effectuée et que le meilleur chemin est emprunté.

À l’avenir, l’intention est revigorée dans le contexte des MEV inter-chaînes (tels que SUAVE), des abstractions de comptes de style ERC4337 et même des commandes Seaport ! Alors que l'ERC4337 avance à toute vitesse, d'autres nouvelles applications telles que les intentions inter-domaines nécessitent encore des recherches plus approfondies. Une discussion plus approfondie sur les intentions et leurs applications peut être trouvée dans cet exposé.

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 l'exécuter et est capable d'exécuter l'intention en temps opportun. Qui sont ces parties, comment l'exécution a lieu et quelles sont leurs motivations sont des questions qui 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 pool de mémoire

Le canal le plus évident est le pool de mémoire Ethereum. Malheureusement, la conception actuelle ne prend pas en charge la propagation d'intention. Les inquiétudes concernant les attaques DoS peuvent signifier que la prise en charge générale d’une intention entièrement générale dans le pool de mémoire Ethereum est impossible, même à long terme. Comme nous le verrons ci-dessous, la nature ouverte et sans autorisation du pool de mémoire Ethereum présente un obstacle supplémentaire aux intentions d’adoption.

En l’absence d’un pool de mémoire Ethereum, les concepteurs de systèmes d’intention sont désormais confrontés à certains problèmes de conception. Une décision de haut niveau consiste à savoir s'il faut propager l'intention à un ensemble autorisé ou la fournir sans autorisation afin que l'une ou l'autre des parties puisse exécuter l'intention.

Figure 2 : Les intentions circulent des utilisateurs vers des pools d'intentions autorisés/sans autorisation et publics/privés, convertis par les entremetteurs en transactions, et enfin vers des pools de mémoire publics ou directement en chaîne via des enchères de type boost MEV

Pool de mémoire sans licence

Une conception que l'on pourrait rechercher est une API décentralisée qui permet à l'intention de se propager à travers les nœuds du système, offrant ainsi aux exécuteurs testamentaires un accès sans autorisation. Cela a déjà été fait. Par exemple, dans le protocole 0x, les relayeurs discutent entre eux des ordres limités et les placent en chaîne en cas de correspondance. Cette idée a également été explorée dans le contexte d’un pool de mémoire partagé 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 :

• Résistance au DoS : il peut être nécessaire de limiter la fonctionnalité des intentions pour éviter les vecteurs d'attaque (voir la proposition ER C4337 pour une discussion plus approfondie)
• Propager les incitations : pour de nombreuses applications, faire respecter l'intention est une activité rentable. Par conséquent, les nœuds exploitant le pool d’intentions sont incités à ne pas propager les intentions 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, ce qui peut être difficile lors de l'utilisation de pools d'intentions publics et sans autorisation. Si une mauvaise exécution est rentable, les pools d’intentions sans autorisation sont susceptibles de conduire à ce résultat. Ceci est similaire aux mempools Ethereum aujourd’hui et devrait devenir un problème courant lié à DeFi. Une voie possible ici pourrait être des pools d’intentions sans autorisation mais cryptés.

"pools de mémoire" autorisés

Les API centralisées de confiance sont plus résistantes aux attaques DoS et n'ont pas besoin de propager l'intention. Les modèles de confiance fournissent également une certaine base pour les problèmes MEV. Tant que l’hypothèse de confiance est valable, la qualité de l’exécution doit être garantie. Les intermédiaires de confiance peuvent également avoir une réputation qui leur est associée, ce qui les incite à bien exécuter leurs activités. Par conséquent, les pools d’intentions autorisés sont attrayants pour les développeurs d’applications basées sur l’intention à court terme. Cependant, nous sommes tous conscients que l’hypothèse d’une confiance forte est erronée et quelque peu contraire à une grande partie de la philosophie des blockchains. Ces questions sont abordées ci-dessous.

Solution hybride

Certaines solutions sont des mélanges de ce qui précède. Par exemple, il peut y avoir une autorisation de propagation, mais aucune 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 générale derrière ces conceptions est que les utilisateurs qui ont 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). Les flux de conception incluent généralement une partie de confiance qui reçoit les intentions (ou transactions) des utilisateurs et facilite les enchères au nom des utilisateurs. La participation aux enchères (parfois) ne nécessite pas d'autorisation.

Ces types de conceptions ont leurs propres inconvénients et sont susceptibles d'être concernés par de nombreux groupes d'intentions d'autorisation, mais certaines distinctions importantes apparaîtront plus tard.

Conclusion : les applications basées sur l'intention n'impliquent pas seulement de nouveaux formats de message pour interagir avec les contrats intelligents, elles impliquent également des mécanismes de propagation et de découverte d'adversaires sous la forme de pools de mémoire alternatifs. 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 trivial.

Où puis-je me tromper ?

Bien que les intentions constituent un nouveau paradigme de transaction passionnant, leur adoption généralisée pourrait signifier l’accélération d’une tendance plus large consistant à déplacer l’activité des utilisateurs vers d’autres pools de mémoire. S’il n’est pas géré correctement, ce changement pourrait conduire à la centralisation et au renforcement des intermédiaires en quête de rente.

Flux de commande

La migration à partir du pool de mémoire public pourrait centraliser la production de blocs d'Ethereum si l'exécution d'intention est autorisée et si l'ensemble d'autorisations n'est pas choisi avec soin.

La migration à partir du pool de mémoire public pourrait centraliser la production de blocs dans Ethereum si l'exécution de l'intention est autorisée, mais l'ensemble d'autorisations n'est pas choisi avec soin.

La grande majorité de la production de blocs sur Ethereum se fait 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 changera bientôt. 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 avec PBS est que les constructeurs de blocs obtiennent un accès exclusif aux matières premières nécessaires à la production de blocs de valeur – transactions et intentions, également appelés « flux de commandes ». Dans le langage PBS, l'accès autorisé aux intentions est connu sous le nom de flux de commandes exclusif (EOF). Comme indiqué dans cet article, un EOF entre les mains de la mauvaise partie menace la structure du marché sur laquelle repose le PBS, car l’exclusivité du flux d’ordres implique 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 seront en mesure de produire la majorité des blocs du réseau principal, ouvrant ainsi la voie à la censure. Étant donné que le réseau s’appuie sur la concurrence entre les constructeurs pour transmettre 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 les constructeurs. La recherche de rente et la censure constituent bien entendu des menaces importantes pour le protocole.

confiance

Étant donné que de nombreuses solutions nécessitent la confiance dans un intermédiaire, 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 se retrouvent dans une position où une seule partie exécute l'intention, comme le constructeur de blocs monopolistiques de la section précédente. Dans un tel monde, les constructeurs de blocs monopolistiques seraient en mesure d’extraire des rentes, et toute nouvelle proposition sur la manière 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 entendent accorder davantage de liberté aux intermédiaires.

Malheureusement, la stagnation du marché due à la centralisation des infrastructures ne tient pas compte des préoccupations concernant le marché des constructeurs. Même pour les entreprises de construction sans bloc, une barrière à l’entrée élevée peut placer les intermédiaires dans une position avantageuse, car ils sont confrontés à peu de concurrence. Par exemple, considérons l’état actuel du marché des enchères de flux d’ordres. Quelques entités comme Flashbots et CoWswap reçoivent la plupart des commandes acheminées vers OFA. Le flux de commandes est réparti 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 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. Ce besoin de 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 où des pools de mémoire autorisés et fiables peuvent contenir un petit nombre de participants puissants, nuisant ainsi au marché. meilleurs intérêts des utilisateurs.

Le format d'intention EIP4337 fournit un autre exemple de mécanisme possible. Imaginez un monde où des architectures fiables sont en place pour prendre en charge les intentions 4 337. Si un autre format d'intention était proposé, il pourrait servir à d'autres cas d'utilisation comme la fonctionnalité cross-origin, mais les intermédiaires de confiance établis n'adoptent pas ce nouveau format (après tout, il n'est pas beaucoup adopté et entre en concurrence avec leur modèle commercial). du nouveau format devra établir la confiance dans la nouvelle entité. Une fois de plus, nous nous trouvons dans une situation où l’innovation et la remise en question du statu quo se heurtent à des barrières à l’entrée basées sur la confiance.

Opacité

Étant donné que de nombreuses architectures d'intention exigent que les utilisateurs abandonnent un certain contrôle sur leurs actifs en chaîne et que les mempools autorisés impliquent un certain degré d'imperméabilité de l'extérieur, nous courons le risque de construire un système opaque dans lequel ce que les utilisateurs attendent ou s'il est satisfait n'est pas clair. , et les menaces qui pèsent sur l’écosystème restent non détectées.

Les sections ci-dessus traitent des risques que les déséquilibres de pouvoir sur les marchés de flux d’ordres posent aux utilisateurs et aux protocoles. Un problème connexe est que l’écosystème de middleware et de mempools développé entre les utilisateurs et la blockchain devient opaque, même pour les observateurs avertis. Ce problème s'applique particulièrement aux applications basées sur l'intention qui tentent de 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 des utilisateurs sont souvent dues au fait que les transactions cèdent un haut degré de liberté à leurs exécuteurs (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 offrent de plus grands degrés de liberté devraient concevoir plus soigneusement leurs systèmes d’exécution. Le pire résultat à cet égard est que 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 préférez), qui est ensuite implémentée d'une manière ou d'une autre comme une transaction sans qu'il soit clair comment ni par qui elle a été créée. 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. Si cet écosystème est obscur pour les observateurs les plus avertis, comment la communauté Ethereum est-elle censée surveiller les menaces qui pèsent sur la santé de son écosystème de production de blocs ?

Atténuer le risque

Le pool de mémoire Ethereum est limité. Pour certaines applications, cela est dû à son manque de confidentialité (pris en sandwich au milieu), et 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 devrait être

Sans autorisation afin que n'importe qui puisse faire correspondre et exécuter les intentions sans trop sacrifier la qualité d'exécution

Générique pour que le déploiement de nouvelles applications ne nécessite pas la création de nouveaux pools de mémoire,

Transparent afin que le processus d'exécution de l'intention de reporting soit rendu public lorsque les garanties de confidentialité le permettent, et fournisse 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 n'est peut-être pas prêt de si tôt. Par conséquent, différentes solutions font leurs propres compromis qui peuvent servir au mieux différentes applications. Bien que des mécanismes tels que les crlists soient apparus en réponse à bon nombre des mêmes problèmes liés aux applications basées sur les transactions, et peuvent ne pas être applicables à l'intention, un gadget permettant aux utilisateurs de recourir aux transactions chaque fois que cela est possible ferait bien d'améliorer le pire des cas. De même, les applications souhaitant créer un pool d’intentions, si elles n’y sont pas autorisées, feraient bien de rechercher des points communs et, si elles le font, de choisir soigneusement les intermédiaires.

D'une manière générale, nous demandons aux concepteurs d'applications basées sur l'intention de prendre pleinement en compte l'impact hors chaîne de leurs applications, car celles-ci peuvent toucher la communauté au sens large, pas seulement leur base d'utilisateurs, et nous demandons à la communauté au sens large de se concentrer étroitement sur le hors chaîne. écosystème autour d’Ethereum.

en conclusion

L'adoption des intentions représente le passage d'un paradigme impératif à un paradigme déclaratif, qui promet d'améliorer considérablement l'expérience utilisateur et les pertes d'efficacité dues aux fuites 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’intention croissante d’adopter, motivée par ERC4337, pourrait accélérer le transfert des mempools Ethereum vers de nouveaux sites. Bien que ce changement 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 lors du développement d’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é. Si vous trouvez intéressant ce sujet ou d’autres sujets de recherche liés à l’intention, veuillez contacter 0xquintus georgios@paradigm.xyz.

*Un grand merci à Dan Robinson, Charlie Noyes, Matt Huang, John gu, Xinyuan Sun et Elijah Fox pour leurs commentaires sur cet article, et à Achal Srinivasan pour la conception des graphiques. *