Présentation d'ERC7683 : la nouvelle norme pour les intentions cross-chain élaborée conjointement par Uniswap et Across
TechFlow SélectionTechFlow Sélection
Présentation d'ERC7683 : la nouvelle norme pour les intentions cross-chain élaborée conjointement par Uniswap et Across
ERC7683 vise à optimiser l'expérience utilisateur des solutions et à réduire les barrières d'entrée au réseau des solutions universelles.
Dédié à des analyses Web3 approfondiesRédaction :Nick Pai，Archetype
Traduction : TechFlow
Cet article se divise en deux parties. Premièrement, j'explique pourquoi je considère que l'infrastructure d'abstraction des chaînes est essentielle à l'adoption grand public des cryptomonnaies, et pourquoi une architecture basée sur les intentions constitue la meilleure manière de la concevoir. Deuxièmement, j'analyse les principaux obstacles à l'adoption généralisée des intentions : l'activité du réseau de solutionneurs.
À la fin de l'article, je propose une solution et présente une norme élaborée par Across et Uniswap suite aux retours du groupe de travail CAKE. Cette norme vise à améliorer l'expérience utilisateur des solutionneurs, à abaisser le seuil d'entrée vers un réseau de solutionneurs universel, à permettre le routage de la majorité des intentions vers ce réseau, et ainsi à favoriser l'émergence d'un écosystème de solutionneurs plus vaste et compétitif.
Agenda
Problématique :
-
Définir l'état final : qu'est-ce qui rend une application crypto « utilisable » ?
-
Pourquoi l’« abstraction des chaînes » constitue-t-elle la réponse aux problèmes d’expérience utilisateur induits par la topologie fondamentale des blockchains modulaires ?
-
Pourquoi les applications crypto utilisables doivent-elles reposer sur une infrastructure d’abstraction des chaînes ?
Espace des solutions :
-
Comment une architecture fondée sur les intentions permet-elle d’atteindre l’abstraction des chaînes ?
-
Comprendre pourquoi les marchés d’intentions fonctionnent au mieux lorsque le réseau de solutionneurs est vaste et concurrentiel
-
Lancer un réseau de solutionneurs d’intentions nécessite d’introduire davantage d’applications générant des intentions
Proposition :
-
Pourquoi avons-nous besoin d’une norme inter-chaînes pour les intentions, priorisant l’« expérience utilisateur du solutionneur », afin d’élargir suffisamment les marchés de solutions et d’intentions pour atteindre un effet de réseau ?
Impossible de construire des applications crypto utilisables sans abstraction des chaînes
Nos meilleurs talents ne seraient-ils pas en train de construire une infrastructure redondante ?
Beaucoup reprochent aux ingénieurs crypto les plus talentueux de trop se concentrer sur la fourniture d’espace bloc supplémentaire aux utilisateurs finaux. Ces critiques sont justifiées : il existe actuellement bien trop de solutions L2 proposées aux utilisateurs par rapport à la demande réelle.
Cependant, je rejette l'idée selon laquelle aucune application crypto utile n'existerait.
La finance décentralisée permet aux individus de conserver eux-mêmes leurs actifs numériques, de contourner des fournisseurs de services contraignants, et d’utiliser ces actifs pour acquérir des biens ayant une valeur dans le monde réel. La promesse de pouvoir conserver soi-même ses données constitue également une alternative utopique pour ceux qui s'inquiètent de plus en plus de confier leurs données à des monopoles comme FAANG (acronyme désignant cinq des entreprises technologiques les plus performantes et populaires du marché américain).
Je pense que le véritable problème n’est pas l’absence d’applications crypto utiles, mais la friction rencontrée par les utilisateurs lorsqu’ils tentent d’y accéder. Les utilisateurs devraient pouvoir expérimenter les éléments suivants lorsqu’ils interagissent avec une application crypto :
-
Vitesse : l’application doit être aussi rapide qu’une application web2
-
Coût : contrairement au web2, chaque interaction web3 a un coût, mais celui-ci par clic devrait être négligeable
-
Résistance à la censure (« permissionless ») : toute personne disposant d’un portefeuille devrait pouvoir interagir avec l’application, dès lors qu’elle peut en supporter les frais
-
Sécurité : chaque clic doit accomplir exactement ce que l’utilisateur attend, sans possibilité de réversibilité ; toutes les mises à jour web3 doivent être permanentes
Tels sont les attributs d'une application crypto « utilisable ».
Nous essayons depuis longtemps déjà de construire des applications crypto utilisables
Les solutions blockchain modulaires actuelles offrent à elles seules tous ces attributs aux consommateurs, mais pas simultanément sur un même lieu.
En 2020, les blockchains étaient monolithiques et ne pouvaient offrir que deux des trois attributs suivants aux utilisateurs : rapidité, faible coût ou sécurité. Nous avons alors imaginé un avenir centré sur les rollups, ou modulaire, capable de débloquer simultanément ces trois attributs.
Aujourd’hui, nous avons jeté les bases de cette infrastructure centrée sur les rollups. Les L2 offrent un espace bloc bon marché et rapide, tandis que la plupart assurent un accès libre à cet espace. En revanche, les L1 offrent un espace bloc sécurisé contre les risques de type WW3 (lire davantage sur les compromis entre sécurité et expérience utilisateur offerts par les L1 et L2 dans mon article). Ces L2 sont reliés en toute sécurité aux L1 via des chemins de messages normalisés, posant ainsi les fondations d’un réseau modulaire et interopérable. Au cours des quatre dernières années, nous avons tissé des connexions fibre entre blockchains capables de supporter des applications crypto utiles. Alors pourquoi les blockchains modulaires restent-elles si peu utilisables ?
L’architecture modulaire des blockchains implique nécessairement que les actifs capitaux s’accumuleront sur la couche la plus sûre, tandis que les interactions utilisateurs se concentreront sur les couches plus rapides et moins coûteuses.
La topologie modulaire pousse à séparer la fourniture d’espace bloc sécurisé de celle d’espace bloc bon marché et rapide. Naturellement, les utilisateurs préféreront conserver leur valeur sur les réseaux les plus sûrs, tout en souhaitant interagir fréquemment avec les réseaux les plus rapides et économiques. Or, par conception, le chemin normalisé entre L2 et L1 est lent et/ou coûteux. C’est là l’explication du fait que les utilisateurs doivent emprunter ces chemins pour payer leurs interactions L2 avec des actifs L1 — ce qui conduit à une expérience utilisateur « inutilisable ».
L’objectif de l’abstraction des chaînes est de réduire la friction liée au transfert de valeur à travers ces protocoles. Les partisans de l’abstraction supposent que les utilisateurs préfèrent indiquer à l’application décentralisée (dApp) l’état final désiré sous forme d’« intention », laissant à l’application la responsabilité de réaliser cette intention. Les utilisateurs ne devraient pas avoir à sacrifier la sécurité de leurs actifs pour bénéficier de frais bas et de faibles latences.
Par conséquent, l’abstraction des chaînes consiste à permettre aux utilisateurs de transférer rapidement, à moindre coût et en toute sécurité de la valeur entre réseaux. Un flux utilisateur courant aujourd’hui consiste en un utilisateur possédant un solde USDC sur une chaîne « sécurisée » (comme Ethereum) et souhaitant frapper un NFT ou échanger un nouveau jeton sur une nouvelle chaîne (comme Blast ou Base). Pour exécuter cela avec un nombre minimal d’étapes, il faut effectuer en série une succession de transactions : pont → échange → frappe (ou échange → pont → frappe).
Dans cet exemple, l’intention de l’utilisateur est d’utiliser son USDC détenu sur la chaîne sécurisée pour frapper un NFT sur une autre chaîne. Tant qu’il obtient bien son NFT et que son solde USDC est débité depuis l’endroit choisi pour le garder, l’utilisateur sera satisfait.
L’architecture fondée sur les intentions est la seule voie viable pour construire l’abstraction des chaînes
L’abstraction des chaînes repose sur le transfert de valeur inter-chaînes, mais envoyer de la valeur via les chemins normalisés est soit coûteux, soit lent. Les « ponts rapides » offrent aux utilisateurs une alternative économique et rapide pour transférer de la valeur entre réseaux, mais introduisent de nouvelles hypothèses de confiance. Le transfert de messages est la méthode la plus intuitive pour construire des ponts rapides, car il s’inspire de l’architecture TCP/IP : il repose sur un protocole de pont agissant comme routeur TCP reliant deux chaînes.
Schéma TCP/IP sur ResearchGate
Le transfert de valeur par message consiste à envoyer un message entre les contrats du protocole de pont sur la chaîne initiale et celle de destination. Ce message est déclenché par une transaction utilisateur sur la chaîne source, puis relayé vers la chaîne cible une fois sa « validité » vérifiée.
Ce message ne peut être validé qu’après que la transaction initiale sur la chaîne source a été finalisée, c’est-à-dire après que la transaction a été intégrée de façon permanente dans la blockchain canonique de la chaîne source. Cette validation peut s’effectuer via une preuve de validité attestant que la transaction a été incluse dans le consensus de la chaîne source, ou selon une proposition optimiste, ou encore après accumulation d’un certain nombre de signatures témoins sur la chaîne source. Une fois le message relayé au contrat de pont sur la chaîne cible, les jetons sont libérés à l’utilisateur.
Cette architecture présente plusieurs problèmes fondamentaux :
-
Le mécanisme de validation doit attendre la pleine finalité avant de relayer le message au contrat de pont sur la chaîne cible. Pour les L2 dotés d’une période de finalité optimiste, cela peut prendre jusqu’à sept jours.
-
Chaque transaction de pont envoie un seul message inter-chaînes, ou regroupe des messages, mais ne peut relayer le lot qu’après la complétion du dernier message inclus.
-
Les ponts ont une capacité limitée à mobiliser des liquidités externes pour offrir un meilleur prix aux utilisateurs, car ils doivent déclarer à l’avance le chemin d’exécution de l’intention.
Les ponts rapides basés sur le transfert de messages seront donc, selon leur mécanisme de validation, soit insécurisés, soit lents, soit coûteux. Le marché des intentions constitue une architecture alternative au pont rapide, découlant d’un constat clé :
La valeur est fongible : pour le destinataire, tant qu’il reçoit les fonds, peu importe comment elle a été transférée
Un pont peut-il externaliser le transfert de valeur vers un agent complexe afin d’améliorer la vitesse et réduire les coûts ? La liquidité varie dynamiquement sur et hors chaîne ; si le mécanisme de pont pouvait choisir de façon flexible le meilleur chemin d’exécution au moment du transfert, des gains de prix seraient possibles.
Le mécanisme d’intention permet à l’utilisateur de spécifier les conditions précises ou le contrat selon lesquelles sa transaction de transfert de valeur peut être exécutée.
L’intention la plus simple consiste en une commande de type : « Payer X jetons sur la chaîne A pour recevoir Y jetons sur la chaîne B ».
Le protocole de pont n’a pas besoin d’envoyer un message entre domaines pour satisfaire l’intention inter-domaines de l’utilisateur. Au contraire, il externalise le transfert de valeur vers un agent sélectionné parmi un réseau de solutionneurs non autorisés, chacun devant ensuite se faire rembourser par le protocole de pont. Contrairement aux mécanismes basés sur les messages, qui précisent exactement comment exécuter la transaction, cette approche repose sur la disponibilité des agents.
Protocole de règlement des intentions
Les protocoles de pont basés sur les intentions peuvent être nommés plus précisément « protocoles de règlement des intentions ». Ils garantissent que les solutionneurs respectent les conditions spécifiées par l’utilisateur. Ces protocoles assurent aux solutionneurs un remboursement et une récompense en cas de bonne exécution. Pour cela, ils doivent recourir à des oracles pour vérifier l’authenticité de l’exécution. La sécurité de l’oracle peut reposer sur une période de défi optimiste, un seuil de témoins, ou des preuves de validité ZK.
Étant donné qu’un solutionneur unique peut assumer le risque de finalité et déterminer le meilleur chemin d’exécution, les protocoles de règlement des intentions permettent des transferts de valeur rapides et peu coûteux
Les ponts basés sur les messages ne peuvent communiquer qu’une fois la finalité atteinte sur la chaîne source. Actuellement, la finalité prend sept jours sur les Rollups optimistes et une heure sur les Rollups ZK. Même si ces délais devraient diminuer grâce à l’adoption généralisée des clients légers ZK et aux progrès des pré-confirmations via des ordonnanceurs partagés, il est peu probable que la finalité devienne instantanée pour tous les blockchains — ce qui maintient le besoin de solutions de pont rapide. Sans assumer le risque de finalité, aucun pont ne pourrait accélérer le relais au-delà de la période de finalité, même en ajoutant un agent de confiance intermédiaire pour couvrir les pertes dues à une réorganisation de chaîne.
L’accélération offerte par l’architecture basée sur les intentions provient du fait qu’un solutionneur individuel, au sein d’un réseau hétérogène, peut assumer davantage de risque de finalité que les protocoles de message, et satisfaire l’intention de l’utilisateur avant que le risque de réorganisation disparaisse totalement. Le solutionneur facturera ensuite à l’utilisateur une prime correspondant au risque de finalité pris pour gagner du temps.
Externaliser l’exécution inter-chaînes des intentions vers des agents améliore également en moyenne le prix pour l’utilisateur. Dans un pont basé sur les intentions, le solutionneur frontalier est remboursé par le système après vérification de son exécution. Ces règlements d’intentions peuvent être regroupés pour mutualiser les coûts. Contrairement aux utilisateurs, les remplisseurs (fillers) n’exigent pas de remboursement immédiat et factureront donc une prime pour avancer les fonds. Le règlement groupé n’est pas exclusif à l’architecture fondée sur les intentions, mais celle-ci s’y prête particulièrement bien, car elle sépare l’étape de remboursement de celle d’exécution de l’intention.
Une source plus importante d’amélioration des prix vient de l’intuition suivante : la valeur étant fongible, trouver rapidement le meilleur chemin d’exécution est souvent supérieur au transfert lui-même. Toutefois, certains chemins ne peuvent pas être battus en coût, comme le transfert d’USDC via CCTP.
Les ponts basés sur les messages doivent coder la manière dont ils transmettront la valeur à l’utilisateur. Certains choisissent d’envoyer des jetons depuis un pool de liquidité à un taux de change fixe, tandis que d’autres créent des jetons représentatifs destinés à des destinataires qui devront ensuite échanger ces actifs représentatifs contre les actifs canoniques requis.
Lors de l’exécution d’une intention utilisateur, un agent peut combiner des liquidités provenant de multiples sources, on-chain et off-chain. Un réseau concurrentiel de solutionneurs théoriquement illimité offre aux utilisateurs une infinité de sources de liquidité (bien que celles-ci puissent malgré tout s’épuiser rapidement lors d’événements chaotiques à forte volatilité, comme la frappe massive d’un NFT tendance, un airdrop ou un rug pull).
Après soumission d’une commande inter-chaînes comme intention, les solutionneurs peuvent internaliser la MEV générée par cette commande pour améliorer le prix offert.
L’architecture fondée sur les intentions est intrinsèquement conçue pour être sécurisée
Les ponts basés sur les intentions peuvent être construits de façon sécurisée car ils séparent les besoins urgents de l’utilisateur des exigences complexes du réseau de règlement. Les solutionneurs peuvent attendre d’être remboursés, contrairement aux utilisateurs, et factureront donc aux utilisateurs en fonction du délai de remboursement imposé par le protocole de règlement. Ainsi, le règlement des intentions peut utiliser des mécanismes de vérification très robustes, sans contrainte temporelle stricte. D’un point de vue sécurité, c’est préférable, car la vérification de l’exécution d’une intention est par nature complexe.
À titre d’exemple de vérification d’intention en production, Across valide et rembourse les remplisseurs par lots, après une période de défi optimiste de 90 minutes. Bien sûr, les réseaux de règlement doivent viser un remboursement aussi rapide que possible pour réduire les frais supportés par les utilisateurs finaux. Une amélioration du mécanisme de défi optimiste serait un mécanisme de preuve de validité ZK, qui nécessiterait d’encoder la logique de vérification des intentions dans un circuit ZK. À mon avis, l’évolution vers des mécanismes de preuve de vérification, qui remplaceront progressivement les défis optimistes, est inévitable et permettra aux réseaux de règlement d’intentions de rembourser plus vite.
Alors, comment l’abstraction des chaînes émerge-t-elle de l’architecture fondée sur les intentions ?
Rappelons que l’abstraction des chaînes requiert un transfert de valeur inter-chaînes rapide et peu coûteux, sans obliger l’utilisateur à soumettre une transaction on-chain sur le réseau où ses actifs sont stockés.
Si l’intention inclut une signature Permit2 ou EIP 3074, elle n’a pas besoin d’être soumise on-chain par l’utilisateur. Cela est vrai aussi bien pour les ponts basés sur les messages que pour ceux fondés sur les intentions. Ces deux architectures peuvent exploiter le modèle Permit2, permettant à l’utilisateur de signer hors ligne, depuis son portefeuille sur la chaîne source, le montant de jetons qu’il accepte de payer.
Les marchés d’intentions soutiennent le mieux l’abstraction des chaînes, car ils permettent des transferts de valeur inter-chaînes rapides et économiques. Imaginons qu’un utilisateur puisse demander à un solutionneur de lui proposer un devis pour utiliser son USDC sur Optimism afin d’entrer dans une position collatérale en WETH sur Arbitrum. L’utilisateur pourrait envoyer cette intention à une enchère RFQ (Request for Quote), à laquelle les solutionneurs répondraient. Le gagnant recevrait alors l’intention signée par l’utilisateur, incluant une autorisation de dépenser son USDC sur Optimism, le montant de WETH à obtenir sur Arbitrum, ainsi que les calldata nécessaires pour déposer ce WETH dans la position collatérale sur Arbitrum. Le solutionneur pourrait alors soumettre cette transaction sur Optimism (au nom de l’utilisateur) pour lancer l’intention inter-chaînes et retirer l’USDC du portefeuille de l’utilisateur sur Optimism. Enfin, le solutionneur comblerait l’intention en envoyant le WETH à l’utilisateur et en relayant les calldata vers sa position collatérale sur Arbitrum.
Construire une infrastructure d’abstraction des chaînes signifie rendre le parcours utilisateur immédiat et peu coûteux, sans qu’il doive soumettre de transaction on-chain. Abordons maintenant les obstacles à l’adoption plus large des intentions pour conclure cet article.
Pour obtenir la meilleure expérience utilisateur avec l’abstraction des chaînes basée sur les intentions, nous avons besoin d’un réseau de solutionneurs compétitif
La clé d’une excellente expérience utilisateur avec l’abstraction des chaînes fondée sur les intentions réside dans la création d’un réseau de solutionneurs concurrentiel. Les ponts reliant les intentions dépendent de l’effet de réseau des solutionneurs pour surpasser les variantes basées sur les messages. Voilà le compromis central entre intentions et architecture basée sur les messages. La réalité est que toutes les applications générant des intentions n’ont pas nécessairement besoin d’accéder à un ensemble entièrement concurrentiel de solutionneurs, et certaines préféreront peut-être router leurs intentions vers un réseau oligopolistique. Toutefois, l’état actuel des réseaux de solutionneurs reste immature, loin d’atteindre le niveau d’activité requis pour que les marchés d’intentions fonctionnent comme prévu.
Nous ne voulons pas que chaque dApp route ses intentions vers un réseau isolé de solutionneurs. Le scénario optimal est que de nombreuses dApps communiquent avec le même pool de solutionneurs, et que toutes aient la liberté de changer de pool à tout moment.
Comment amorcer un réseau de solutionneurs ?
Nous devons faire de l’expérience utilisateur du solutionneur notre priorité absolue.
Exécuter un solutionneur d’intentions est complexe et nécess
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
@archetypevc
