jakiro
Autor:YQ,kompilieren:Einhorn blockieren
Die v2-Version des x402-Protokolls basiert auf Erfahrungen mit der Produktionsbereitstellung und stellt eine grundlegende Architekturänderung dar (bei Interesse können Sie sich die x402-Grundlage ansehen: https://www.x402.org/writing/x402-v2-launch). Nach der Verarbeitung von mehr als 100 Millionen Transaktionen identifizierte das Team die wichtigsten Reibungspunkte und gestaltete das Protokoll im Hinblick auf drei Ziele neu: klare Schichtentrennung, Blockchain-unabhängige Skalierbarkeit und Einhaltung von Webstandards.
Änderungen in der v2-Version
Traditionelle Agenturzahlung vs. x402-Agenturzahlung
Herkömmliche Zahlungsprozesse erfordern mehrere manuelle Schritte und menschliches Eingreifen.x402 beseitigt Reibungsverluste, indem es autonome, sofortige Zahlungen ermöglicht.
Architekturverbesserungen in Version 2
Einheitliche Zahlungsschnittstelle
Die v2-Version unterstützt standardmäßig Multi-Chain-Zahlungen.Eine einzige API zum Akzeptieren von USDC-Zahlungen auf Base, Solana oder einer anderen unterstützten Blockchain, ohne Ihren Code zu ändern.
Netzwerkkennung: unter Verwendung von CAIP-2
Die v1-Version verwendet benutzerdefinierte Netzwerkkennungen wie „base-sepolia“ und „base“.Die v2-Version übernimmt CAIP-2 (Chain-Independent Improvement Proposal 2) und das Format ist „namespace:reference“.Dadurch kann jede Blockchain unterstützt werden, auch Nicht-Blockchain-Zahlungssysteme.
Rekonstruktion der Zahlungsnachfrage
In der v1-Version sind die Ressourcenmetadaten in jeder Zahlungsoption dupliziert. Wenn der Server drei Token akzeptiert, wiederholt er die URL, die Beschreibung und den Inhaltstyp dreimal.Die v2-Version extrahiert es in ein gemeinsam genutztes Ressourcenobjekt, wodurch die Nachrichtengröße reduziert und Inkonsistenzen beseitigt werden.
Erweitern
Version v2 führt ein formales Erweiterungssystem für optionale Funktionen ein, das unabhängig vom Kernzahlungsmechanismus funktioniert.Jede Erweiterung verfügt über ein Info-Objekt, das erweiterungsspezifische Daten enthält, und ein Schema-Objekt, das die Struktur über JSON Schema definiert.
Explizite Zahlungsoptionen
Die v1-Version verwendet Feldvergleichsheuristiken, um zu bestimmen, welche Zahlungsoption vom Kunden ausgewählt wurde.Version v2 macht den Auswahlprozess durch ein „Akzeptiert“-Feld, das die vollständigen ausgewählten Zahlungsanforderungen enthält, übersichtlicher.
Aktualisierung der HTTP-Übertragung
Entspricht dem RFC 6648-Standard
Die IETF hat das Präfix „X-“ für HTTP-Header abgelehnt, da experimentelle Header tendenziell zu De-facto-Standards werden, aber immer als experimentell gekennzeichnet sind. Version v2 entfernt diese Präfixe und verschiebt die Zahlungsanforderung vom Antworttext in den Header.Warum zum Header wechseln?Durch die Trennung von Protokollmetadaten und Anwendungsinhalten können Server benutzerdefinierte HTML-Paywalls an Browser zurückgeben und gleichzeitig maschinenlesbare Zahlungsanforderungen im Header beibehalten.Dies verbessert die Middleware-Kompatibilität und die Framework-Integration.
SDK-Refactoring
Von harter Codierung bis hin zur Modularität
Die v1-Version des SDK bettet Blockchain-spezifische Logik in verschachtelte if/else-Ketten ein. Das Hinzufügen einer neuen Blockchain erfordert die Änderung der Kerndateien und die Veröffentlichung einer neuen SDK-Version.Die v2-Version führt drei Schnittstellen ein, um Plug-and-Play-Blockchain-Unterstützung zu erreichen.
Registrierung des Builder-Musters
Entwickler registrieren Blockchain-Implementierungen mithilfe von CAIP-2-Wildcards.Das SDK leitet Vorgänge basierend auf dem Netzwerkmodus an die richtige Implementierung weiter. Wildcard-Mustervergleich:eip155:*Passt zu allen EVM-Ketten •Solana:*Passt zu allen Solana-Netzwerken• eip155:8453Bezieht sich speziell auf das Base-Mainnet
Lambda-basierte Strategie-Engine
Wallet-Typ und Zahlungsschema sind in Version 1 fest codiert. Version v2 führt zusammensetzbare Richtlinienfunktionen für die Zahlungsautorisierung zur Laufzeit ein.
Hakensystem
Die Version v1 führt die Geschäftslogik nach der Überprüfung und vor der Abrechnung aus.Wenn die Abwicklung fehlschlägt, hat der Server einen irreversiblen Vorgang durchgeführt (Dateiübertragung, API-Aufruf, Datenbankschreibvorgang).Die v2-Version führt sechs Lebenszyklus-Hooks ein.
Konfiguration
Die v2-Version der Middleware unterstützt die routenbasierte Konfiguration und stellt Rückruffunktionen für Laufzeitentscheidungen bereit.
Moderator API-ErweiterungFunktion
Hinweis zur Leistungsfähigkeit
Der /support-Endpunkt kündigt jetzt drei Hauptfunktionen an: unterstützte Zahlungsarten, gruppiert nach Protokollversion, Signaturadressen für Abwicklungsvorgänge und implementierte Erweiterungen.
Autodiscover
Discovery-Erweiterungen ermöglichen es Diensten, strukturierte Metadaten für die automatische Indizierung verfügbar zu machen.ModeratorEndpunkte, die das x402-Protokoll unterstützen, können gescrapt werden, um einen aktuellen Preiskatalog ohne manuelle Übermittlung zu verwalten.
Migrationsstrategie
Die v2-Version gewährleistet die Abwärtskompatibilität durch Namespace-Isolation.Moderatorund Server können beide Versionen gleichzeitig unterstützen.Der Client gibt über das Feld x402Version eine Versionspräferenz an und die Implementierung antwortet mit einer passenden Protokollversion.
