Autor:YQ,compilar:Bloque de unicornio
La versión v2 del protocolo x402 se basa en la experiencia de implementación de producción y representa un cambio arquitectónico fundamental (si está interesado, puede ir a la base x402 para verlo: https://www.x402.org/writing/x402-v2-launch).Después de procesar más de 100 millones de transacciones, el equipo identificó puntos de fricción clave y rediseñó el protocolo en torno a tres objetivos: separación clara de capas, escalabilidad independiente de blockchain y cumplimiento de estándares web.
Cambios en la versión v2
Pago de agencia tradicional versus pago de agencia x402
Los procesos de pago tradicionales requieren múltiples pasos manuales e intervención humana.x402 elimina la fricción al permitir pagos instantáneos y autónomos.
Mejoras arquitectónicas en la versión v2.
Interfaz de pago unificada
La versión v2 admite pagos multicadena de forma predeterminada.Una API única para aceptar pagos en USDC en Base, Solana o cualquier blockchain compatible sin modificar su código.
Identificador de red: usando CAIP-2
La versión v1 utiliza identificadores de red personalizados como «base-sepolia» y «base». La versión v2 adopta CAIP-2 (Propuesta de mejora independiente de la cadena 2) y el formato es «espacio de nombres: referencia».Esto le permite admitir cualquier blockchain, incluso sistemas de pago que no sean blockchain.
Reconstrucción de la demanda de pago
La versión v1 tiene metadatos de recursos duplicados en cada opción de pago. Si el servidor acepta tres tokens, repite la URL, la descripción y el tipo de contenido tres veces.La versión v2 lo extrae en un objeto de recurso compartido, lo que reduce el tamaño del mensaje y elimina inconsistencias.
Expandir
La versión v2 introduce un sistema de extensión formal para funcionalidad opcional que opera independientemente del mecanismo de pago principal.Cada extensión tiene un objeto de información que contiene datos específicos de la extensión y un objeto de esquema que define la estructura mediante el esquema JSON.
Opciones de pago explícitas
La versión v1 utiliza heurísticas de coincidencia de campos para determinar qué opción de pago seleccionó el cliente.La versión v2 aclara el proceso de selección con un campo «aceptado» que contiene todos los requisitos de pago seleccionados.
Actualización de transferencia HTTP
Cumple con el estándar RFC 6648
El IETF desaprobó el prefijo «X-» para los encabezados HTTP porque los encabezados experimentales tienden a convertirse en estándares de facto, pero siempre están marcados como experimentales. La versión v2 elimina estos prefijos y mueve el requisito de pago del cuerpo de la respuesta al encabezado.¿Por qué pasar al encabezado?La separación de los metadatos del protocolo del contenido de la aplicación permite a los servidores devolver muros de pago HTML personalizados a los navegadores manteniendo al mismo tiempo los requisitos de pago legibles por máquina en el encabezado.Esto mejora la compatibilidad del middleware y la integración del marco.
Refactorización del SDK
De la codificación rígida a la modularidad
La versión v1 del SDK incorpora lógica específica de blockchain en cadenas anidadas if/else. Agregar una nueva cadena de bloques requiere modificar los archivos principales y lanzar una nueva versión del SDK.La versión v2 presenta tres interfaces para lograr soporte blockchain plug-and-play.
Registro de patrón de constructor
Los desarrolladores registran implementaciones de blockchain utilizando comodines CAIP-2.El SDK enruta las operaciones a la implementación correcta según el modo de red. Coincidencia de patrones comodín:eip155:*Coincide con todas las cadenas EVM •solana:*Coincide con todas las redes Solana• eip155:8453Se refiere específicamente a la red principal base.
Motor de estrategia basado en Lambda
El tipo de billetera y el esquema de pago están codificados en v1.La versión v2 introduce funciones de políticas componibles para la autorización de pagos en tiempo de ejecución.
sistema de gancho
La versión v1 ejecuta la lógica empresarial después de la verificación y antes de la liquidación.Si la liquidación falla, el servidor ha realizado una operación irreversible (transferencia de archivos, llamada API, escritura de base de datos).La versión v2 presenta seis ganchos de ciclo de vida.
Configuración
La versión v2 del middleware admite la configuración basada en rutas y proporciona funciones de devolución de llamada para decisiones en tiempo de ejecución.
Facilitador Amejora de PIFunción
Aviso de capacidad
El punto final /support ahora anuncia tres características clave: tipos de pago admitidos agrupados por versión de protocolo, direcciones de firma para operaciones de liquidación y extensiones implementadas.
descubrimiento automático
Las extensiones de descubrimiento permiten que los servicios expongan metadatos estructurados para la indexación automática.FacilitadorLos puntos finales que admiten el protocolo x402 se pueden eliminar para mantener un catálogo de precios actualizado sin envío manual.
Estrategia de migración
La versión v2 mantiene la compatibilidad con versiones anteriores mediante el aislamiento del espacio de nombres.facilitadory los servidores pueden admitir ambas versiones simultáneamente.El cliente especifica una preferencia de versión a través del campo x402Version y la implementación responde con una versión de protocolo coincidente.
jakiro
