Aperture vous emmène à la découverte de l'architecture des intentions (Intents)
TechFlow SélectionTechFlow Sélection
Aperture vous emmène à la découverte de l'architecture des intentions (Intents)
Outre les paroles creuses, quelles fonctionnalités et caractéristiques un système d'intention doit-il réellement posséder ?
Dédié à des analyses Web3 approfondiesAuteur : Aperture Finance
Voici le premier article de la série « Décryptage du domaine des intentions » par Aperture Finance. Dans cet article, nous introduisons la narration autour des intentions, les problèmes qu'elle peut résoudre dans l'écosystème actuel de la DeFi, et mettons en lumière les caractéristiques d'Aperture en tant que projet de pointe dans l'architecture des intentions. Cet article sera utile aussi bien pour les nouveaux venus découvrant ce domaine que pour les investisseurs ou professionnels déjà familiers avec des produits comme Anoma, ou ayant suivi les rapports de Binance Research, Paradigm et Delphi Digital.
Commençons par un scénario simple
Imaginons l’expérience utilisateur future offerte par Aperture, où les utilisateurs peuvent clairement spécifier l’état final souhaité à partir d’une transaction (et obtenir ainsi la meilleure solution via un système d’enchères) :
● Neutraliser la volatilité de 50 % de ma position en ETH, pendant 30 jours, quel que soit le moyen utilisé, à condition que le coût soit plafonné à un taux annuel inférieur à 2 % par ETH ;
● Récupérer tous mes récompenses d’airdrop disponibles, avec une commission intermédiaire ne dépassant pas 1 % (frais de gaz inclus) ;
● Rééquilibrer toutes mes positions de liquidité sur toutes les blockchains et tous les DEX (Uniswap, Maverick et Sushiswap), afin que 60 % des fonds soient concentrés dans le pool au APR le plus élevé, 30 % dans le deuxième meilleur, et 10 % dans le troisième.
Dans le modèle actuel centré sur les « transactions », chacune de ces intentions pourrait donner naissance à un protocole complet, nécessitant financement, développement et création d'une communauté. Mais développer un protocole pour chaque cas prendrait trop de temps. En outre, les utilisateurs restent constamment limités par les interfaces et les contrats intelligents. Il existe pourtant une meilleure solution, mais pour cela, il faut d'abord sortir du paradigme « transactionnel ».
Intention > Transaction
Dans le modèle actuel de la DeFi, on utilise fréquemment une méthode bien connue mais très limitée : celle des « transactions ». L'utilisateur interagit avec une interface dApp, déclenche une opération, puis espère obtenir le résultat souhaité. Cette approche présente de fortes similitudes avec les difficultés du système de santé : les patients font face à une infinité de choix, cherchent à atteindre un objectif médical précis, mais sans aucune garantie d'efficacité ni de contrôle sur le coût final.
Prenons un exemple simple : Monsieur Wang souffre de douleurs cervicales et a les objectifs suivants lors de sa consultation :
● Réduction de la douleur globale entre 40 % et 100 % ;
● Coût inférieur à 500 dollars (payé de sa poche) ;
● Soulagement obtenu dans les trois mois.
De façon analogue à la recherche de solutions sur chaîne, Monsieur Wang pourrait directement envisager une intervention chirurgicale, mais ses options seraient alors limitées par son niveau de connaissance. Il pourrait rencontrer un chirurgien affirmant pouvoir soulager la douleur tout en garantissant un coût inférieur à 500 $. Toutefois, le résultat est souvent décevant : la douleur diminue peu, tandis que les dépenses réelles dépassent largement les 500 $.
À l’inverse, une approche « centrée sur l’intention » pourrait révolutionner ce processus. Dans le même exemple, le patient pourrait exprimer directement sa demande en langage naturel :
« Réduire la douleur cervicale d’au moins 40 % en moins de 3 mois et pour moins de 500 $, en priorisant d’abord l’efficacité, puis le coût, puis le délai. Le prestataire de soins doit avoir un taux de confiance de 99 %. Peu importe le canal utilisé. »
Supposons l’existence d’une plateforme médicale basée sur une architecture d’intentions, permettant aux prestataires de soins (les « solveurs ») de concurrencer entre eux pour proposer la meilleure solution. Ces prestataires pourraient innover techniquement, proposer des thérapies originales ou des offres plus compétitives, et ainsi se distinguer.
Au final, la meilleure solution trouvée par Monsieur Wang pourrait être un traitement de deux mois proposé par un prestataire noté 100 % de fiabilité : une séance de sauna quotidienne accompagnée d'une séance de rééducation toutes les deux semaines, lui permettant de réduire sa douleur de 90 % pour moins de 200 $. (Cet article ne constitue pas un avis médical. En cas de douleurs cervicales, consultez un professionnel.)
Bien sûr, cette analogie a ses limites, car le domaine médical comporte toujours une part d'imprévisibilité. Les coûts et délais peuvent être estimés, mais les effets varient fortement selon les individus. En revanche, dans notre monde blockchain, la situation est radicalement différente : la simulation avancée de processus, l’utilisation des preuves à divulgation nulle (ZKP), et d'autres progrès technologiques permettent aux utilisateurs DeFi d’échapper à cette incertitude.
Alors, quelles conditions doivent être réunies pour rendre l’approche « centrée sur l’intention » réalité ? Au-delà des discours généraux, quelles fonctionnalités et caractéristiques concrètes un système d’intentions doit-il posséder ?
Les composants clés d'une architecture d'intentions
Du point de vue de l’utilisateur final, une expérience utilisateur véritablement basée sur les intentions (Intents UX) repose sur trois composants essentiels, dont la plupart des dApps DeFi (au niveau d’exécution) sont actuellement dépourvus :
1. Une nouvelle interface utilisateur, permettant aux utilisateurs d’exprimer clairement leurs objectifs de transaction. Plus question de choisir simplement entre « oui » ou « non » parmi une liste d'options, mais de décrire précisément l’état final souhaité.
2. Un réseau de solveurs (Solver Network), qui sélectionne de manière concurrentielle la meilleure méthode pour atteindre l’objectif, de façon flexible.
3. Un exécuteur arbitral, capable de classer avec précision les solutions proposées par les solveurs et d’exécuter la solution retenue. Ce réseau de solveurs a la responsabilité de choisir la solution selon ce classement, assurant ainsi la responsabilité des solveurs, et réalisant finalement la transaction entre les dApps et la blockchain (« composable à l’échelle globale »).
Construire une nouvelle interface utilisateur nécessite un langage spécifique au domaine (DSL), permettant à l’interface frontale de transformer l’intention en une instruction exécutable et vérifiable sur la blockchain. Mettre en place un réseau de solveurs est également indispensable pour offrir aux utilisateurs des tarifs et résultats optimaux grâce à la concurrence.
Outre ces composants orientés utilisateur, toute architecture d’intentions doit gérer un ensemble de questions abstraites provenant de l’utilisateur, notamment :
1. Vérifiabilité (composabilité globale) : l’architecture doit disposer d’un mécanisme permettant de vérifier si la solution fournie respecte bien l’intention de l’utilisateur. Standardiser cette vérification est la clé pour libérer l’innovation liée à la « composabilité globale ». Autrement dit, s’il existait une méthode standardisée permettant à un exécuteur arbitral de valider l’état final, quelle que soit la blockchain ou le dApp concerné, les utilisateurs disposeraient d’un véritable réseau d’intentions « globalement composable ».
2. Classement (preuve à divulgation nulle) : en plus de la vérification multi-chaînes et multi-dApp, il faut simuler et classer les solutions proposées. Certaines vérifications peuvent être complexes et coûteuses à réaliser directement sur la chaîne. Dans ce cas, les preuves à divulgation nulle (ZK) permettent de réduire les coûts computationnels. Ces schémas ZK n’ont pas besoin d’être construits depuis zéro : des solutions modulaires comme Axiom ou Brevis peuvent être utilisées.
3. Confidentialité (solveurs à privilèges spéciaux) : certaines intentions pourraient révéler des informations sensibles que l’utilisateur souhaite garder secrètes (par exemple, pour éviter les attaques de frontrunning). Une architecture complète d’intentions peut résoudre ce problème en activant des solveurs à privilèges spéciaux. Ces derniers sont spécialisés dans les intentions confidentielles, disposent de crédits de confiance particuliers, et peuvent traiter des transactions nécessitant une sécurité et une confidentialité renforcées.
4. Comportement des solveurs déviant de l’intention (mécanisme de sanction) : pour garantir que les solveurs exécutent correctement les transactions et n’engagent aucune action malveillante, le système doit intégrer un mécanisme de sanction. Un point clé de l’architecture d’intentions est son système de responsabilisation : en cas de comportement malveillant (annulation de transaction ou autre incident), l’architecture peut sanctionner ces actions. Cela protège non seulement l’intégrité des transactions, mais dissuade aussi les comportements malveillants potentiels.
L’architecture universelle d’intentions d’Aperture
Revenons à l’exemple précédent :
Rééquilibrer toutes mes positions de liquidité sur toutes les blockchains et tous les DEX (Uniswap, Maverick et Sushiswap), afin que 60 % des fonds soient concentrés dans le pool au APR le plus élevé, 30 % dans le deuxième meilleur, et 10 % dans le troisième.
Cet exemple décrit une intention universelle, valable sur toutes les blockchains et tous les DEX. Dans le prochain article, nous exposerons la vision ambitieuse d’Aperture dans le domaine des intentions : un réseau de DAO de solveurs, alimenté par une interface d’interaction unifiée. Dans les articles suivants, nous analyserons la feuille de route 2024 d’Aperture, expliquant comment nous passerons progressivement du plan à la mise en œuvre, construisant étape par étape une architecture universelle d’intentions. Restez à l’écoute !
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
