Auteur original : Hendrix, Chercheur chez Waibu Research (Web3Caff Research)
Comment maîtriser facilement les tendances du marché, les évolutions technologiques, les progrès des écosystèmes, les dynamiques de gouvernance en cours dans le secteur Web3...? La rubrique « Analyse du Pouls du Marché » lancée par Waibu Research (Web3Caff Research) explore en profondeur les événements chauds du moment, les sélectionne, et en propose une interprétation de valeur, des commentaires et une analyse des principes. Voir l'essence à travers les phénomènes, suivez-nous dès maintenant pour capturer rapidement les tendances de première ligne du marché Web3.
Avec l'augmentation continue des capacités des agents intelligents d'IA et leur couverture d'un nombre croissant de tâches de bout en bout, la construction de systèmes de paiement pour les agents est devenue un changement nécessaire pour les commerçants traditionnels et les fournisseurs de services. Cependant, les solutions existantes ont chacune leurs limites : les systèmes de paiement traditionnels, comme les cartes de crédit ou les plateformes de paiement tierces, conçus à l'origine pour des utilisateurs humains, nécessitent des processus complexes de vérification d'identité, d'évaluation des risques, etc., qui ne sont pas adaptés aux agents intelligents. Les nouveaux protocoles de paiement pour agents, comme x402 (développé et promu par Coinbase) ou MPP (Machine Payment Protocol développé par Tempo et Stripe), semblent partir de zéro, construits entièrement pour les paiements on-chain, le traitement du paiement se faisant sur la blockchain, la sécurité étant assurée par la vérification on-chain. Les fournisseurs de services doivent mettre en place un système de paiement différent en plus de leurs canaux de paiement traditionnels, augmentant ainsi le seuil d'adoption. Les solutions de paiement traditionnelles et les nouveaux protocoles de paiement pour agents ressemblent à deux voies parallèles qui ne se rejoignent pas vraiment, ce qui limite également les services que les agents peuvent acheter de manière autonome, généralement à la sphère Web3-friendly, les empêchant ainsi de créer des flux de travail massifs et interconnectés. C'est pourquoi la Fondation Solana et Google Cloud ont conjointement lancé Pay.sh, se positionnant comme la "passerelle de paiement entre les agents intelligents et les infrastructures de services d'entreprise", franchissant la dernière étape permettant aux agents d'accéder à davantage de services.
Avertissement de conformité : Le contenu suivant est uniquement une analyse objective de Pay.sh, de ses principes techniques et de ses règles de conception. Cela ne constitue en aucun cas une recommandation ou une offre. Veuillez ne pas prendre de décisions basées sur ces informations et respecter strictement les lois et réglementations de votre pays ou région (les lecteurs basés en Chine continentale sont fortement encouragés à lire «Résumé et points clés des lois et réglementations relatives à la blockchain et aux crypto-monnaies en Chine continentale »). Ne participez à aucune activité financière interdite par les lois de votre pays ou région.
Pay.sh permet aux utilisateurs de recharger rapidement un portefeuille Solana via une carte de crédit ou des stablecoins. Ensuite, le portefeuille Solana peut agir comme identité et compte de paiement mandataire pour l'agent intelligent dans le monde des ressources Web2. Lorsqu'un agent intelligent a besoin d'appeler un service, il n'a plus besoin de créer un compte ou de saisir une clé API. La passerelle Pay.sh déclare l'identité légitime de l'agent, comme le ferait un système d'identité Google, permettant à l'agent d'utiliser une identité de compte unifiée pour acheter des ressources de développement comme Google Cloud, Alibaba Cloud, etc., qui étaient auparavant difficiles à obtenir.
Services API actuellement pris en charge par Pay.sh. Source : site officiel du projet
Le processus de paiement de Pay.sh est similaire au protocole x402 qui a récemment fait sensation, tous deux étant construits sur le code d'état HTTP 402 : lorsqu'un agent intelligent découvre un service externe à appeler, il envoie une requête pour la ressource payante. Le serveur renvoie le code d'état 402 (Paiement requis) accompagné des détails du paiement, tels que le montant, le plan tarifaire, l'adresse du bénéficiaire, la durée de validité du paiement, etc. Pay.sh analyse ces informations et demande une autorisation au portefeuille. Une fois le paiement effectué par le portefeuille et le justificatif de paiement généré, Pay.sh renvoie la requête de service avec le justificatif pour obtenir une réponse normale. Mais pour couvrir divers scénarios d'utilisation d'API, Pay.sh est compatible à la fois avec la logique de paiement de x402 et de MPP : lorsque le serveur renvoie le code d'état 402, Pay.sh évalue en outre le mode de paiement du service cible. S'il s'agit d'un accès ponctuel aux données (paiement pour un accès unique) ou d'un accès basé sur la consommation (paiement pour un quota d'accès fixe), Pay.sh construit un transfert unique à montant fixe et le diffuse sur la blockchain. S'il s'agit d'une facturation continue ou basée sur une session (paiement forfaitaire basé sur la consommation), Pay.sh prend en charge le justificatif d'autorisation de session introduit par le protocole MPP (Machine Payment Protocol), écrit la limite budgétaire dans l'autorisation et la renvoie au serveur. Ainsi, l'agent intelligent peut appeler à plusieurs reprises un service sur une courte période, évitant de lancer fréquemment des autorisations similaires. Pay.sh met à jour le solde restant à chaque appel et relance automatiquement l'autorisation de session lorsque le quota est épuisé ou que le service expire. Pay.sh choisit automatiquement la voie de paiement la plus adaptée en fonction des exigences du service cible, ce qui peut réduire les coûts d'utilisation et de gestion. Pay.sh garantit également que le portefeuille reste stocké en local en toute sécurité, ne demandant confirmation à l'utilisateur qu'au moment du paiement. Lorsque des informations sont renvoyées, Pay.sh distingue les données des instructions. Tous les contenus externes renvoyés par le fournisseur de service (y compris les titres, le corps du texte et les descriptions d'API) sont traités par Pay.sh comme des entrées non fiables ; l'agent ne doit pas exécuter directement les instructions renvoyées par le fournisseur pour prévenir les injections d'invites malveillantes ou d'autres attaques.
Le plus grand avantage de Pay.sh est qu'il offre également une passerelle facile à déployer pour les fournisseurs de services. Ces derniers n'ont pas besoin d'apporter des modifications importantes à leurs circuits de paiement ou à leurs API pour intégrer la passerelle de paiement dans leur réseau de services. Il suffit de fournir un fichier déclaratif décrivant les paramètres liés au paiement pour s'adapter à divers scénarios d'utilisation complexes. Par exemple, en définissant des règles de routage, les agents peuvent utiliser un service gratuitement jusqu'à un certain quota, puis payer au-delà, voire implémenter une tarification progressive (prix différents selon la consommation). De plus, Pay.sh offre une fonctionnalité de fractionnement des paiements : les frais reçus par le fournisseur de service peuvent être automatiquement envoyés à plusieurs adresses, par exemple 2 % pour les redevances de droits d'auteur sur les données, 5 % pour les coûts cloud, le reste pour ses propres opérations. Le fournisseur de service n'a qu'à définir différents pourcentages ou montants lors de la configuration de l'adresse de paiement pour réaliser un règlement multi-comptes en une seule fois. Après l'enregistrement, le fournisseur de service peut publier les données de ses services API dans le Pay Skill Registry. Les agents intelligents peuvent ainsi découvrir et choisir les services API appropriés en interrogeant ce registre.
Pay.sh lui-même n'est pas un concurrent des protocoles x402 et MPP. Alors que ces protocoles s'efforcent de rendre les paiements on-chain par les agents aussi fiables que possible, l'objectif de Pay.sh est de relier les écosystèmes de paiement Web2 et Web3, en dotant les agents intelligents de l'identité nécessaire pour accéder aux ressources. Le portefeuille de l'agent est à la fois son identité et son moyen de paiement ; il n'a plus besoin de créer un compte sur le site du fournisseur pour obtenir le service (certains fournisseurs pourraient considérer comme une violation la simulation par un agent d'une inscription humaine). Par ailleurs, le partenariat de Pay.sh avec Google permet que l'exécution de l'agent mandataire d'API et la gestion du trafic se fassent sur Google Cloud, assurant ainsi le contrôle d'accès et la conformité des journaux, et maintenant le comportement des agents dans des limites raisonnables. Pay.sh peut fournir un catalogue de services et une découverte des prix présélectionnés ; les agents n'ont pas besoin de découvrir des services au hasard dans un environnement réseau non protégé. Ils peuvent utiliser à la fois les différents modes de paiement de x402 et MPP, et le processus de service peut être réalisé sur Google Cloud pour répondre aux exigences de conformité des entreprises. Ces éléments complètent les capacités de paiement des agents que les canaux uniques de paiement comme x402 et MPP ne pouvaient couvrir, tout en ouvrant une porte pour le flux commercial des agents vers le Web3. De plus, Pay.sh peut également compléter l'étape finale de paiement pour plusieurs protocoles commerciaux pour agents proposés par Google, comme A2A (Agent2Agent Protocol) pour la communication et la délégation de tâches entre agents, AP2 (Agent Payments Protocol) pour la vérification de conformité, UCP (Universal Commerce Protocol) pour la découverte et l'exécution de services, Pay.sh se chargeant du règlement sans friction de la valeur du service. L'apparition de Pay.sh parachève également les maillons du commerce des agents Web2, devenant le point de convergence des flux de valeur entre les deux mondes. Cette étape représente également une opportunité d'évolution pour l'écosystème de la blockchain Solana elle-même. Dans l'environnement du protocole x402, il existe de nombreuses API "coquilles", des fournisseurs de services qui violent les conditions d'utilisation du fournisseur original pour revendre son service, par exemple en récoltant malicieusement des données d'un site de base de données pour les revendre, ou en encapsulant l'API d'un grand modèle pour la revendre à d'autres. Les agents intelligents n'ont aucun moyen de distinguer les services autorisés des services malveillants ou indésirables. Grâce à la passerelle de paiement Pay.sh et à la collaboration avec Google, les agents utilisant des services via Pay.sh pourraient réduire les risques potentiels. Le lancement de Pay.sh marque l'entrée en scène de la blockchain Solana pour fournir une caution et une infrastructure de support aux paiements par agents. Cela peut non seulement attirer davantage de flux de paiement Web2 vers Solana, mais aussi améliorer encore les capacités des portefeuilles Solana et accélérer leur adoption.
Mais Pay.sh est encore loin d'être une solution de passerelle de paiement parfaite. Le registre des fournisseurs de services de Pay.sh manque actuellement de mécanismes d'admission et de validation décentralisés, rendant toujours difficile la distinction effective entre les services tiers "coquilles" non autorisés et les services malveillants. Les agents intelligents risquent fort de se connecter à des services contrefaits, causant des pertes aux utilisateurs. De plus, comme Pay.sh ne conçoit pas lui-même les protocoles de paiement sous-jacents, la sécurité du processus de paiement repose davantage sur la conception de ces protocoles eux-mêmes, ce qui introduit un risque externe incontrôlable pour Pay.sh, et pourrait également entraîner des échecs de paiement potentiels en raison d'une adaptation insuffisante aux différents protocoles. Du point de vue des fournisseurs de services, malgré la caution de la plateforme Google, des fournisseurs d'API de différents pays et régions pourraient encore hésiter à adopter les services proposés par Pay.sh, en raison des exigences de conformité liées à la confidentialité des données ou aux paiements de leurs propres services. Cela pourrait non seulement limiter le nombre de fournisseurs utilisant Pay.sh, mais aussi exiger de Pay.sh davantage d'efforts de conformité à l'avenir. Quoi qu'il en soit, le lancement de Pay.sh marque une étape dans la fusion et la concrétisation des infrastructures de paiement pour agents entre le Web2 et le Web3. Les portefeuilles on-chain auront l'opportunité de devenir la caution permettant aux agents de participer à des tâches diversifiées. Nous pouvons donc continuer à observer les développements ultérieurs de Pay.sh.
Schéma de structure des points clés :
Avis de non-responsabilité : Ce rapport est rédigé par Waibu Research (Web3Caff Research). Les informations qu'il contient sont fournies à titre informatif uniquement et ne constituent en aucun cas une prévision, un conseil en investissement, une recommandation ou une offre. Les investisseurs ne doivent pas se baser sur ces informations pour acheter ou vendre des titres, des crypto-monnaies ou adopter une stratégie d'investissement. Les termes utilisés et les points de vue exprimés dans le rapport visent à faciliter la compréhension des tendances du secteur et à promouvoir le développement responsable du Web3, y compris de l'industrie blockchain, et ne doivent pas être interprétés comme des opinions juridiques explicites ou les opinions de Waibu Research (Web3Caff Research). Les opinions exprimées dans le rapport reflètent uniquement les opinions personnelles de l'auteur à la date indiquée, sont indépendantes de la position de Waibu Research (Web3Caff Research) et sont susceptibles de changer par la suite. Les informations et opinions contenues dans ce rapport proviennent de sources propriétaires et non propriétaires que Waibu Research (Web3Caff Research) estime fiables, ne couvrent pas nécessairement toutes les données et n'en garantissent pas l'exactitude. Par conséquent, Waibu Research (Web3Caff Research) ne donne aucune garantie quant à leur exactitude et fiabilité, ni n'assume la responsabilité des erreurs et omissions pouvant en résulter (y compris la responsabilité envers toute personne découlant d'une négligence). Ce rapport peut contenir des informations « prospectives », pouvant inclure des prévisions et projections, et ne constitue pas une garantie concernant ces prévisions. Le choix de s'appuyer ou non sur les informations contenues dans ce rapport relève de la seule responsabilité du lecteur. Ce rapport est fourni à titre informatif uniquement, ne constitue pas un conseil en investissement, une recommandation ou une offre d'achat ou de vente de titres, de crypto-monnaies ou d'adoption d'une stratégie d'investissement, et vous êtes prié de respecter strictement les lois et règlements en vigueur dans votre pays ou région.
