Comment « le calcul d'intention » peut-il transformer l'interaction Web3 en brisant l'impasse de la mauvaise expérience utilisateur ?
TechFlow SélectionTechFlow Sélection
Comment « le calcul d'intention » peut-il transformer l'interaction Web3 en brisant l'impasse de la mauvaise expérience utilisateur ?
Grâce à l'intention, les utilisateurs peuvent facilement exprimer leur résultat attendu, ce qui contraste fortement avec les transactions impératives actuelles.
Dédié à des analyses Web3 approfondiesRédaction : Bastian Wetzel
Traduction : TechFlow
Il s'avère que l'utilisation des divers systèmes actuels dans Web3 est complexe et chronophage. Cela implique de spécifier des chemins d'exécution entre différentes infrastructures, ce qui exige une compréhension approfondie. En conséquence, les utilisateurs rencontrent des frustrations constantes dans la réalisation de leurs objectifs finaux et sont vulnérables à l'exploitation par des participants plus sophistiqués.
Cette situation découle du fait que la méthode standard dominante pour interagir avec Ethereum nécessite de créer et signer des transactions selon un format spécifique, fournissant toutes les informations nécessaires au machine virtuelle Ethereum (EVM) pour effectuer des transitions d'état.
L'introduction des intentions vise à alléger le fardeau des utilisateurs. Fondamentalement, une intention est un ensemble de contraintes déclaratives permettant à l'utilisateur de déléguer la création de transactions à un réseau de tiers spécialisés, tout en conservant un contrôle total sur le processus. Autrement dit, si une transaction précise « comment » exécuter une opération, une intention définit « quel résultat souhaité » atteindre.
Cette approche déclarative apporte des avancées prometteuses en termes d'expérience utilisateur et d'efficacité. Grâce aux intentions, les utilisateurs peuvent facilement exprimer leur résultat attendu, contrairement aux transactions impératives actuelles où chaque paramètre doit être explicitement défini par l'utilisateur.
Les transactions (Tx) sont une impasse pour les utilisateurs finaux
L'approche actuelle basée sur les Tx dans Web3 s'est révélée complexe, entraînant une mauvaise expérience utilisateur et des pertes d'efficacité, car les utilisateurs sont contraints de prendre des décisions sans accès suffisant à l'information ni possibilité d'utiliser des stratégies d'exécution complexes.
Pour illustrer cette complexité, considérons le scénario suivant : vous souhaitez interagir avec une application décentralisée (dApp) sur le réseau Arbitrum, mais vos fonds sont actuellement stockés sur la blockchain Ethereum :
-
Accédez au site web de la dApp
-
Essayez de connecter votre portefeuille à Arbitrum, mais constatez qu'aucun fond n'est disponible
-
Ouvrez un nouvel onglet pour explorer la meilleure méthode de transfert de vos fonds entre chaînes
-
Allez vers un pont跨链
-
Connectez votre portefeuille à une autre blockchain (Ethereum)
-
Transférez vos fonds d'Ethereum vers Arbitrum
-
Attendez la finalisation du transfert跨链
-
Retournez à l'onglet initial
-
Recommutez votre portefeuille vers Arbitrum
-
Vous pouvez maintenant enfin utiliser la dApp sur Arbitrum avec les fonds transférés.
Avant même d'interagir avec la dApp elle-même, l'utilisateur ressent déjà de la frustration. Dans un monde futur composé de millions de Rollups, ces problèmes deviennent encore plus évidents.
Comment pouvons-nous alors passer du paradigme impératif au paradigme déclaratif ? Pour comprendre les principes fondamentaux, permettez-moi d'abord de résumer brièvement le concept d'abstraction des comptes (AA).
Rappel bref sur l'abstraction des comptes
Sur Ethereum, il existe deux types d'adresses : les contrats intelligents et les comptes possédés extérieurement (EOA).
Les EOA ont la capacité d'initier des transactions, contrairement aux contrats intelligents. Ainsi, la plupart des portefeuilles Ethereum utilisés aujourd'hui sont des EOA. Bien qu'il existe des portefeuilles basés sur contrats intelligents (SCW), comme Safe, ceux-ci nécessitent toujours un EOA pour déclencher toute transaction, car les contrats intelligents ne peuvent pas initier eux-mêmes des transactions. Néanmoins, les SCW offrent des avantages significatifs, car ils peuvent exécuter une logique complexe, ouvrant ainsi de nouvelles fonctionnalités pour les portefeuilles, tandis que les EOA se limitent à la signature.
Pour répondre à la demande croissante de SCW sans dépendre d'un EOA séparé, ERC-4337 a introduit un nouveau type de transaction appelé « UserOp », ainsi qu’un nouveau rôle nommé « Bundlers ». De plus, ERC-1271 (méthode standard de vérification des signatures pour les contrats) a défini une méthode standard pour valider si une signature donnée pour un contrat est valide. Ces mises à jour améliorent l'expérience utilisateur des SCW, offrant un flux plus fluide. Le processus précis est le suivant :
-
L'utilisateur signe un UserOp spécifiant l'opération souhaitée. Ce UserOp n'est pas envoyé directement au mempool principal, mais plusieurs utilisateurs l'envoient à un mempool alternatif. Là, les exécuteurs (executors) et les Bundlers interviennent pour regrouper ces UserOps et les soumettre sous forme de paquet à un contrat d'entrée. Ce dernier communique ensuite avec le portefeuille intelligent.
-
Une fois que le SCW reçoit le UserOp groupé, il passe par un processus en deux étapes. Premièrement, il exécute ValidateOp, qui consiste à vérifier le signataire approprié, le contrôle d'accès et les limitations de taux afin de garantir que l'opération est légitime et sécurisée. Après validation réussie, le SCW passe à l'étape ExecuteOp pour exécuter l'opération. Celle-ci peut inclure des tâches telles que le transfert de fonds, l'exécution d'échanges ou l'achat de NFT.
Un avantage clé de l'abstraction des comptes est l'abstraction du gaz, qui simplifie le paiement du gaz par l'utilisateur. C'est là qu'intervient le paymaster. Un contrat paymaster agit comme une entité tierce. Lorsqu'un utilisateur envoie une transaction, le UserOp est dirigé vers le contrat paymaster. Celui-ci valide et garantit qu'il couvrira le coût en gaz de la transaction. Il rembourse aux Bundlers la quantité correspondante de jeton natif de gaz, servant ainsi de mécanisme de remboursement. Seulement après traitement de ce paiement en gaz, le UserOp passe par les phases ValidateOp et ExecuteOp.
Le paymaster permet également à l'utilisateur d'exécuter d'autres opérations après l'exécution du UserOp, offrant ainsi une flexibilité et un contrôle supplémentaires. En exploitant le paymaster et l'abstraction du gaz, les utilisateurs peuvent effectuer des transactions sans avoir à gérer directement les coûts en gaz, rendant le processus plus fluide et convivial.
Une limitation de l'AA est son incapacité à supporter les paymasters跨链. Considérons le scénario suivant : un utilisateur détient des USDC sur son SCW sur le réseau Ethereum, mais souhaite utiliser un paymaster pour payer les frais de transaction sur le réseau Arbitrum. Un problème survient lorsque le paymaster tente, lors de la fonction post-opération, de transférer les USDC de l'utilisateur vers lui-même. Les USDC sont stockés sur Ethereum, tandis que le contrat paymaster se trouve sur Arbitrum. En résumé, l'abstraction des comptes est principalement conçue pour un usage mono-domaine et manque de capacité intrinsèque à fonctionner de manière transparente sur plusieurs chaînes.
Applications spécifiques aux intentions
L'abstraction des comptes est souvent résumée comme « transactions sans gaz », « récupération sans phrase mnémonique » et éventuellement « limitation de taux ». Oui, ces fonctionnalités sont intéressantes, mais pas assez impressionnantes. Elles ne capturent peut-être pas pleinement l'essence véritablement attrayante de l'AA. L'aspect le plus fascinant de l'abstraction des comptes réside dans son architecture, qui transforme les portefeuilles en points d'entrée pour les intentions.
Qu'est-ce qu'une intention ?
Dans un processus de transaction classique, lorsqu'un validateur reçoit une signature de transaction, il suit un chemin de calcul spécifique selon un état donné. De plus, des frais servent d'incitation pour que les validateurs agissent ainsi. Toutefois, avec les intentions, la situation diffère. Une intention ne prescrit pas un chemin de calcul fixe, mais autorise tout chemin satisfaisant certaines conditions. Lorsqu'un utilisateur signe et partage une intention, il autorise le destinataire à choisir le chemin de calcul en son nom. Cette distinction fait que les intentions sont définies plus précisément comme des messages signés facilitant une série de transitions d'état à partir d'un point de départ donné.
Il convient de noter qu'une seule transaction peut contenir plusieurs intentions, permettant ainsi l'appariement d'intentions superposées. Cela améliore considérablement l'efficacité économique et en gaz. Par exemple, dans un carnet d'ordres maintenu par des builders, deux ordres peuvent être efficacement annulés l'un par l'autre avant d'atteindre le marché. De plus, les intentions permettent un paiement plus flexible du gaz par l'utilisateur, par exemple en autorisant un tiers à parrainer le gaz ou en acceptant des paiements en différents jetons.
Par conséquent, les UserOps ne sont pas des intentions, car ils sont essentiellement des Tx. Toutefois, l'AA fait des portefeuilles des entrées pour les intentions, grâce à la logique de validation intégrée aux portefeuilles intelligents. Cette logique permet d'exprimer et d'exécuter des intentions simples liées au compte utilisateur. Cependant, les SCW manquent de capacité à raisonner sur l'état global.
Fondamentalement, l'abstraction des comptes sert des « intentions spécifiques ». Dans ce cas, l'utilisateur peut spécifier et mettre en œuvre des intentions simplifiées via son SCW, à condition qu'elles respectent certaines exigences restrictives :
-
Elles se concentrent sur un domaine unique ;
-
Elles n'utilisent et n'exécutent que des informations liées au compte de l'utilisateur ;
-
Elles impliquent une compensation en gaz.
Exemples d'applications spécifiques aux intentions
Ainsi, l'abstraction des comptes répond principalement à des objectifs centrés sur l'utilisateur. Toutefois, de nombreux exemples d'applications « spécifiques aux intentions » peuvent être réalisés grâce à l'AA, comme souligné par Paradigm :
-
Ordres à cours limité : l'utilisateur peut spécifier que 100 jetons X ne doivent être retirés de son compte que s'il reçoit au moins 200 jetons Y.
-
Parrainage du gaz : l'utilisateur peut choisir de payer les frais de transaction en USDC au lieu d'ETH, et allouer des USDC dans son compte pour couvrir les frais de gaz du paymaster.
-
Délégation : les interactions avec un compte spécifique peuvent être limitées de manière préautorisée. Par exemple, des ETH peuvent être désignés uniquement pour acheter un NFT listé sur OpenSea, ou une adresse spécifique peut être restreinte à interagir uniquement avec Uniswap et Sushiswap.
-
Traitement par lots : l'utilisateur peut autoriser le regroupement de plusieurs intentions dans une seule transaction pour améliorer l'efficacité en gaz.
-
Agrégateurs : l'utilisateur peut spécifier l'exécution d'une opération donnée au « meilleur » prix ou rendement. Cette intention peut être réalisée en fournissant une preuve exécutant un agrégat sur plusieurs plateformes et choisissant le meilleur chemin.
Bien que l'AA et les applications spécifiques aux intentions soient des progrès importants, elles présentent aussi des limites dans les environnements multi-chaînes. Prenons le scénario suivant : je possède de l'ETH et souhaite acheter le maximum possible de jetons XYZ en exploitant la liquidité disponible sur différents Rollups. Avec l'AA, je peux facilement et rapidement utiliser mon agrégateur DEX préféré sur n'importe quel Rollup. Cependant, le défi réside dans le fait que je dois encore découvrir manuellement quel est le meilleur agrégateur DEX disponible sur tous les Rollups.
Par conséquent, dans un monde multi-chaînes, il est nécessaire d'avoir un langage d'intentions complet et flexible capable d'améliorer efficacement la scalabilité.
Solution universelle
Dans un monde centré sur les intentions, les utilisateurs déclarent ou signent leurs préférences, et le réseau s'appuie sur des tiers participants (solveurs/exécuteurs) pour exécuter ces préférences en leur nom.
Il est important de noter que la méthode actuelle basée sur les transactions permet également aux utilisateurs de sous-traiter la création de transactions, mais la différence réside dans l'identité du tiers. Actuellement, les applications construisent les transactions pour les utilisateurs, mais sans optimisation pour obtenir les meilleurs résultats. L'innovation des intentions ne réside donc pas dans la délégation de la création de transactions à un tiers, mais dans l'ajout d'un réseau spécialisé de tiers capables de fournir de meilleurs résultats.
Cela peut améliorer l'efficacité d'exécution, car ces solveurs peuvent intégrer davantage d'informations sur l'état des autres chaînes sans nécessiter de communication avec l'utilisateur.
Pour illustrer cela, reprenons le scénario où je possède de l'ETH et souhaite acheter le maximum possible de jetons XYZ en exploitant la liquidité entre différents Rollups. Dans un monde centré sur les intentions, je pourrais informer le mempool que je possède de l'ETH et que je veux obtenir la quantité maximale possible de jetons XYZ. Un solveur hautement sophistiqué trouvera efficacement une solution. Les incitations pour ces solveurs devraient conduire à des résultats fortement optimisés. Dans un tel environnement multi-chaînes, même des tâches basiques deviennent irréalistes, par exemple qu'une seule entreprise intègre un agrégateur DEX avec tous les nouveaux Rollups et domaines. Ainsi, dans cet environnement multi-chaînes, les applications spécifiques aux intentions manquent de scalabilité. En revanche, pour les intentions, un langage flexible et universel peut s'échelonner efficacement car il fonctionne comme un système sans permission. Il n'est pas nécessaire qu'une seule entreprise serve d'agrégateur DEX omnichaîne couvrant chaque chaîne. Au lieu de cela, un ensemble de solveurs peut concurrencer pour offrir leurs services aux utilisateurs, certains spécialisés dans certaines catégories de Rollups, d'autres dans différents domaines. Cette approche montre que les intentions跨chain ont une utilité et une capacité importantes, surpassant largement l'abstraction des comptes classique, même pour des cas simples.
L'infrastructure idéale pour exprimer, transmettre et exécuter des intentions devrait minimiser la valeur extractible par les mineurs (MEV), maximiser la résistance à la censure et être optimisée pour les interactions跨domaines. En outre, elle devrait soigneusement équilibrer la communication fine des intentions utilisateur et l'expérience utilisateur, car cette décision a un impact majeur sur l'architecture du protocole d'intention. Enfin, de nombreuses questions restent sans réponse, notamment comment prouver ce qui est optimal, où seront publiées les intentions跨domaines, et comment les solveurs décideront ce qu'ils doivent rechercher.
Exemples de solutions universelles
Bien que cette vision soit prometteuse, la première étape consiste à établir une couche d'intentions où les utilisateurs peuvent exprimer leurs intentions et où les solveurs peuvent rivaliser pour les résoudre. Des projets comme Anoma, SUAVE, Essential et CoW Protocol visent tous à devenir la couche d'intentions de la blockchain, chacun adoptant une approche différente.
Toutefois, comme le concept de couche d'intentions est encore en évolution et que de nombreux principes de conception semblent contradictoires, il est trop tôt pour procéder à une comparaison. Construire une telle couche fait face à d'importants défis.
Anoma est une architecture unifiée pour les applications décentralisées full-stack. Conçue dès le départ pour des applications impliquant un nombre infini d'utilisateurs émettant un nombre illimité d'intentions de complexité variable, Anoma suit les principes d'une architecture centrée sur les intentions et d'une sécurité homogène/hétérogène, formant ainsi un paradigme déclaratif pour construire des applications décentralisées. Les intentions sont soumises à des nœuds de diffusion d'intentions, formant un pool d'intentions. Des matchmakers analysent ces pools pour identifier des intentions pouvant être combinées et mutuellement satisfaites. La machine à états du protocole permet une exécution progressive et une validation découplée via des prédicats valides comme invariants sur les comptes utilisateurs. Anoma simplifie la création d'applications novatrices, difficiles, limitées, voire impossibles à construire sur les protocoles existants type Ethereum (EVM).
SUAVE est un protocole d'enchères unifié pour l'expression de la valeur. SUAVE cherche à responsabiliser les utilisateurs et à réaliser la plus grande décentralisation possible des blockchains publiques. Il dissocie le rôle du mempool et de la construction de blocs des blockchains existantes, offrant une alternative hautement spécialisée et décentralisée, prête à l'emploi. Le partage d'une couche de tri commune permet aux cryptomonnaies de rester décentralisées, aux constructeurs de blocs de capturer le MEV跨domaines, aux validateurs de maximiser leurs revenus, aux utilisateurs d'effectuer des transactions à exécution optimale, tout en réduisant la pression de concentration économique sur chaque domaine. SUAVE constitue un environnement intégré favorisant la collaboration décentralisée dans l'expression, l'exécution et le règlement des préférences. Le concept central est celui de préférence — un message signé par l'utilisateur exprimant un objectif, permettant d'exécuter des transferts simples ou des séquences complexes sur plusieurs blockchains. Les solveurs rivalisent pour fournir la meilleure exécution, y compris la capture du MEV et la valorisation d'un flux d'ordres décentralisé.
Essential développe une suite de produits visant à faire évoluer l'écosystème blockchain d'une logique d'extraction de valeur vers une logique de satisfaction des intentions. Ils créent un langage spécifique aux domaines (DSL) pour exprimer les intentions, une norme Ethereum orientée intentions pour l'abstraction des comptes, ainsi qu'une couche d'intentions modulaire. Le DSL permet une expression normalisée des intentions et une optimisation des solveurs, renforçant la componibilité et le développement d'applications basées sur les intentions. La norme d'abstraction des comptes orientée intentions donne aux solveurs la capacité de construire des transactions efficaces selon les intentions des utilisateurs, intégrant ainsi les fonctionnalités d'intentions aux chaînes EVM existantes. La couche d'intentions modulaire garantit une architecture purement basée sur les intentions, un flux d'ordres agrégé, une résistance au MEV et une exécution d'intentions跨chaînes. La mission d'Essential est d'empouvoir les utilisateurs, d'éliminer l'exploitation et de promouvoir un avenir blockchain centré sur l'utilisateur et équitable.
La technologie CoW Protocol construit un réseau pour les traders et les solveurs, permettant des échanges pair-à-pair fiables et efficaces. CoW Protocol se positionne de manière unique comme infrastructure native de transaction pour les couches de règlement discrètes dans le temps (comme Ethereum), en faisant des enchères groupées un concept clé, offrant ainsi aux utilisateurs des échanges justes et accessibles. Les transactions peuvent être réglées directement via les AMM sous-jacentes ou via des agrégateurs DEX, selon le pool/chemin offrant le meilleur prix. En ce sens, il est essentiellement un « agrégateur d'agrégateurs DEX ». CoW Protocol utilise la « coïncidence des désirs » (CoWs) pour maximiser la liquidité lors des enchères groupées, en exploitant si nécessaire toute la liquidité disponible sur la chaîne. Le protocole exécute continuellement des enchères groupées, car les solveurs — parties chargées de trouver le règlement groupé optimal — rivalisent pour les résoudre.
Aperçu des projets expérimentaux sur les intentions
L'illustration ci-dessous fournit un aperçu non exhaustif des projets expérimentaux sur les intentions. Toutefois, il convient de reconnaître qu'il peut exister des chevauchements entre certaines catégories, et cette présentation est simplifiée. Parmi les exemples typiques d'applications spécifiques aux intentions attirant actuellement beaucoup d'attention figurent 1inch Fusion ou UniswapX. Étant donné que ce domaine est jeune et en rapide évolution, cette illustration pourrait changer considérablement en quelques mois seulement.
Conclusion
Pour les utilisateurs finaux, la méthode actuelle basée sur les Tx dans Web3 s'est révélée complexe et chronophage. Elle implique de spécifier des chemins d'exécution entre diverses infrastructures, entraînant une expérience utilisateur frustrante et une vulnérabilité potentielle à l'exploitation par des participants plus sophistiqués. Les applications basées sur les intentions proposent un changement prometteur, passant d'un paradigme impératif à un paradigme déclaratif, améliorant ainsi l'expérience utilisateur et minimisant le MEV. Bien que l'abstraction des comptes (AA) et les applications spécifiques aux intentions apportent des avancées passionnantes, elles présentent également certaines limites, notamment dans un monde multi-chaînes.
Construire une couche d'intentions pour un monde entièrement centré sur les intentions fait face à d'importants défis, car nous devons surmonter la complexité des systèmes actuels et créer une infrastructure conviviale, efficace et décentralisée pour exprimer et exécuter des intentions. Nous sommes donc encore loin de ce paradigme. Cependant, plusieurs projets travaillent activement dans ce sens, et nous prévoyons qu'un nombre croissant de projets émergera à l'avenir.
À mesure que l'adoption des intentions progresse (soutenue par ERC-4337), les utilisateurs pourraient migrer vers des mempools alternatifs. Une gestion prudente est cruciale pour éviter les risques de centralisation et l'émergence d'intermédiaires rentiers.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@bastian_wetzel
