version v2 de x402

Auteur :YQ,compiler：Bloquer la licorne

La version v2 du protocole x402 est basée sur l’expérience de déploiement en production et représente un changement architectural fondamental (si vous êtes intéressé, vous pouvez vous rendre sur la fondation x402 pour la regarder : https://www.x402.org/writing/x402-v2-launch).Après avoir traité plus de 100 millions de transactions, l’équipe a identifié les principaux points de friction et a repensé le protocole autour de trois objectifs : une séparation claire des couches, une évolutivité indépendante de la blockchain et la conformité aux normes du Web.

Changements dans la version v2

Paiement d’agence traditionnel vs paiement d’agence x402

Les processus de paiement traditionnels nécessitent plusieurs étapes manuelles et une intervention humaine. x402 élimine les frictions en permettant des paiements autonomes et instantanés.

Améliorations architecturales dans la version v2

Interface de paiement unifiée

La version v2 prend en charge le paiement multi-chaînes par défaut.Une API unique pour accepter les paiements USDC sur Base, Solana ou toute blockchain prise en charge sans modifier votre code.

Identifiant de réseau : utilisant CAIP-2

La version v1 utilise des identifiants de réseau personnalisés tels que « base-sepolia » et « base ». La version v2 adopte CAIP-2 (Chain-Independent Improvement Proposal 2) et le format est « namespace:reference ».Cela lui permet de prendre en charge n’importe quel système de paiement blockchain, même non blockchain.

Reconstruction de la demande de paiement

La version v1 comporte des métadonnées de ressources dupliquées dans chaque option de paiement. Si le serveur accepte trois jetons, il répète trois fois l’URL, la description et le type de contenu.La version v2 l’extrait dans un objet ressource partagé, réduisant ainsi la taille du message et éliminant les incohérences.

Développer

La version v2 introduit un système d’extension formel pour des fonctionnalités facultatives qui fonctionnent indépendamment du mécanisme de paiement principal.Chaque extension possède un objet d’information qui contient des données spécifiques à l’extension et un objet de schéma qui définit la structure via le schéma JSON.

Options de paiement explicites

La version v1 utilise des heuristiques de correspondance de champs pour déterminer quelle option de paiement a été sélectionnée par le client.La version v2 rend le processus de sélection plus clair avec un champ « accepté » contenant les conditions de paiement complètes sélectionnées.

Mise à jour du transfert HTTP

Conforme à la norme RFC 6648

L’IETF a déconseillé le préfixe « X- » pour les en-têtes HTTP car les en-têtes expérimentaux ont tendance à devenir des normes de facto mais sont toujours marqués comme expérimentaux. La version v2 supprime ces préfixes et déplace l’exigence de paiement du corps de la réponse vers l’en-tête.Pourquoi passer à l’en-tête ?La séparation des métadonnées du protocole du contenu de l’application permet aux serveurs de renvoyer des paywalls HTML personnalisés aux navigateurs tout en conservant les exigences de paiement lisibles par machine dans l’en-tête.Cela améliore la compatibilité du middleware et l’intégration du framework.

Refactorisation du SDK

Du codage en dur à la modularité

La version v1 du SDK intègre une logique spécifique à la blockchain dans des chaînes if/else imbriquées. L’ajout d’une nouvelle blockchain nécessite de modifier les fichiers principaux et de publier une nouvelle version du SDK.La version v2 introduit trois interfaces pour obtenir une prise en charge plug-and-play de la blockchain.

Enregistrement de modèle de constructeur

Les développeurs enregistrent les implémentations de blockchain à l’aide des caractères génériques CAIP-2.Le SDK achemine les opérations vers l’implémentation correcte en fonction du mode réseau. Correspondance de modèles génériques :eip155:*Correspond à toutes les chaînes EVM •Solana :*Correspond à tous les réseaux Solana• eip155:8453Fait spécifiquement référence au réseau principal de base

Moteur de stratégie basé sur Lambda

Le type de portefeuille et le schéma de paiement sont codés en dur dans la v1.La version v2 introduit des fonctions de stratégie composables pour l’autorisation de paiement à l’exécution.

système de crochet

La version v1 exécute la logique métier après vérification et avant règlement.Si le règlement échoue, le serveur a effectué une opération irréversible (transfert de fichier, appel API, écriture dans la base de données).La version v2 introduit six hooks de cycle de vie.

Configuration

La version v2 du middleware prend en charge la configuration basée sur les routes et fournit des fonctions de rappel pour les décisions d’exécution.

Facilitateur AAmélioration de l’IPFonction

Avis de capacité

Le point de terminaison /support annonce désormais trois fonctionnalités clés : les types de paiement pris en charge regroupés par version de protocole, les adresses de signature pour les opérations de règlement et les extensions implémentées.

découverte automatique

Les extensions de découverte permettent aux services d’exposer des métadonnées structurées pour une indexation automatique.FacilitateurLes points de terminaison prenant en charge le protocole x402 peuvent être récupérés pour maintenir un catalogue de prix à jour sans soumission manuelle.

Stratégie migratoire

La version v2 maintient la compatibilité descendante grâce à l’isolation de l’espace de noms.facilitateuret les serveurs peuvent prendre en charge les deux versions simultanément.Le client spécifie une préférence de version via le champ x402Version et l’implémentation répond avec une version de protocole correspondante.