Bob le Solutionneur : Vers un processus de transaction plus fluide grâce aux « transactions d'intention »
TechFlow SélectionTechFlow Sélection
Bob le Solutionneur : Vers un processus de transaction plus fluide grâce aux « transactions d'intention »
En substance, « l'intention » représente le résultat souhaité, tandis que « la transaction » décrit les étapes précises nécessaires à l'exécution de l'échange.
Dédié à des analyses Web3 approfondiesRédaction : AArow, fondateur de Go2Mars Capital
Le concept d’« intention », récemment mis en avant par Paradigm, fait beaucoup parler de lui. Ce domaine attire également des projets bien financés et soutenus par des investisseurs influents, ce qui renforce encore son attrait économique. Alors, qu’est-ce que les « intentions » (« What Are Intents ? ») ? Aujourd’hui, parlons des « intentions », des « transactions par intention » et d’une infrastructure transactionnelle basée sur les intentions : Bob the Solver.
Comment acheter un bol de pied de porc grâce à une « transaction par intention » ?
Imaginez que vous souhaitiez commander un bol de pied de porc sur Meituan. Vous devez alors : ouvrir l’application Meituan, trouver le restaurant, vérifier s’il existe des coupons de réduction, combiner les offres promotionnelles, payer 20 yuans, puis attendre la livraison. C’est là le processus explicite d’exécution d’une transaction. En revanche, l’« intention » désigne le résultat souhaité par l’utilisateur. Autrement dit, dans cet exemple, votre « intention » serait : « Je veux acheter un bol de pied de porc, et je suis prêt à payer 20 yuans ». Cette instruction est ensuite confiée à un tiers externe chargé de l’exécuter concrètement : ouvrir Meituan, sélectionner le vendeur, appliquer les réductions et finaliser l’achat.
Dans cet exemple, la première approche correspond à une « transaction impérative », où chaque paramètre de la transaction doit être explicitement défini par l’utilisateur. La seconde relève de la « transaction par intention », où l’utilisateur n’a besoin que d’exprimer simplement son objectif pour que la transaction soit accomplie. Bien entendu, dans le cas d’une « transaction par intention », afin de faciliter la réalisation du résultat, il faut déléguer l’exécution des opérations à un tiers.
En essence, une « intention » représente le résultat escompté, tandis qu’une « transaction » décrit précisément les étapes nécessaires à son exécution.
Différence entre intentions et transactions : flux opérationnels comparés
Actuellement, la méthode standard permettant à un utilisateur d’interagir avec Ethereum consiste à créer et signer manuellement une transaction, puis à envoyer un message au format spécifique à la Machine Virtuelle Ethereum (EVM), qui peut ainsi effectuer une transition d’état. Toutefois, la création d’une transaction est une opération complexe : elle est peu efficace, et pousse souvent l’utilisateur à prendre des décisions sans disposer de toutes les informations nécessaires ni d’une stratégie d’exécution optimale.
L’objectif des « intentions » est précisément d’alléger cette charge cognitive pour l’utilisateur. Une intention correspond à la signature d’un ensemble de contraintes déclaratives, qui permettent à l’utilisateur de déléguer la création de la transaction à un tiers, sans pour autant lui transférer un contrôle total. En pratique, cela revient à externaliser intelligemment les opérations complexes vers un tiers autorisé.
Examinons maintenant le flux standard d’une transaction : dans un tel scénario, la signature de la transaction permet aux validateurs d’emprunter un chemin de calcul prédéfini pour atteindre un état donné, tandis que des incitations encouragent les validateurs à suivre ce chemin.
Avec les intentions, la situation change. Une transaction par intention ne spécifie pas le chemin de calcul à suivre, mais autorise tout chemin satisfaisant certaines contraintes. En signant et partageant son intention, l’utilisateur accorde effectivement au destinataire le pouvoir de choisir le chemin de calcul approprié en son nom.
Exemple de projet : Bob the Solver (Bob le Résolveur)
Analysons maintenant un exemple concret (note : ceci ne constitue pas un parrainage du projet, uniquement une analyse).
Bob the Solver (Bob le Résolveur) est une infrastructure transactionnelle fondée sur les intentions, dont l’objectif est d’améliorer l’expérience utilisateur des portefeuilles et des applications décentralisées (dapps). Voyons comment cela fonctionne.
Bob the Solver vise à simplifier le processus transactionnel en s’intégrant directement aux portefeuilles et aux dapps.
Ce projet émerge dans le contexte d’un changement de paradigme naissant dans le domaine des comptes abstraits (nous reviendrons plus tard sur ce sujet), où la création des transactions est déléguée à un tiers. L’accent n’est plus mis sur l’indication d’opérations précises, mais plutôt sur la réalisation effective de l’intention de l’utilisateur.
En réalité, il s’agit fondamentalement d’externaliser la création et l’exécution des transactions, transformant ainsi la manière dont les utilisateurs interagissent avec les transactions blockchain, rendant l’expérience globale plus intuitive et conviviale.
La mise en œuvre de Bob the Solver repose sur deux composants interconnectés :
1. Un « résolveur » (Solver) chargé de créer les transactions (txs) ;
2. Un portefeuille à compte abstrait (AA Wallet) chargé d’exécuter ces transactions.
Le Résolveur (Solver)
Le Résolveur : équipé de modèles d’apprentissage automatique (machine learning, ML), il classifie les intentions des utilisateurs.
Une fois l’intention classifiée, un moteur d’optimisation analyse les itinéraires transactionnels possibles afin d’identifier le chemin le plus efficace pour atteindre le résultat souhaité.
Après identification du meilleur chemin, le résolveur construit la transaction requise au nom de l’utilisateur, puis la transmet au portefeuille AA.
Portefeuille à compte abstrait (AA - Account Abstraction)
Le portefeuille AA joue le rôle d’exécuteur du système. Il comprend un « bundler » (regroupeur) et un « paymaster » (payeur).
Le rôle du bundler est de collecter et organiser les transactions prévues par le résolveur.
Par ailleurs, le paymaster gère les frais de gaz associés à ces transactions. Cela signifie qu’il paie les frais de gaz quand nécessaire, garantissant ainsi une exécution fluide et ininterrompue des transactions.
Grâce à l’utilisation de modèles ML pour interpréter les intentions des utilisateurs, le résolveur élimine la complexité inhérente à la construction des opérations transactionnelles, tandis que le portefeuille AA assure une exécution fiable des transactions.
En combinant ces deux composants, on parvient à simplifier considérablement les étapes de transaction. Par exemple, si vous souhaitez effectuer une transaction en disant simplement : « Je veux acheter un BAYC au prix plancher », alors « Bob the Solver » peut vous offrir une expérience transactionnelle fluide et hautement efficace.
Vous n’avez plus besoin de comparer différents logiciels de trading ou d’effectuer vous-même les manipulations techniques. Il vous suffit d’exprimer votre « intention », le reste étant pris en charge par la « transaction par intention ».
Note : Les opinions exprimées dans cet article s'appuient largement sur mes lectures des travaux de Quintus Kilbourn et Georgios Konstantopoulos de Paradigm, notamment leur article « Intent-Based Architectures and Their Risks » (Architectures basées sur les intentions et leurs risques), complétées par des projets actuels populaires et mon propre point de vue. Pour une compréhension plus complète, nous vous invitons à lire l'article original des auteurs de Paradigm.
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
Go2Mars Capital
