Ordre du jour

Le Problème

1. Définir l'état final: ce qui rend les applications de crypto "utilisables"

2. Pourquoi "l'abstraction de chaîne" est une solution à un problème d'UX qui découle de la topologie fondamentale des blockchains modulaires

3. Pourquoi les applications crypto utilisables doivent être construites sur une infrastructure d'abstraction de chaîne

L'espace de solution

1. Comment l'architecture basée sur l'intention donnera naissance à une abstraction de chaîne

2. Comprendre que les places de marché d’intention sont plus performantes lorsque le réseau de solveurs est vaste et compétitif

3. Le démarrage du réseau du solveur d'intention nécessite d'embarquer plus d'applications qui produiront des intentions

La proposition

1. Pourquoi avons-nous besoin d'une norme d'intentions inter-chaînes qui priorise l'« expérience utilisateur du solveur » pour faire croître le marché des solveurs et des intentions à une échelle suffisamment grande pour atteindre des effets de réseau

Les applications cryptographiques utilisables ne peuvent pas être construites sans abstraction de chaîne

Nos bâtiments les plus performants et les plus brillants sont-ils redondants ?

Beaucoup se sont plaints du fait que les meilleurs ingénieurs en cryptographie et les penseurs les plus basés allouent trop d’attention et d’énergie pour offrir plus d’espace de bloc aux utilisateurs finaux. Cette critique est fondée ; il y a trop de L2 disponibles pour les utilisateurs finaux par rapport à la demande.

Cependant, je rejette l'idée qu'il n'y a pas d'applications crypto utiles en existence.

La finance décentralisée offre aux individus la possibilité de s'auto-garder des actifs numériques, leur permettant de contourner les fournisseurs de services draconiens et d'utiliser leurs actifs numériques pour acheter des biens valorisés dans le monde réel. La promesse de données auto-gardées offre également une alternative utopique pour les individus de plus en plus méfiants à l'égard des monopoles des GAFA pour sécuriser leurs données.

Le vrai problème à mon avis n'est pas le manque d'applications crypto utiles mais la friction pour les utilisateurs finaux qui essaient d'y accéder. Les utilisateurs finaux devraient pouvoir vivre ce qui suit lorsqu'ils interagissent avec des applications crypto :

1. Vitesse : les applications doivent être aussi rapides que les applications web2.
2. Coût : Contrairement à web2, toutes les interactions web3 doivent entraîner un certain coût, mais le "coût par clic" devrait être négligeable.
3. Résistance à la censure (« non autorisation ») : Toute personne possédant un portefeuille devrait pouvoir interagir avec l'application si elle peut se permettre de cliquer.
4. Sécurité : Les clics doivent faire ce que les utilisateurs s'attendent à ce qu'ils fassent et ne doivent pas être annulés. Toutes les mises à jour web3 doivent être permanentes.

Ce sont les propriétés des applications crypto "utilisables".

Nous essayons de construire une crypto utilisable depuis longtemps

Les solutions modulaires de blockchain d’aujourd’hui offrent aux consommateurs toutes ces propriétés, mais elles ne sont pas toutes disponibles au même endroit.

En 2020, les blockchains étaient monolithiques, offrant deux des trois propriétés aux utilisateurs finaux : vitesse, coût ou sécurité. Nous avons alors imaginé un avenir centré sur le rollup ou modulairequi débloquerait simultanément les trois propriétés.

Aujourd'hui, nous avons posé les bases de cette infrastructure centrée sur le rollup. Les L2 offrent un espace de bloc bon marché et rapide, et la plupart d'entre eux offrent un espace de bloc sans permission. En revanche, L1 offre un espace de bloc sécurisé et résistant à la WW3. (Vous pouvez en savoir plus sur le compromis sécurité-UX offert par les L1 et les L2 dans mon court article de sondage). Ces L2 se connectent de manière sécurisée à L1 via des chemins de messages canoniques, posant les bases d'un réseau modulaire mais interopérable. Au cours des quatre dernières années, nous avons construit la fibre optique entre les blockchains qui soutiendront un jour des applications crypto utiles. Mais pourquoi les blockchains modulaires sont-elles si peu utilisables?

L'inévitabilité des réseaux blockchain modulaires est que les actifs en capital s'accumuleront aux couches les plus sécurisées tandis que les clics des utilisateurs s'accumuleront aux couches plus rapides et moins chères.

La topologie modulaire de la blockchain encourage à offrir un espace de bloc sécurisé sur une couche différente de l'espace de bloc bon marché et rapide. Les utilisateurs préféreront naturellement stocker leur valeur sur les réseaux les plus sécurisés, mais ils exigeront d'interagir le plus fréquemment avec les réseaux bon marché et rapides.Par conception, les chemins canoniques entre les L2 et les L1 sont lents et/ou coûteux. Ces phénomènes expliquent pourquoi les utilisateurs doivent emprunter ces voies canoniques pour payer les interactions L2 en utilisant des actifs L1. Cela se traduit par une UX crypto «inutilisable».

Vitalik sur les différents types de L2s

L'objectif de l'abstraction de la chaîne est de réduire la friction de l'envoi de la valeur le long de ces chemins en protocole, loin de l'utilisateur.Chain abstractorssupposer que les utilisateurs préfèrent spécifier leur état final souhaité aux dapps sous forme d'"intentions" et qu'il incombe aux dapps de remplir leurs intentions. Les utilisateurs ne devraient pas avoir à compromettre la garde sécurisée de leurs actifs pour accéder à des frais réduits et à une latence réduite.

Donc abstraction de chaînedépend de manière critique de la capacité des utilisateurs à transférer de la valeur entre les réseaux de manière sécurisée, peu coûteuse et rapide. Un flux utilisateur courant aujourd'hui est qu'un utilisateur disposant d'un solde en USDC sur une chaîne 'sécurisée' comme Ethereum souhaite créer un NFT ou échanger de nouveaux jetons sur une chaîne plus récente comme Blast ou Base. La manière de le faire en aussi peu d'étapes que possible est d'exécuter séquentiellement une série de transactions Pont→Échange→Mint (ou Échange→Pont→Mint).

Dans cet exemple, l'intention de l'utilisateur est d'utiliser son USDC sur la chaîne sécurisée pour créer un NFT sur une autre chaîne. L'utilisateur sera satisfait tant qu'il recevra le NFT et que son solde USDC sera débité où qu'il choisisse de le conserver.

L'architecture basée sur l'intention est le seul moyen de construire une abstraction de chaîne

L'abstraction de chaîne repose sur le transfert de valeur entre chaînes, mais l'envoi de valeur via des chemins de messagerie canoniques est soit coûteux, soit lent. Les “ponts rapides” offrent des alternatives bon marché et rapides pour que les utilisateurs envoient de la valeur à travers les réseaux, mais ils introduisent de nouvelles hypothèses de confiance. Le passage de messages est la manière la plus intuitive de construire un pont rapide car il est basé sur l'architecture TCP/IP; il repose sur un protocole de pont agissant comme le routeur TCP pour connecter deux chaînes.

Diagramme TCP/IP de ResearchGate

Le transfert de valeur via le passage de messages implique que le protocole de passerelle envoie des messages entre ses contrats sur les chaînes d'origine et de destination. Ce message est déclenché du côté de l'origine par une transaction utilisateur et relayé du côté de la destination une fois que la "validité" du message est vérifiée.

Un message ne peut être vérifié qu'après que la transaction de chaîne d'origine initiant le message a été finalisée, ce qui signifie que la transaction est définitivement incluse dans la blockchain canonique de la chaîne d'origine. Cette vérification peut être effectuée en tant que preuve de validité prouvant l'inclusion du consensus de la transaction sur la chaîne d'origine, en tant que proposition optimiste, ou après qu'un seuil de signatures de témoins attestant de son inclusion a été accumulé du côté d'origine. Une fois que le message est relayé au contrat de pont sur la chaîne de destination, des jetons sont libérés à l'utilisateur.

Il existe plusieurs problèmes fondamentaux avec cette architecture :

1. Le mécanisme de vérification doit attendre la pleine finalité avant d'envoyer le message au contrat protocole de la chaîne de destination. Cela peut prendre jusqu'à sept jours pour les L2 avec des périodes de finalité optimistes.
2. Un message de chaîne croisée est envoyé par transaction de pont OU les messages sont regroupés, mais le lot ne peut être envoyé qu'après que le dernier message du lot soit finalisé.
3. Le pont a une capacité limitée à sourcer de la liquidité externe pour offrir des améliorations de prix à l'utilisateur car il doit être déclaratif sur le chemin d'accomplissement de l'intention de l'utilisateur.

Les ponts rapides de transmission de messages vont être soit peu sûrs, lents ou coûteux en fonction du mécanisme de vérification. Les places de marché d'intention sont une architecture alternative pour des ponts rapides qui découlent d'une idée clé :

La valeur est fongible et il ne devrait pas importer au destinataire comment la valeur est transférée tant qu'il reçoit les fonds

Un pont peut-il externaliser le transfert de valeur à un agent sophistiqué pour gagner en rapidité et réduire les coûts? La liquidité est dynamique sur et hors chaîne et l'amélioration des prix peut être réalisée si le mécanisme du pont a la flexibilité de choisir un chemin d'exécution optimal au moment du transfert du pont.

Les mécanismes d'intention permettent aux utilisateurs de spécifier des conditions ou des conventions précises en vertu desquelles leur transaction de transfert de valeur peut être exécutée.

Un intent minimal viable est un ordre de payer X jeton de la chaîne A pour recevoir le jeton Y sur la chaîne B.

Le protocole Gate n'a pas besoin d'envoyer un message entre les domaines par transaction de pont pour satisfaire l'intention de l'utilisateur de passer d'un domaine à l'autre. Au lieu de cela, le protocole externalise le transfert de valeur à un agent tiré d'un réseau de solveurs sans permission, et le solveur individuel demandera plus tard un remboursement au protocole Gate. En comparaison, les mécanismes de passage de messages spécifient exactement comment leurs transactions doivent être exécutées et n'ont pas besoin de compter sur la disponibilité d'un agent.

Protocoles de règlement d'intention

Les protocoles de pont basés sur l'intention peuvent être étiquetés de manière plus précise comme des protocoles de règlement d'intention qui sont responsables de s'assurer que les solveurs ne violent pas les conditions spécifiées par l'utilisateur. Les protocoles de règlement d'intention offrent aux solveurs la sécurité qu'ils seront remboursés et récompensés pour avoir rempli les intentions de l'utilisateur. Pour ce faire, les protocoles de règlement d'intention doivent faire appel à un oracle pour vérifier l'authenticité de l'accomplissement de l'intention. La sécurité de l'oracle peut reposer sur une période de défi optimiste, un seuil de témoin, ou être basée sur une preuve de validité ZK, par exemple.

Les protocoles de règlement d'intention offrent un transfert de valeur rapide et peu coûteux car les solveurs individuels peuvent prendre en charge le risque de finalité et identifier les chemins d'exécution optimaux

Les ponts de transmission de messages ne peuvent communiquer qu’aussi rapidement que la finalité est atteinte par la chaîne d’origine. Les délais de finalité sont de sept jours sur les cumuls optimistes et d’une heure sur les cumuls ZK aujourd’hui. Même si ces délais de finalité devraient avoir tendance à diminuer à la suite de l’adoption plus large de la technologie des clients légers ZK et des progrès de la technologie de pré-confirmation de séquençage partagé, il est peu probable que les temps de finalité de toutes les blockchains soient un jour « instantanés » pour les utilisateurs, ce qui suggère un besoin persistant de solutions de transition rapides. Il est impossible de relayer un message plus rapidement que la période de finalité sans assumer le risque de finalité, qui est en dehors du champ d’application d’un pont de transmission de message, à moins que le pont ne veuille ajouter un agent de confiance supplémentaire au chemin de relais qui garantira les pertes dues aux réorganisations de la chaîne.

L'accélération offerte par l'architecture basée sur l'intention provient du fait que les solveurs individuels au sein d'un réseau de solveurs hétérogènes peuvent assumer plus de risque de finalité qu'un protocole de passage de messages et remplir l'intention d'un utilisateur avant que le risque de réorganisation de la chaîne ne disparaisse complètement. Les solveurs factureront ensuite aux utilisateurs ce risque de finalité qu'ils assument en échange de temps de remplissage plus rapides.

Externaliser l'accomplissement de l'intention de chaîne croisée à un agent conduit également à une amélioration des prix en moyenne pour les utilisateurs. Dans les ponts basés sur l'intention, les solveurs qui prennent en charge les ordres des utilisateurs sur la chaîne de destination souhaitée sont remboursés ultérieurement par le système après la validation de leur réalisation. Ces règlements d'intention peuvent être regroupés pour amortir les coûts. Contrairement aux utilisateurs, les remplisseurs ne demandent pas de remboursement immédiat et factureront en conséquence les utilisateurs pour leur avance en capital. Le règlement par lot n'est pas propre à l'architecture basée sur l'intention, mais l'architecture est plus synergique avec le règlement par lot car elle sépare l'étape de remboursement de l'étape d'accomplissement de l'intention.

La plus grande source d'amélioration des prix provient de l'intuition selon laquelle la valeur est fongible, et trouver le meilleur chemin juste à temps surpassera généralement le transfert de valeur. (Cependant, certains chemins seront impossibles à battre en termes de coût juste à temps, comme lors du pontage de l'USDC sur le CCTP.)

Les passerelles de transfert de messages doivent coder la manière dont elles transféreront de la valeur à l'utilisateur. Certains choisissent d'envoyer des jetons hors d'un pool de liquidité à un taux de change prédéterminé, tandis que d'autres émettent des jetons représentatifs aux destinataires qui doivent ensuite les échanger contre l'actif de jeton canonique souhaité.

Lorsqu’il répond à l’intention d’un utilisateur, un agent peut s’approvisionner en liquidités à partir d’une combinaison de sites de liquidité onchain et offchain. Les réseaux de solveurs compétitifs offrent aux utilisateurs des sources de liquidité illimitées en théorie (mais même ces sources de liquidité peuvent être épuisées rapidement lorsque le volume évolue dans une direction lors d’événements onchain à forte volatilité tels que les mints NFT, les airdrops et les rug pulls populaires).

Soumettre un ordre inter-chaînes en tant qu'intention permet aux solveurs d'intérioriser le MEV généré de l'ordre comme amélioration de prix.

L'architecture basée sur l'intention est fondamentalement conçue pour être sécurisée

Les ponts basés sur l'intention peuvent être construits en toute sécurité car ils séparent les demandes urgentes de l'utilisateur des demandes complexes du réseau de règlement. Les solveurs peuvent attendre le remboursement, contrairement aux utilisateurs, et ils factureront aux utilisateurs le montant de temps que le protocole de règlement les oblige à attendre le remboursement. Par conséquent, les règlements d'intention peuvent être validés à l'aide de mécanismes très robustes sans contrainte de temps stricte. Cela est préférable d'un point de vue sécurité car vérifier l'accomplissement d'une intention est intuitivement complexe.

Comme exemple de vérification d'intention en production, À traversvalide 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 devraient s'efforcer de rembourser les remplisseurs aussi rapidement que possible pour réduire les frais des 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 validation de l'intention dans un circuit ZK. À mon avis, il est inévitable que les mécanismes de preuve de validité remplaceront les mécanismes de défi optimiste et permettront aux réseaux de règlement d'intention de rembourser les utilisateurs plus rapidement.

Alors, comment l'abstraction de la chaîne émerge-t-elle de l'architecture basée sur l'intention ?

Rappelez-vous que l'abstraction de chaîne nécessite un transfert de valeur inter-chaîne rapide et bon marché. Il ne devrait pas non plus exiger de l'utilisateur de soumettre une transaction on-chain sur le réseau où leurs actifs sont stockés.

L'intention d'un utilisateur n'a pas besoin d'être soumise onchain par l'utilisateur si elle inclut un Permis2ouEIP3074signature. Cela est vrai pour les ponts basés sur les messages et les ponts basés sur l'intention. Les deux architectures peuvent tirer parti du schéma Permit2 pour permettre à l'utilisateur de signer hors chaîne le montant de jetons qu'il est prêt à payer depuis son portefeuille de chaîne d'origine.

Les places de marché d'intention soutiennent le mieux l'abstraction de la chaîne car elles offrent un transfert de valeur inter-chaînes bon marché et rapide. Imaginez un monde où un utilisateur pourrait demander à un solveur de lui fournir un devis pour entrer dans une position de mise en jeu WETH sur Arbitrum, en utilisant leur USDC sur Optimism comme paiement. L'utilisateur pourrait envoyer cette intention hors chaîne à une enchère RFQ où les solveurs pourraient enchérir. Le solveur gagnant de l'enchère pourrait alors recevoir l'intention signée de l'utilisateur, contenant une autorisation pour dépenser leur USDC sur Optimism, le montant désiré de WETH à recevoir sur Arbitrum et les données d'appel nécessaires pour déposer ce WETH dans une position de mise en jeu sur Arbitrum. Le solveur pourrait ensuite soumettre cette transaction sur Optimism (au nom de l'utilisateur) pour initier l'intention inter-chaînes et retirer des USDC du portefeuille Optimism de l'utilisateur. Enfin, le solveur pourrait remplir l'intention de l'utilisateur sur Arbitrum en lui envoyant du WETH et en transmettant les données d'appel pour entrer l'utilisateur dans la position de mise en jeu sur chaîne.

La construction d'une infrastructure d'abstraction de chaîne signifie rendre ce flux d'utilisateurs instantané et bon marché sans les obliger à soumettre une transaction onchain. Concluons cet article en discutant des obstacles à une adoption plus large des intentions.

Architecture d'intention par Across

Pour que l'expérience utilisateur la meilleure possible se matérialise à partir de l'abstraction de chaîne basée sur l'intention, nous avons besoin d'un réseau compétitif de solveurs

La création de ponts avec des intentions dépend des effets de réseau du solveur pour mieux fonctionner que les variantes de transmission de messages. C'est le compromis fondamental des architectures basées sur l'intention par rapport à la transmission de messages. En réalité, toutes les applications produisant des intentions n'auront pas besoin d'avoir accès à un ensemble de solveurs parfaitement compétitif, et certaines pourraient préférer router leurs intentions vers réseaux de solveurs oligopolistiques. Cependant, l'état actuel des réseaux de solveurs est immatureet n'est pas proche de remplir les hypothèses de vivacité du réseau du solveur sur lesquelles dépendent les marchés.

Nous ne voulons pas d'un monde où chaque dapp achemine des intentions vers des réseaux de résolution isolés. Le meilleur scénario pour l'UX est que de nombreuses dapps communiquent avec les mêmes pools de résolution, et que toutes les dapps aient la liberté de changer vers quels pools de résolution elles envoient leurs intentions.

Comment démarrons-nous le réseau du solveur ?

Nous devons donner la priorité à l'expérience utilisateur du solveur.

L’exécution d’un solveur d’intention est compliquée et nécessite une expertise dans la création de logiciels hautement performants ainsi que dans la gestion des risques d’inventaire inter-chaînes. Naturellement, il y aura un nombre limité de parties intéressées à payer le coût de démarrage pour exécuter ce code. Dans le meilleur des cas, un solveur écrit pour une dapp, comme un solveur UniswapX, peut être réutilisé pour résoudre d’autres dapps productrices d’intention comme Across et CowSwap.

Nous devons vraiment augmenter l'efficacité en capital agrégé du réseau de solveurs pour toutes les dapps basées sur l'intention. Cela nécessitera de s'attaquer aux obstacles à l'exécution d'un solveur.

Pour cela, nous aurons besoin que les dapps produisant des intentions soient visibles par tout solveur et nous assurer que tous les solveurs aient accès à de nombreux réseaux de règlement d'intentions différenciés et compétitifs. Cela donnerait confiance aux solveurs qu'ils pourraient choisir de router leurs réalisations d'intentions vers un réseau de règlement en lequel ils ont confiance. La concurrence entre les réseaux de règlement abaisserait également les coûts pour les solveurs.

La proposition de valeur des réseaux de règlement d'intention est d'offrir une sécurité aux solveurs ainsi que d'autres fonctionnalités qui affecteraient la capacité du solveur à remplir une intention.

Le choix du réseau de règlement d'intention du solveur affectera sa capacité à offrir des frais et des garanties de délai d'exécution aux utilisateurs. Certains réseaux de règlement peuvent offrir des périodes d'exclusivité du solveur, ce qui soutiendrait le développement d'enchères hors chaîne où les solveurs et les utilisateurs pourraient négocier et s'engager à des frais de relais. (Ces enchères d'intention pourraient en outre offrir des pré-confirmations économiquement garanties, améliorant ainsi l'expérience utilisateur. Pour en savoir plus sur un flux utilisateur présentant la découverte de l'intention via des enchères et des pré-confirmations, je recommande ceci discours de Karthik de Sorella.)

Certains réseaux de règlement peuvent offrir une expiration d'intention (c'est-à-dire renvoyer la valeur aux utilisateurs après le dépassement d'une date limite de réalisation), un soutien en arrière-plan de l'intention (c'est-à-dire que le réseau de règlement utilise son propre bilan pour réaliser l'intention d'un utilisateur si aucun résolveur ne le fait), ou une chaîne de remboursement flexible (c'est-à-dire permettre au résolveur d'être remboursé sur sa chaîne de choix).

En fin de compte, les réseaux de règlement vont rivaliser férocement pour rembourser rapidement et à moindre coût les solveurs sans compromettre la sécurité. À leur tour, les solveurs enverront leur flux de commandes aux réseaux de règlement qui leur permettent d'offrir les frais les moins chers aux utilisateurs afin qu'ils puissent remporter le flux de commandes d'applications. La concurrence dans les réseaux de règlement et de solveurs dépend de toutes les parties de la chaîne d'approvisionnement ayant l'intention de coordonner pour parler le même langage, et la concurrence aboutira à la meilleure expérience utilisateur pour le transfert de valeur entre chaînes.

Il est clair que nous avons besoin d'une norme pour les intentions de chaîne croisée

Si les solveurs peuvent supposer que les intentions partageront des éléments communs, alors ils peuvent réutiliser leur code pour résoudre les intentions provenant de différents dapps et réduire ainsi leurs coûts de configuration. Si différents dapps créent des intentions conformes à la même norme, ils peuvent tous router leurs intentions vers les mêmes pools de solveurs. Cela aiderait à intégrer la prochaine génération de dapps en leur donnant la possibilité de brancher directement leurs intentions inter-chaînes dans un pool de solveurs existant et mature. Les nouveaux dapps n'auraient pas à intégrer individuellement les solveurs et auraient accès à des transferts de valeur bon marché, rapides, sécurisés et sans autorisation.

Les logiciels de suivi tiers seraient également plus facilement en mesure de suivre les statuts d'intention pour toute nouvelle dapp si elles respectent une norme.

Ce standard d'intention devrait permettre au principal d'intention ou au solveur de spécifier le réseau de règlement sur lequel ils souhaitent régler leur intention.

Je prévois que des protocoles de règlement concurrents comme SUAVE, Across, Anoma et Khalani offriront des fonctionnalités différenciées aux solveurs d'intention. En fonction du réseau de règlement qui rembourse le solveur, celui-ci peut offrir des garanties de prix et de délais différentes au propriétaire de l'intention. Le dapp et le solveur pourraient convenir de router l'intention d'un utilisateur vers un réseau de règlement en lequel ils ont confiance pour éviter la censure, préserver la confidentialité des données, et être suffisamment sécurisés pour être dignes de confiance pour rembourser le solveur.

En consacrant le choix du réseau de règlement dans l'ordre d'intention lui-même, le solveur pourrait intégrer cette certitude dans le devis qu'il montrerait à l'utilisateur. Le solveur et l'utilisateur élimineraient l'incertitude initiale sur la tarification du pont avant de soumettre l'intention onchain, réduisant les coûts.

En collaboration avec Uniswap et sur la base des retours d’expérience du groupe de travail CAKE, Across et moi-même proposons la norme d’intention cross-chain suivante hiérarchisant l’UX du solveur :

///@title Type CrossChainOrder

/// @noticeStructure standard de commande à signer par les swappers, à diffuser aux fillers et à soumettre aux contrats de règlement

struct CrossChainOrder {

/// @dev L'adresse du contrat par lequel l'ordre est censé être réglé. Les Fillers envoient cet ordre à cette adresse de contrat sur la chaîne d'origine adresse settlementContract;/// @dev L'adresse de l'utilisateur qui lance l'échange, dont les jetons d'entrée seront pris et mis en garantie adresse swapper;/// @dev Nombre aléatoire à utiliser comme protection contre la répétition de l'ordreuint256 nonce;/// @dev L'identifiant de la chaîne d'origineuint32 originChainId;/// @dev Le timestamp à partir duquel l'ordre doit être initiéuint32 initiateDeadline;/// @dev Le timestamp à partir duquel l'ordre doit être exécuté sur la chaîne de destinationuint32 fillDeadline;/// @dev Données spécifiques à l'implémentation arbitraire/// Peut être utilisé pour définir des jetons, des montants, des chaînes de destination, des frais, des paramètres de règlement,/// ou toute autre information spécifique à un type d'ordre particulierbytes orderData;

}

Cette norme est conçue pour faciliter le travail d’un solveur. Un choix opiniâtre qu’il fait est de prendre en charge Permit2/EIP3074 nativement avec le nonce et initiateDeadline et il donne aux remplisseurs certaines garanties, telles que le montant qu’ils seront remboursés par le réseau de règlement et le format de l’intention de l’utilisateur qu’ils peuvent suivre. De plus, une fonction d’initiation est définie dans le standard qui permet de manière cruciale au remplisseur, celui qui apportera la commande sur la chaîne, de spécifier des « fillerData » supplémentaires sur la chaîne que l’utilisateur n’aurait pas connus au moment où il a signé le CrossChainOrder. Cela permet au remplisseur de s’assurer qu’il est récompensé par le contrat de règlement pour avoir soumis la méta-transaction de l’utilisateur et de définir des informations spécifiques au remboursement, telles que la chaîne de remboursement.

Cette norme est également conçue pour faciliter le suivi par les dapps de l'état d'accomplissement de l'intention tout au long de son cycle de vie. Tout contrat de règlement mettant en œuvre cette norme devrait créer un sous-type personnalisé ResolvedCrossChainOrder qui peut être analysé à partir du champ orderData arbitraire. Cela peut inclure des informations telles que les jetons impliqués dans l'échange, la ou les chaînes de destination, et d'autres contraintes d'accomplissement. Une fonction de résolution est incluse dans la norme pour permettre aux dapps de comprendre comment afficher les états d'intention aux utilisateurs et aux resolveurs de connaître la structure exacte de l'ordre d'intention avec lequel ils travaillent.

///@titleType de commande ResolvedCrossChain

/// @noticeUne représentation générique de mise en œuvre d'une commande

/// @devDéfinit toutes les exigences pour remplir une commande en dégroupant les données de commande spécifiques à la mise en œuvre.

///@devDestiné à améliorer la généralisation de l'intégration en permettant aux compléments de calculer les informations d'entrée et de sortie exactes de n'importe quel ordre

struct ResolvedCrossChainOrder {

/// @dev L'adresse du contrat selon laquelle l'ordre doit être réglé.address settlementContract;/// @dev L'adresse de l'utilisateur qui lance l'échangeaddress swapper;/// @dev Nombre aléatoire à utiliser comme protection contre la relecture pour l'ordreuint256 nonce;/// @dev L'identifiant de chaîne de la chaîne d'origineuint32 originChainId;/// @dev L'horodatage auquel l'ordre doit être initiéuint32 initiateDeadline;/// @dev L'horodatage auquel l'ordre doit être rempli sur la(les) chaîne(s) de destinationuint32 fillDeadline;/// @dev Les entrées à prendre du swapper dans le cadre de l'initiation de l'ordreInput[] swapperInputs;/// @dev Les sorties à donner au swapper dans le cadre de l'exécution de l'ordreOutput[] swapperOutputs;/// @dev Les sorties à donner au remplisseur dans le cadre du règlement de l'ordreOutput[] fillerOutputs;

}

///@noticeJetons envoyés par le swapper en tant qu'entrées à l'ordre

struct Input {

/// @dev L'adresse du jeton ERC20 sur la chaîne d'origineaddress jeton;/// @dev Le montant du jeton à envoyeruint256 montant;

///@noticeJetons qui doivent être reçus pour un traitement de commande valide

struct Output {

/// @dev L'adresse du jeton ERC20 sur la chaîne de destination/// @dev L'adresse(0) utilisée comme sentinelle pour le jeton natifadresse jeton;/// @dev Le montant du jeton à envoyeruint256 montant;/// @dev L'adresse pour recevoir les jetons de sortieadresse bénéficiaire;/// @dev La chaîne de destination de cette sortieuint32 chainId;

Une implémentation de contrat de règlement conforme DOIT implémenter l'interface ISettlementContract :

///@titleISettlementContract

/// @noticeInterface standard pour les contrats de règlement

interface ISettlementContract {

/// @notice Initie le règlement d'un ordre cross-chain/// @dev À appeler par le remplisseur/// @param order La définition de l'ordre CrossChain/// @param signature La signature du swapper sur l'ordre/// @param fillerData Toutes les données définies par le remplisseur requises par le règlementfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;/// @notice Résout un ordre CrossChain spécifique en un ResolvedCrossChainOrder générique/// @dev Destiné à améliorer l'intégration normalisée de divers types d'ordres et de contrats de règlement/// @param order La définition de l'ordre CrossChain/// @param fillerData Toutes les données définies par le remplisseur requises par le règlement/// @returns ResolvedCrossChainOrder données d'ordre hydraté comprenant les entrées et sorties de l'ordrefunction resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

Les objectifs de conception de cette norme étaient d'améliorer l'expérience utilisateur du solveur, de faciliter leur soutien à plusieurs réseaux de règlement et de calculer de manière déterministe leurs récompenses. Je crois que cela leur permettra de fournir des devis plus précis et plus serrés aux utilisateurs. Vous pouvez en savoir plus sur cette norme, codée ERC7683, dans ce post X/Twitteret la discussion qui l'entouresur le forum des Magiciens d'Ethereum.

Pensées de clôture

Les "intents" sont confus car ils ne sont pas définis, et ce manque de définition crée de réels défauts d'UX.

Tout le monde veut que tout le monde utilise leur définition standard d'une intention, donc je reconnais pleinement que les normes sont pratiquement impossibles à établir. Je ne pense pas que définir un système de règlement d'intentions en premier et essayer d'attirer des flux d'ordres en second lieu soit la bonne approche pour établir une norme industrielle générale.

À mon avis, l'approche la plus faisable est que les dapps qui possèdent déjà beaucoup de flux d'utilisateurs et qui génèrent de nombreuses intentions d'utilisateurs acceptent de se conformer à une norme minimale que leurs solveurs existants adopteront. Cela formera un nouveau et plus grand pool de solveurs. En obtenant l'accès à un flux d'ordres fusionné à partir de lieux déjà importants, ce nouveau pool de solveurs réalisera plus de profits et pourra proposer de meilleurs prix aux utilisateurs finaux. Finalement, les nouvelles dapps exigeront également de router leurs intentions vers ce pool de solveurs et soutiendront sa norme d'intention.

Pour nous lancer, Across et Uniswap sont conjointementproposer une normepour que toutes les parties de la chaîne d'approvisionnement utilisent lors du traitement des commandes des utilisateurs pour envoyer des jetons X de la chaîne A et recevoir des jetons Y sur la chaîne B. Le flux de commandes passant par UniswapX (ayant un avantage comparatif dans la conception d'enchères et dans l'origine des intentions) et Across (ayant un avantage comparatif dans le règlement des accomplissements des intentions) peut fusionner et lancer le processus de développement d'un réseau de solveurs plus important et plus compétitif.

Démenti:

1. Cet article est repris de [GateMiroir], Tous les droits d'auteur appartiennent à l'auteur original[Nick Pai]. If there are objections to this reprint, please contact the Portail Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.