Intentions : Possibles réponses aux problèmes de complexité de la Finance décentralisée

Avant l'effondrement de Luna, je mettais en place une stratégie de rendement en stablecoins pour un ami qui souhaitait comprendre les taux d'intérêt élevés qu'il pouvait obtenir en janvier 2020. Cet ami n'est pas très au fait des cryptomonnaies et n'avait même jamais effectué d'opérations en chaîne auparavant. Notre collaboration était simple : il déposait des fonds dans un portefeuille matériel, puis nous nous rencontrions une ou deux fois par semaine via Zoom, et je le guidais progressivement sur les opérations qu'il devait réaliser.

Nous avons réparti les fonds dans presque tous les protocoles de Finance décentralisée disponibles sur différentes chaînes. Au cours d'une session de 2 à 4 heures, nous effectuons des dizaines d'approbations, de transferts, d'échanges, de dépôts, de réclamations et de retraits de fonds. Les fonds sont transférés dans des paires de trading LP Uniswap sur mesure, dans le vote de verrouillage Curve, etc., tous les fonds sont dispersés pour obtenir des incitations. Nous avons utilisé presque tous les principaux ponts inter-chaînes, DEX et agrégateurs de rendement pour déplacer notre panier de stablecoins, afin d'accéder à divers rendements dans le domaine des cryptomonnaies.

Dire que je lui ai demandé d'agir à l'aveuglette est un peu trop euphémique.

La partie la plus difficile de mon travail est d'essayer d'expliquer en détail toutes les étapes à suivre. Je donne des instructions d'opération, il les exécute, tout en devant également comprendre l'interface de ces outils DeFi complexes. Nos réunions sont remplies d'instructions opérationnelles telles que "cliquez ici", "allez là", "échangez ceci". Prenons l'exemple de l'échange de USDC en FRAX/DAI LP sur Polygon :

1. Échanger USDC contre DAI(2 sur un DEX, approuver + échanger)
2. Transférer USDC et DAI sur Polygon ( en 4 transactions, approuver + transfert inter-chaînes )
3. Fusionner USDC et DAI( dans une transaction sur un DEX sur Polygon, approuver + fusionner)
4. Déposer LP dans le coffre de rendement (2 transactions, approuver + déposer )

Une simple circulation de fonds nécessite déjà l'initiation de 12 transactions ! Nous devons utiliser les informations fournies par l'interface spécifique au protocole pour interroger, créer et exécuter directement une transaction unique sur l'EVM. Ce processus est manuel, chronophage et ardu, en particulier lorsque la taille du portefeuille est importante. En y repensant, ces tâches ne faisaient que reproduire quelques DApp de finance décentralisée, mais leur exécution manuelle est très complexe.

D'un point de vue plus élevé, tous les processus que nous exécutons ont des résultats attendus clairs. Nous avons des actifs et souhaitons les utiliser pour accomplir des tâches X, Y, Z. Comme dans l'exemple ci-dessus, "nous avons USDC( sur Ethereum), nous espérons fournir de la liquidité sous la forme de FRAX/DAI( sur Polygon), puis les déposer dans un vault de staking". C'est le "contenu" de notre opération, et les 12 transactions que nous devons exécuter sont le "comment" de l'opération. Un ensemble d'étapes claires et logiques est nécessaire du point de départ à la fin, toutes ces étapes étant quantifiables.

Un puissant algorithme construit pour gérer le routage des transactions simplifiera ce processus en seulement 1 à 2 étapes. Nous partageons le résultat souhaité, et l'algorithme nous renverra le meilleur chemin, pouvant même traiter la transaction. Ce type de structure de cartographie des chemins est appelé "intention", et fait partie de l'avenir des middleware en pleine expansion d'Ethereum. Bien que nous ayons une conception large de l'intention, il n'y a pas encore de consensus sur sa définition. Actuellement, il existe quelques idées générales. La définition d'une organisation est : "L'intention est un ensemble de contraintes déclaratives signées, permettant aux utilisateurs d'externaliser la création de transactions à des tiers, sans renoncer au contrôle total sur les parties transactionnelles". Une autre définition donnée par David Ma de Near est : "Les transactions sont impératives, tandis que les intentions sont déclaratives. En d'autres termes, les transactions sont des messages clairement définis, spécifiant comment exécuter l'EVM pour générer des changements d'état, tandis que les intentions spécifient les changements d'état souhaités, sans se soucier du processus de mise en œuvre."

Dans ces deux définitions, l'intention est "déclarative", c'est-à-dire qu'elle cherche une aide externe par le partage de données entre l'utilisateur et le "solveur". L'utilisateur déclare le résultat souhaité, et le solveur lui fournit un moyen de l'atteindre. Contrairement aux transactions avec des paramètres spécifiques, l'intention doit être mappée par un tiers. De plus, il existe des contraintes qui limitent l'ensemble des chemins possibles. Cela aide à concentrer le nombre total de possibilités dans un ensemble plus petit et filtrable, à partir duquel l'utilisateur peut faire son choix. Prenons l'exemple de mon ami, l'intention nous permet de diffuser l'objectif final à un groupe de solveurs, qui calculent ensuite le meilleur chemin. Nous choisirons ensuite la route la plus avantageuse et exécuterons la transaction. Toutes les étapes intermédiaires seront gérées par le chemin fourni par le solveur, laissant 1 à 2 transactions nécessitant la confirmation de l'utilisateur.

L'architecture de base basée sur "l'intention" est déjà construite sur l'EVM. Lorsque vous utilisez un DEX, il trouvera le meilleur chemin d'exécution des transactions. Dans certaines interfaces DEX, après avoir sélectionné les actifs à acheter ou à vendre, l'interface utilisateur trouvera automatiquement le meilleur LP pour le routage. Comme il n'y a pas de LP USDT/frxETH, les ordres passent par plusieurs LP pour obtenir le meilleur chemin d'exécution : USDT > sUSD > sETH > ETH > frxETH, le tout réalisé en une seule transaction. Il donne également une estimation de l'impact sur le prix, ainsi que des mesures que les utilisateurs peuvent prendre pour limiter le slippage. Une fois les bons paramètres sélectionnés, l'interface utilisateur peut également aider à construire les données EVM brutes à diffuser.

Cette intention de transaction sur un certain DEX n'est qu'un exemple très basique. L'UI n'est qu'un outil utile pour construire des transactions d'échange via la logique suivante :

Échange FRAX: Échanger 100 000 FRAX contre au moins 999 000 USDC en utilisant un LP FRAX/USDC de 5 bps, valable jusqu'à X blocs. D'autre part, l'intention de partager le résultat souhaité ( pour obtenir le maximum d'USDC ) et de contraindre ( à ne vendre que 100 000 FRAX ). C'est au solveur de déterminer quel est le meilleur taux d'échange.

Si vous avez déjà utilisé certains agrégateurs DEX, vous verrez un système d'intention pour construire des transactions d'échange. En utilisant ces agrégateurs, vous fournissez toujours tous les paramètres d'exécution, puis vous obtenez un ensemble de relais de transactions potentiels qui exécuteront la transaction. Tous les échanges potentiels se déroulent toujours sur un DEX spécifique ( sauf pour certains échanges ), mais en fonction des relais de transactions, ils ont des frais et des coûts de gaz différents. C'est finalement à l'utilisateur de choisir le meilleur prix/coût.

En plus des agrégateurs de transactions, il existe plusieurs autres types d'"intentions" sur Ethereum :

1. Ordre à cours limité : si les conditions sont remplies, il est permis de retirer des actifs du compte.

2. Enchères de type échange : exécution d'ordres tiers basée sur la liquidité non DEX.

3. Gas sponsorisé : permet d'utiliser des jetons comme FRAX pour effectuer des transactions tierces, applicable aux portefeuilles abstraits.

4. Mandat : La liste blanche appartient à ce cas, une vérification de la base de données est effectuée avant d'exécuter la transaction.

5. Traitement par lots des transactions : permet de regrouper les intentions d'efficacité du Gas.

6. Échange inter-chaînes: voir certaines plateformes de trading inter-chaînes.

Bien que les types de commandes deviennent de plus en plus variés, la manière la plus simple que j'ai vue pour décrire une intention est "ordre à cours limité", mais avec un nouveau terme marketing. Un ordre à cours limité fait référence à la volonté d'acheter une quantité spécifique d'actifs à un prix déterminé, et l'ordre ne sera exécuté que lorsque l'autre partie apparaîtra et acceptera la commande.

Comme les ordres à cours limité, l'intention se compose de deux parties dans une transaction. La première partie est l'état final souhaité par l'utilisateur. La deuxième partie est la transaction initiée par le solveur. Lorsque vous combinez les deux, vous obtenez finalement ce qui est nécessaire pour exécuter la transaction.

Vente de MEV

La méthode de construction basée sur l'architecture des intentions présente presque aucun risque. Tout d'abord, les solveurs n'ont pas intérêt à diffuser des intentions MEV dont ils pourraient tirer profit. "Dans de nombreux cas, l'extraction de MEV nécessite l'exécution des commandes des utilisateurs sur la chaîne. Dans ces situations, l'exécution des commandes des utilisateurs expose l'état de la blockchain, et l'extracteur peut tirer profit de cet état. Les transactions rétroactives et les transactions sandwich sont quelques exemples courants."

La caractéristique principale de l'intention est l'exposition des données. En signant un message d'intention, vous indiquez que vous êtes prêt à extraire le MEV au détriment de la commodité. Comme l'intention ne peut pas être directement diffusée dans la mémoire de la chaîne Ethereum, où les transactions ( font la queue avant d'être exécutées ), elles sont remplies dans des Interpool privés hors chaîne. Ces Interpool peuvent être autorisés, non autorisés ou un mélange des deux.

Interpool sans autorisation utilise une API décentralisée, permettant aux nœuds du système de partager librement leurs intentions et de donner aux exécutants un accès illimité. Des exemples incluent certains relais de protocole et le pool de mémoire ERC4337 partagé proposé. Le pool de mémoire ouvert est déjà mature pour les attaques DDOS et ne peut pas garantir d'empêcher la propagation des intentions de mauvaise exécution.

En revanche, le pool de mémoire autorisé utilise une API de confiance, capable de résister aux DDoS, sans nécessiter de propagation d'intention. En s'appuyant sur des intermédiaires de confiance, tant qu'ils maintiennent la confiance, ils peuvent garantir la qualité d'exécution. Ces intermédiaires jouissent généralement d'une bonne réputation, ce qui peut les inciter à garantir une exécution de premier ordre. Cependant, ils ont toujours une forte hypothèse de confiance, ce qui nuit à l'esprit même des blockchains ouvertes.

Les solutions hybrides comblent le fossé entre les systèmes autorisés et non autorisés. Elles peuvent adopter une diffusion autorisée combinée à une exécution non autorisée, et vice versa. Par exemple, certains protocoles d'enchères de flux de commandes utilisent une partie de confiance ( pour faire correspondre les commandes hors chaîne ) afin d'opérer des enchères, mais la participation est sans autorisation.

L'Interpool le plus populaire aujourd'hui est centralisé et sous licence, sans aucune incitation à partager des informations avec ses concurrents. Le risque ici est qu'une partie absorbe la majorité des transactions basées sur l'intention et utilise sa position monopolistique pour commencer à imposer des frais et d'autres comportements de rente, les utilisateurs ayant un pouvoir de négociation ayant disparu entre les mains d'intermédiaires exploitants.

Risque de middleware

Lorsque l'intention est considérée comme un ordre à cours limité, nous pouvons faire une comparaison claire avec le flux d'ordres de certains courtiers en utilisant le paiement (PFOF).

Ces géants de courtage offrent des transactions "gratuites" aux utilisateurs, basées sur la vente du flux d'ordres plutôt que sur l'envoi de ceux-ci vers des bourses traditionnelles. Les teneurs de marché sont des entreprises qui achètent et vendent en grande quantité des titres, et elles fournissent ce paiement car elles peuvent réaliser un profit sur l'écart entre les prix d'achat et de vente des ordres. Les critiques dénoncent largement ces courtiers pour conflit d'intérêts. Bien que les sociétés de courtage aient l'obligation de fournir la meilleure exécution pour les ordres de leurs clients, les incitations monétaires liées au PFOF seraient censées influencer leurs décisions d'envoi des ordres.

L'intention est une forme d'arbitrage PFOF que nous appelons MEV. Les opportunités d'arbitrage créées par certaines commandes non liquidées à long terme ( peuvent être plus précieuses que les transactions ajoutées manuellement au pool de mémoire Ethereum, car le solveur peut déterminer le chemin, au lieu de rivaliser avec des transactions de sandwich pour obtenir le MEV avant ou après la transaction dans un bloc donné.

Les solveurs non vérifiés et opaques sont très susceptibles de fournir les pires itinéraires, car leurs marges bénéficiaires sont inversement proportionnelles à leur capacité d'exécution. Les utilisateurs doivent toujours choisir un solveur, et ils peuvent utiliser ce pouvoir de négociation pour forcer les solveurs à enchérir les uns contre les autres pour capter le flux de commandes. Le solveur qui offre le meilleur retour aux utilisateurs sous des contraintes remporte l'enchère.

Certains protocoles de trading utilisent ce type de conception, qui emploie des enchères par lots pour trouver le meilleur prix de règlement pour les traders. Dans ces protocoles, les ordres ne sont pas exécutés immédiatement, mais sont plutôt collectés et réglés par lots. Ce système ne fait pas appel à un opérateur central, mais utilise une concurrence publique entre les solveurs pour faire correspondre les ordres. Une fois le lot terminé, ces solveurs soumettent des solutions pour le règlement des ordres.

Les enchères par lots permettent à un groupe de transactions d'avoir le même prix, évitant ainsi aux mineurs de réorganiser les transactions. Il n'y a pas de front-running ou de back-running. Ces protocoles utilisent des enchères de flux d'ordres pour garantir que les traders obtiennent la meilleure exécution des prix. Mais certaines de ces commandes contiennent également du MEV, car les teneurs de marché doivent être en mesure d'effectuer des transactions d'arbitrage sur un autre marché pour rester rentables.

![Pourquoi les intentions (Intents) peuvent être Finance décentralisée