Aperture est en train de créer un nouveau chatbot UX basé sur une infrastructure Intents sous-jacente qui permettra aux utilisateurs de « déclarer leurs objectifs » en langage naturel et de faire appel à un réseau de solveurs pour bénéficier d'une meilleure exécution et de meilleurs prix que ce qui est possible selon le paradigme transactionnel actuel.
Pour commencer, nous allons commencer par la pierre angulaire de tout mouvement d'adoption massive : l'expérience utilisateur (UX).
L'expérience utilisateur DeFi actuelle est centrée sur une approche transactionnelle qui oblige les utilisateurs aux connaissances techniques variées à approuver un delta ou un changement d'état dans l'espoir que le changement produise « l'état final » qu'ils avaient en tête. Avec Intents, nous avons placé cet « état final » au centre de l'expérience utilisateur.
En utilisant la puissance des LLM modernes et un langage de programmation propriétaire orienté Intents, nous cherchons à améliorer l'expressibilité des intentions des utilisateurs. Cela permettra aux utilisateurs d'exprimer leurs objectifs et préférences transactionnels de manière plus intuitive et plus efficace, exploitant ainsi le potentiel de la blockchain avec plus de facilité et de précision.
Imaginez un utilisateur qui ne comprend pas les principes de la technologie blockchain et qui doit faire face à de nombreux « boutons et boutons » sur l'interface DeFi traditionnelle. L'approche Aperture qui consiste à « permettre à l'utilisateur d'exprimer ce qu'il veut en langage naturel » est plus simple. Cela tient à la nécessité de convertir le langage naturel en code blockchain. C'est là que le langage spécifique au domaine (DSL) entre en jeu.
Un langage spécifique à un domaine (DSL) est un langage informatique spécialisé adapté à un domaine d'application particulier, ce qui le distingue des langages à usage général (GPL) applicables dans un large éventail de domaines. La conception et l'utilisation des DSL font partie intégrante de l'ingénierie des domaines, impliquant souvent la création d'un nouveau DSL ou l'adaptation de DSL existants afin d'exprimer les problèmes et les solutions de manière plus efficace dans un domaine spécifique.
Dans Aperture, le DSL est conçu en mettant l'accent sur la lisibilité humaine, essentielle pour permettre une expression d'intention claire et intuitive. Cette approche diffère des autres DSL qui peuvent donner la priorité à des aspects tels que l'efficacité programmatique ou l'optimisation au niveau de la machine.
Sur Aperture, le LLM comble le fossé entre les fonctionnalités techniques et les interfaces conviviales en permettant à l'utilisateur d'exprimer ses intentions en langage naturel et en reprenant cette même intention sur un DSL très lisible qui peut ensuite être diffusé aux résolveurs en tant que « déclaration de vérité » de la part de cet utilisateur.
Faisons une analogie avec le monde réel : l'expérience utilisateur de traduction LLM vers DSL est similaire à celle d'un client qui passe une commande dans une pizzeria par téléphone. Le client peut commander dans un langage très courant : « Donnez-moi votre pizza avec toutes les viandes, quelle que soit votre taille la plus grande ». L'opérateur à l'autre bout pourrait leur répondre : « Voulez-vous une pizza très grande pour les amateurs de viande ? ». L'utilisateur comprend facilement cette conversion et est d'accord : « Oui, je ne connaissais pas le nom mais c'est celui-ci que je voulais. »
Cette interaction en chaîne se déroulerait de la même manière. L'utilisateur peut commencer par déclarer son objectif final...
« Pouvez-vous rééquilibrer mes LP ETH-GMX sur toutes mes chaînes EVM afin de me concentrer à 80 % sur les configurations les plus performantes et de répartir équitablement les 20 % restants de mon capital de LP entre les pools restants ? »
La traduction DSL peut renvoyer à l'utilisateur —
● Actifs éligibles : paires ETH-GMX sur Mainnet, Arbitrum et Avalanche ;
● Actions autorisées : passerelle, suppression de liquidités, échange d'ETH ou de GMX, ajout de liquidités ;
● Objectif final 1 : Rééquilibrer les positions de liquidité afin de concentrer 80 % du capital actif éligible sur la position présentant le TAEG au comptant le plus élevé, selon les données d'APY Vision ;
● Objectif final 2 : Rééquilibrer les positions de liquidité afin de concentrer 20 % du capital actif éligible sur les pools existants non utilisés dans le cadre de l'objectif final 1 ;
● Signez la déclaration d'intention si elle est correcte
La conversion LLM codifiera le langage courant selon la terminologie normalisée du DSL, qui pourra être exploitée par les solveurs de manière prévisible et reproductible.
L'infrastructure d'intention peut être divisée en plusieurs éléments :
● Intents Clearing House (Mempool) : il sert de zone de préparation préliminaire pour les intentions des utilisateurs. Il est conçu pour organiser et mettre en file d'attente efficacement ces intentions en vue de leur traitement, à l'aide d'algorithmes qui établissent des priorités en fonction de divers critères tels que l'urgence et les besoins en ressources. Le Clearing House garantit la gestion sécurisée et ordonnée des intentions avant qu'elles ne soient enregistrées dans la blockchain.
● ZK-Simulate for Data Validity : il s'agit d'une ressource obligatoire pour valider certaines intentions et les solutions correspondantes qui s'appuieront sur des données hors chaîne. Une preuve de connaissance nulle peut être utilisée pour vérifier la validité de ces données. À l'aide d'outils cryptographiques avancés tels que Brevis ou Axiom, Aperture peut générer des zKP pour les données historiques de la chaîne qui font partie de la solution proposée par le solveur. Cette méthode permet de vérifier rigoureusement les sorties du solveur, afin de s'assurer qu'elles sont exactes, complètes et conformes aux contraintes et aux intentions spécifiées, sans compromettre la confidentialité des données de transaction.
● Contrats intelligents de vérification : chaque type de cas d'utilisation intentionnel nécessitera un contrat intelligent pour simuler, vérifier et contrôler la solution proposée.
● Moteur de classement et d'exécution : chaque groupe d'intentions vérifiées devra être classé en fonction des résultats et du score du solveur, puis exécuté. L'un des aspects cruciaux de ce moteur d'exécution est sa capacité à renforcer la responsabilité. En cas d'activité néfaste, telle que des transactions annulées ou d'autres événements malveillants, le moteur d'exécution est conçu pour pénaliser les résolveurs responsables par le biais de barres obliques ou d'autres moyens. Cela permet non seulement de protéger l'intégrité des transactions, mais aussi de prévenir les comportements malveillants potentiels de la part des solveurs.
Le réseau Solver DAO est une couche applicative unique basée sur l'Intents-Infra. L'Aperture Intents-Infra permet aux DAO de Solver de se concentrer sur l'activation et la résolution de cas d'utilisation uniques basés sur les intentions sans avoir à se soucier des besoins d'exécution sous-jacents.
Solver DAO a accès aux intentions des utilisateurs trouvées dans le Clearing House d'Aperture en misant le montant requis de $APTR et $ETH. Un Solver DAO peut être associé à un grand solveur professionnel doté d'une solution propriétaire ou à un réseau de solveurs plus petits.
Les nouvelles solutions d'intention peuvent provenir d'Aperture ou d'un Solver DAO tiers. Les DAO Solver ajoutent de la valeur en activant le nouveau cas d'utilisation Intent. Cela nécessiterait de soumettre la logique commerciale nécessaire pour s'intégrer à la conception modulaire d'Aperture. Une fois créé, le cas d'utilisation est désormais « déclarable » depuis l'interface Aperture Intents ou depuis une interface tierce créée par le Solver DAO.
L'Aperture DAO fournira une subvention de l'APTR à Solver DAO qui cherche à créer de nouveaux cas d'utilisation d'Intent.
Dans l'écosystème compétitif d'Aperture Intents, les solveurs se différencient par les méthodes qu'ils utilisent pour publier des solutions. Bien que ce ne soit pas obligatoire, les contrats intelligents sont préférés pour leur évolutivité et leur rapidité. Cependant, les scripts hors chaîne sont tout aussi doués pour publier rapidement des solutions, en proposant un autre itinéraire. Certaines intentions déclarées peuvent même présenter des caractéristiques qui permettraient aux solveurs de soumettre des solutions manuellement (par exemple, un vendeur qui souhaite organiser une transaction OTC importante avec une fenêtre d'enchères de 3 jours).
Pour les solveurs qui utilisent de véritables méthodes « alpha » ou propriétaires de génération de solutions, ils peuvent éviter d'utiliser un contrat intelligent pour générer leurs solutions et se fier au processus de vérification ZK d'Aperture pour renforcer la confiance autour de leur solution basée sur les scripts hors chaîne. Cela renforcera l'effet de volant sur l'intégration des solveurs (solutions commerciales durables, augmentation des revenus, attire plus de solveurs).
Bien que cela ne soit pas explicitement obligatoire, un solveur d'un écosystème donné peut également choisir de financer ses exigences de staking via un mécanisme de coffre-fort en échange d'un partage des recettes de son solveur. Chaque Solver DAO peut mettre en œuvre en open source un contrat Rev-Share Vault à mettre en œuvre par ses solveurs (s'ils souhaitent un financement de démarrage).
Pour faciliter les choses, prenons l'exemple de l' « intention de réclamation par largage » proposée dans notre premier billet de blog. Comment un utilisateur pourrait-il déclarer son intention de réclamation ? Comment un Solver DAO spécialisé dans les réclamations a-t-il pu accéder à Solver DAO Marketplace d'Aperture ?
L'utilisateur commencerait par déclarer en langage naturel :
« Réclamez tous les parachutages éligibles en mon nom, y compris les frais de gaz associés à la réclamation, en échange de frais d'identification de 1 % ou moins. »
Le chatbot peut poser des questions de clarification pour mieux comprendre la déclaration de l'utilisateur.
Une fois cette précision apportée, l'intention serait traduite du langage naturel vers le DSL codifié Intents et renvoyée à l'utilisateur dans un format lisible pour qu'il puisse vérifier. À partir de là, l'expression de l'intention sera publiée dans l'Intents Clearing House où tous les solveurs éligibles pourront consulter la déclaration de l'utilisateur.
N'importe quel solveur peut désormais consulter l'adresse de l'utilisateur et la comparer à tous les airdrops ou récompenses éligibles à cette adresse. Une fonction d'autorisation alimentée par un portefeuille d'abstraction de comptes permettrait aux Solvers de réclamer tout airdrop au nom de l'utilisateur. Les solveurs s'affrontaient entre eux en fonction des « frais de recherche » et de leurs connaissances générales en matière de parachutage. Maintenant, quelle est la beauté des intentions, il peut y avoir plusieurs solutions gagnantes et exécutées. Si le Solver A couvre un largage Dymension et le Solver B couvre un largage Celestia, les deux Solvers pourraient gagner des frais de recherche de la part de notre utilisateur.
Les solutions proposées seront toutes simulées par les contrats intelligents d'Aperture afin de vérifier les résultats proposés, puis toutes les solutions vérifiées seront classées. Aperture s'exécutera ensuite pour le compte de l'utilisateur, renvoyant tous les parachutages.
Aperture est en train de créer un nouveau chatbot UX basé sur une infrastructure Intents sous-jacente qui permettra aux utilisateurs de « déclarer leurs objectifs » en langage naturel et de faire appel à un réseau de solveurs pour bénéficier d'une meilleure exécution et de meilleurs prix que ce qui est possible selon le paradigme transactionnel actuel.
Pour commencer, nous allons commencer par la pierre angulaire de tout mouvement d'adoption massive : l'expérience utilisateur (UX).
L'expérience utilisateur DeFi actuelle est centrée sur une approche transactionnelle qui oblige les utilisateurs aux connaissances techniques variées à approuver un delta ou un changement d'état dans l'espoir que le changement produise « l'état final » qu'ils avaient en tête. Avec Intents, nous avons placé cet « état final » au centre de l'expérience utilisateur.
En utilisant la puissance des LLM modernes et un langage de programmation propriétaire orienté Intents, nous cherchons à améliorer l'expressibilité des intentions des utilisateurs. Cela permettra aux utilisateurs d'exprimer leurs objectifs et préférences transactionnels de manière plus intuitive et plus efficace, exploitant ainsi le potentiel de la blockchain avec plus de facilité et de précision.
Imaginez un utilisateur qui ne comprend pas les principes de la technologie blockchain et qui doit faire face à de nombreux « boutons et boutons » sur l'interface DeFi traditionnelle. L'approche Aperture qui consiste à « permettre à l'utilisateur d'exprimer ce qu'il veut en langage naturel » est plus simple. Cela tient à la nécessité de convertir le langage naturel en code blockchain. C'est là que le langage spécifique au domaine (DSL) entre en jeu.
Un langage spécifique à un domaine (DSL) est un langage informatique spécialisé adapté à un domaine d'application particulier, ce qui le distingue des langages à usage général (GPL) applicables dans un large éventail de domaines. La conception et l'utilisation des DSL font partie intégrante de l'ingénierie des domaines, impliquant souvent la création d'un nouveau DSL ou l'adaptation de DSL existants afin d'exprimer les problèmes et les solutions de manière plus efficace dans un domaine spécifique.
Dans Aperture, le DSL est conçu en mettant l'accent sur la lisibilité humaine, essentielle pour permettre une expression d'intention claire et intuitive. Cette approche diffère des autres DSL qui peuvent donner la priorité à des aspects tels que l'efficacité programmatique ou l'optimisation au niveau de la machine.
Sur Aperture, le LLM comble le fossé entre les fonctionnalités techniques et les interfaces conviviales en permettant à l'utilisateur d'exprimer ses intentions en langage naturel et en reprenant cette même intention sur un DSL très lisible qui peut ensuite être diffusé aux résolveurs en tant que « déclaration de vérité » de la part de cet utilisateur.
Faisons une analogie avec le monde réel : l'expérience utilisateur de traduction LLM vers DSL est similaire à celle d'un client qui passe une commande dans une pizzeria par téléphone. Le client peut commander dans un langage très courant : « Donnez-moi votre pizza avec toutes les viandes, quelle que soit votre taille la plus grande ». L'opérateur à l'autre bout pourrait leur répondre : « Voulez-vous une pizza très grande pour les amateurs de viande ? ». L'utilisateur comprend facilement cette conversion et est d'accord : « Oui, je ne connaissais pas le nom mais c'est celui-ci que je voulais. »
Cette interaction en chaîne se déroulerait de la même manière. L'utilisateur peut commencer par déclarer son objectif final...
« Pouvez-vous rééquilibrer mes LP ETH-GMX sur toutes mes chaînes EVM afin de me concentrer à 80 % sur les configurations les plus performantes et de répartir équitablement les 20 % restants de mon capital de LP entre les pools restants ? »
La traduction DSL peut renvoyer à l'utilisateur —
● Actifs éligibles : paires ETH-GMX sur Mainnet, Arbitrum et Avalanche ;
● Actions autorisées : passerelle, suppression de liquidités, échange d'ETH ou de GMX, ajout de liquidités ;
● Objectif final 1 : Rééquilibrer les positions de liquidité afin de concentrer 80 % du capital actif éligible sur la position présentant le TAEG au comptant le plus élevé, selon les données d'APY Vision ;
● Objectif final 2 : Rééquilibrer les positions de liquidité afin de concentrer 20 % du capital actif éligible sur les pools existants non utilisés dans le cadre de l'objectif final 1 ;
● Signez la déclaration d'intention si elle est correcte
La conversion LLM codifiera le langage courant selon la terminologie normalisée du DSL, qui pourra être exploitée par les solveurs de manière prévisible et reproductible.
L'infrastructure d'intention peut être divisée en plusieurs éléments :
● Intents Clearing House (Mempool) : il sert de zone de préparation préliminaire pour les intentions des utilisateurs. Il est conçu pour organiser et mettre en file d'attente efficacement ces intentions en vue de leur traitement, à l'aide d'algorithmes qui établissent des priorités en fonction de divers critères tels que l'urgence et les besoins en ressources. Le Clearing House garantit la gestion sécurisée et ordonnée des intentions avant qu'elles ne soient enregistrées dans la blockchain.
● ZK-Simulate for Data Validity : il s'agit d'une ressource obligatoire pour valider certaines intentions et les solutions correspondantes qui s'appuieront sur des données hors chaîne. Une preuve de connaissance nulle peut être utilisée pour vérifier la validité de ces données. À l'aide d'outils cryptographiques avancés tels que Brevis ou Axiom, Aperture peut générer des zKP pour les données historiques de la chaîne qui font partie de la solution proposée par le solveur. Cette méthode permet de vérifier rigoureusement les sorties du solveur, afin de s'assurer qu'elles sont exactes, complètes et conformes aux contraintes et aux intentions spécifiées, sans compromettre la confidentialité des données de transaction.
● Contrats intelligents de vérification : chaque type de cas d'utilisation intentionnel nécessitera un contrat intelligent pour simuler, vérifier et contrôler la solution proposée.
● Moteur de classement et d'exécution : chaque groupe d'intentions vérifiées devra être classé en fonction des résultats et du score du solveur, puis exécuté. L'un des aspects cruciaux de ce moteur d'exécution est sa capacité à renforcer la responsabilité. En cas d'activité néfaste, telle que des transactions annulées ou d'autres événements malveillants, le moteur d'exécution est conçu pour pénaliser les résolveurs responsables par le biais de barres obliques ou d'autres moyens. Cela permet non seulement de protéger l'intégrité des transactions, mais aussi de prévenir les comportements malveillants potentiels de la part des solveurs.
Le réseau Solver DAO est une couche applicative unique basée sur l'Intents-Infra. L'Aperture Intents-Infra permet aux DAO de Solver de se concentrer sur l'activation et la résolution de cas d'utilisation uniques basés sur les intentions sans avoir à se soucier des besoins d'exécution sous-jacents.
Solver DAO a accès aux intentions des utilisateurs trouvées dans le Clearing House d'Aperture en misant le montant requis de $APTR et $ETH. Un Solver DAO peut être associé à un grand solveur professionnel doté d'une solution propriétaire ou à un réseau de solveurs plus petits.
Les nouvelles solutions d'intention peuvent provenir d'Aperture ou d'un Solver DAO tiers. Les DAO Solver ajoutent de la valeur en activant le nouveau cas d'utilisation Intent. Cela nécessiterait de soumettre la logique commerciale nécessaire pour s'intégrer à la conception modulaire d'Aperture. Une fois créé, le cas d'utilisation est désormais « déclarable » depuis l'interface Aperture Intents ou depuis une interface tierce créée par le Solver DAO.
L'Aperture DAO fournira une subvention de l'APTR à Solver DAO qui cherche à créer de nouveaux cas d'utilisation d'Intent.
Dans l'écosystème compétitif d'Aperture Intents, les solveurs se différencient par les méthodes qu'ils utilisent pour publier des solutions. Bien que ce ne soit pas obligatoire, les contrats intelligents sont préférés pour leur évolutivité et leur rapidité. Cependant, les scripts hors chaîne sont tout aussi doués pour publier rapidement des solutions, en proposant un autre itinéraire. Certaines intentions déclarées peuvent même présenter des caractéristiques qui permettraient aux solveurs de soumettre des solutions manuellement (par exemple, un vendeur qui souhaite organiser une transaction OTC importante avec une fenêtre d'enchères de 3 jours).
Pour les solveurs qui utilisent de véritables méthodes « alpha » ou propriétaires de génération de solutions, ils peuvent éviter d'utiliser un contrat intelligent pour générer leurs solutions et se fier au processus de vérification ZK d'Aperture pour renforcer la confiance autour de leur solution basée sur les scripts hors chaîne. Cela renforcera l'effet de volant sur l'intégration des solveurs (solutions commerciales durables, augmentation des revenus, attire plus de solveurs).
Bien que cela ne soit pas explicitement obligatoire, un solveur d'un écosystème donné peut également choisir de financer ses exigences de staking via un mécanisme de coffre-fort en échange d'un partage des recettes de son solveur. Chaque Solver DAO peut mettre en œuvre en open source un contrat Rev-Share Vault à mettre en œuvre par ses solveurs (s'ils souhaitent un financement de démarrage).
Pour faciliter les choses, prenons l'exemple de l' « intention de réclamation par largage » proposée dans notre premier billet de blog. Comment un utilisateur pourrait-il déclarer son intention de réclamation ? Comment un Solver DAO spécialisé dans les réclamations a-t-il pu accéder à Solver DAO Marketplace d'Aperture ?
L'utilisateur commencerait par déclarer en langage naturel :
« Réclamez tous les parachutages éligibles en mon nom, y compris les frais de gaz associés à la réclamation, en échange de frais d'identification de 1 % ou moins. »
Le chatbot peut poser des questions de clarification pour mieux comprendre la déclaration de l'utilisateur.
Une fois cette précision apportée, l'intention serait traduite du langage naturel vers le DSL codifié Intents et renvoyée à l'utilisateur dans un format lisible pour qu'il puisse vérifier. À partir de là, l'expression de l'intention sera publiée dans l'Intents Clearing House où tous les solveurs éligibles pourront consulter la déclaration de l'utilisateur.
N'importe quel solveur peut désormais consulter l'adresse de l'utilisateur et la comparer à tous les airdrops ou récompenses éligibles à cette adresse. Une fonction d'autorisation alimentée par un portefeuille d'abstraction de comptes permettrait aux Solvers de réclamer tout airdrop au nom de l'utilisateur. Les solveurs s'affrontaient entre eux en fonction des « frais de recherche » et de leurs connaissances générales en matière de parachutage. Maintenant, quelle est la beauté des intentions, il peut y avoir plusieurs solutions gagnantes et exécutées. Si le Solver A couvre un largage Dymension et le Solver B couvre un largage Celestia, les deux Solvers pourraient gagner des frais de recherche de la part de notre utilisateur.
Les solutions proposées seront toutes simulées par les contrats intelligents d'Aperture afin de vérifier les résultats proposés, puis toutes les solutions vérifiées seront classées. Aperture s'exécutera ensuite pour le compte de l'utilisateur, renvoyant tous les parachutages.