El sistema de IA de Solana que procesa “un millón de pagos por segundo” puede dejar a los vendedores sin cobrar incluso después de entregar

Un cliente que utiliza un canal de pago de Solana puede dejar de comprar servicios de IA antes de que el canal haya terminado de pagar por ellos. Si el operador se queda en silencio entre tanto, el cliente necesita una forma de recuperar el depósito restante, mientras que el comerciante necesita que su última factura llegue a la blockchain antes de que se cierre la ventana de recuperación.

Esa división de riesgo está detrás del anuncio del canal de pago de la Fundación Solana del 3 de septiembre, que reportó más de un millón de pagos por segundo a través de un proxy utilizando 100,000 billeteras únicas. El sistema permite a los agentes gastar hasta un límite prepagado a través de mensajes firmados, reduciendo la necesidad de una transacción blockchain separada por cada entrega.

El cliente financia el canal, el comerciante proporciona el servicio y el operador gestiona el proceso de pago. Cada uno financia una parte diferente del intervalo entre la autorización y la cobranza: depósitos del cliente, anticipos del operador de SOL para tarifas y alquiler de cuentas reembolsables, y servicios del comerciante que esperan el pago en la cadena.

Una advertencia en la plantilla de referencia vinculada a la Fundación hace que ese intervalo sea significativo: reiniciar su almacenamiento en memoria predeterminado puede hacer que se pierdan los vales aceptados pero aún no liquidados.

La plantilla de referencia informa sobre aproximadamente 1.09 millones de vales verificados por segundo en un host AVX-512 de 128 núcleos durante una ejecución sostenida de 10 minutos. Mide la puerta de pago que devuelve una respuesta sin un servicio ascendente. El resultado no mide un millón de finalizaciones de IA o transacciones de mainnet liquidadas de forma independiente cada segundo.

La puerta verifica una firma y avanza el registro de gasto acumulativo del canal fuera de la cadena. Ese arreglo permite que muchas pequeñas autorizaciones compartan el costo de las operaciones en la cadena. Pero la plantilla dice que un despliegue con almacenamiento de sesión duradero debe ser evaluado por separado porque una escritura duradera se convierte en parte de la ruta de solicitud.

Para un comerciante, esa distinción conecta la velocidad con la recuperabilidad. Un registro de aceptación rápido es útil para decidir si atender la siguiente solicitud. Se necesita un vale sobreviviente para respaldar la cobranza después de un reinicio. La cifra de rendimiento principal no establece el rendimiento de ambos juntos.

La Fundación dijo que los puntos finales de la API de Alibaba Cloud estaban activos en el lanzamiento, y el repositorio del programa enumera un despliegue en mainnet. La plantilla describe una carga de trabajo de prueba en lugar de una demanda comercial medida.

Un reembolso tiene dos rutas

Un canal de pago comienza con el cliente depositando un límite en un fideicomiso controlado por el programa en la cadena. El programa controla el saldo y hace cumplir sus reglas de pago. Las autorizaciones de gasto se acumulan contra ese depósito, y el cierre proporciona una ruta de regreso para la porción no registrada como liquidada.

Cuando ambas partes cooperan, el beneficiario designado, cuya firma autoriza el cierre final, puede presentar la liquidación final, sellar el canal y distribuir los fondos en una sola transacción. Sellar congela el total liquidado; la distribución transfiere los tokens. El pago al comerciante y el reembolso al cliente pueden llegar juntos sin una espera de gracia por cierre forzado.

El borrador de la sesión del 3 de septiembre, una especificación en progreso, describe la alternativa para un servidor no respondedor: el cliente solicita el cierre forzado y comienza un período de gracia. Recomienda 900 segundos, o 15 minutos, configurados por canal. El reloj comienza cuando la solicitud se registra en la cadena, no cuando el cliente se da cuenta por primera vez de un servicio detenido.

En una sesión de stablecoin patrocinada, el operador paga tarifas normales y alquiler. Un cliente que no posee SOL debe, por lo tanto, obtener SOL o un presentador que pague tarifas para iniciar la salida si ese operador no está disponible. La recuperación sin permisos permite que otra parte ayude; un presentador de reemplazo aún debe estar disponible y dispuesto a pagar las tarifas de transacción.

Después de que expire el período de gracia, cualquier persona puede enviar la instrucción de sellado. El cliente puede retirar el depósito menos el monto liquidado en la cadena. Alternativamente, cualquiera puede enviar una transacción de distribución que pague las acciones registradas del comerciante y el reembolso pendiente, utilizando la división de pagos comprometida en la transacción de apertura pública.

Estos caminos de recuperación suponen una red funcional y cuentas de tokens utilizables. La documentación del programa advierte que un depósito en garantía congelado por el emisor puede bloquear transferencias y que la distribución puede redirigir la parte de una cuenta de beneficiario o reembolso inutilizable al tesoro. Esos son límites separados sobre la recuperación, incluso cuando no se necesita la firma de un operador.

Para el cliente, el retraso práctico incluye la organización y ejecución de las transacciones, así como el temporizador configurado. La carga de tarifas depende de quién las envíe. La recomendación de 15 minutos describe una posible espera de protocolo; el costo de referencia por autorización mide una operación diferente.

La ventana de cobro del comerciante se estrecha

La posición del comerciante depende de qué registro ha alcanzado su factura. Un comprobante fuera de la cadena, un monto registrado como liquidado en la cadena y tokens ya distribuidos a un destinatario son tres cosas diferentes.

La implementación actual de liquidación permite que cualquiera presente un comprobante válido mientras el canal permanezca abierto. Una vez que el pagador solicita el cierre, esa instrucción ordinaria deja de aceptar nuevas liquidaciones. Durante el período de gracia, el comprobante final debe pasar a través del camino de liquidación y sellado autorizado por el beneficiario descrito en las reglas de la máquina de estados.

Durante el período de gracia, el beneficiario tiene tiempo para registrar su factura final. Un tercero capaz de pagar las tarifas de transacción no puede necesariamente reemplazar una firma de beneficiario faltante. Mantener una copia del comprobante solo ayuda si el camino de liquidación autorizado aún puede usarlo antes de la fecha límite.

Si el servicio entregado nunca alcanza el total final de liquidación en la cadena antes de la fecha límite, puede volverse incobrable desde ese canal. Una vez que el canal está sellado, el reembolso del cliente se calcula en función del total registrado, no de la reconstrucción posterior de un operador de lo que debería haberse facturado.

Los fondos del comerciante ya liquidados tienen un resultado diferente. Permanecen reservados para distribución después del sellado, sujetos a que las cuentas de tokens requeridas sean utilizables. El reembolso del cliente no incluye esas acciones registradas del comerciante. Por lo tanto, el fallo del operador no implica que cada saldo de comerciante no pagado desaparezca.

Una transacción de pago faltante puede completarse a través de una distribución sin permiso una vez que el canal esté sellado, con cuentas utilizables y una transacción financiada. Una liquidación final en la cadena faltante es más difícil: después de que comienza el cierre forzado, agregarla requiere un comprobante válido y el camino autorizado por el beneficiario antes de que expire el período de gracia.

El borrador de la sesión ofrece dos arreglos de firma. En modo cliente, el cliente controla la clave de firma del comprobante; este es el valor predeterminado cuando el desafío omite un modo. En modo operador, el cliente presenta una prueba de portador reutilizable y el operador firma los comprobantes de gasto.

El techo de la garantía limita la liquidación en cualquiera de los modos. La elección de firma determina quién crea la autorización de pago. El material publicado no establece un único período de gracia activo o modo de firma para cada canal de Alibaba o pay.sh, por lo que la exposición del cliente y del comerciante depende de los términos particulares de su canal.

El coste de financiación separado del operador

También hay un coste de financiación separado para el operador. La referencia de instrucción permite que el alquiler reembolsable de SOL de la cuenta del canal drenado permanezca comprometido hasta que haya pasado una ventana de apertura de 1,500 espacios. Ese temporizador se refiere a la desasignación de cuentas. Los reembolsos de tokens de clientes y los pagos de tokens de comerciantes proceden independientemente de ese temporizador de alquiler.

Para los operadores, los registros de vales duraderos y la liquidación oportuna abordan diferentes problemas: preservar la factura y hacer que sea reconocida en la cadena. La distribución completa el pago. Una liquidación más frecuente puede reducir el valor del servicio que espera entrar en el registro, mientras que una distribución más temprana reduce el tiempo que los ingresos registrados permanecen en custodia.

Para los clientes, los saldos comprometidos más pequeños reducen el dinero atado a una sesión, pero la capacidad de salir aún depende del temporizador del canal y del acceso a un presentador de transacciones financiado. Mientras tanto, el comerciante necesita un proceso de cobro que pueda sobrevivir a un reinicio y operar dentro de la ventana de cierre.

Los canales de pago de Solana mueven autorizaciones repetidas fuera de la carga de trabajo inmediata de la blockchain. La financiación sigue siendo visible en tres lugares: el depósito del cliente, el servicio del comerciante que espera ser cobrado y el adelanto de SOL del operador. Una medida útil de la economía del sistema es cuán confiablemente esos tres saldos llegan a sus propietarios previstos cuando el camino rápido se detiene.