La zkAPI de Ethereum oculta quién paga por la IA, pero el modelo sigue viendo el prompt

La Fundación Ethereum y Open Anonymity Project lanzaron zkAPI en la red principal de Ethereum el 1 de octubre. Un usuario puede depositar créditos y probar que una solicitud posterior a una API de IA está pagada sin dar al servidor de pagos una identidad ni al proveedor del modelo la dirección de financiación. El proveedor aún recibe el prompt. Esa separación es útil, pero es una afirmación de privacidad más limitada que una conversación anónima con un modelo.

Elanuncio técnico de la Fundación Ethereum es inusualmente explícito sobre el límite. La prueba oculta qué nota paga por el uso, mientras que el proveedor opera el modelo y ve la solicitud. También nombra los metadatos de red y el contenido del prompt como fuentes restantes de correlación. Eso importa porque la frase pagos de IA privados puede fácilmente escucharse como uso de IA privado.

El proyecto está activo, según la Fundación, con un repositorio público en GitHub, una bóveda en la red principal que contiene créditos USDC y una interfaz de chat de demostración enlazada desde su anuncio. El despliegue activo establece que hay código y un contrato para inspeccionar. No establece la adopción por parte de los usuarios, el alcance de una auditoría de seguridad, el anonimato en cada configuración de cliente ni la protección contra un proveedor que reconoce la escritura y los documentos de un usuario.

Un depósito reemplaza un rastro de facturas de API

La mayoría de las API de IA comerciales conectan una clave a una cuenta y un método de pago. El proveedor puede asociar solicitudes con una identidad de facturación, incluso si un usuario nunca firma el prompt con un nombre. zkAPI introduce una bóveda financiada y una nota privada. Un usuario deposita activos compatibles como USDC en un contrato; el software en la máquina del usuario luego produce una prueba de conocimiento cero de que una nota financiada válida puede pagar por un uso limitado sin revelar cuál es la nota.

El servidor de pagos verifica la prueba y emite una clave de API de corta duración y con límite en dólares. En el modo directo con clave de tiempo de ejecución descrito por la Fundación, los prompts van desde el dispositivo del usuario al proveedor de IA con esa clave. Después de la sesión, un recibo firmado registra el uso medido, y el saldo privado se carga por la cantidad utilizada en lugar de simplemente el límite reservado. Una prueba puede cubrir una sesión de múltiples solicitudes.

Esto evita poner cada solicitud de modelo en Ethereum. La cadena ve depósitos, cierres y retiros de la bóveda, mientras que el servidor verifica las pruebas de gasto fuera de cadena. El proveedor del modelo ve el texto y el tráfico de la API. El servidor de pagos ve evidencia de que la sesión está financiada y el cargo total, pero en el modo directo no recibe el prompt. Estas son afirmaciones sobre la arquitectura descrita, no prueba de que los registros o la configuración de red de un despliegue particular nunca puedan correlacionar usuarios.

Hay un modo proxy más simple. En él, el servidor zkAPI retransmite la solicitud del usuario al proveedor del modelo. Ese servidor puede ver el tráfico, según la Fundación. Una persona que decide entre modos debería preguntar a qué parte confía el contenido y cuál solo necesita validar una prueba de pago. Una interfaz local que parece idéntica podría enrutar las solicitudes de manera diferente bajo el capó.

El pagaré demuestra valor sin nombrar a su depositante

La construcción criptográfica utiliza compromisos en un árbol de Merkle. Una prueba afirma que el pagaré del usuario está entre los pagarés financiados válidos sin identificar su hoja. Un nullifier, derivado de un secreto del pagaré, impide que el mismo saldo se gaste dos veces. La Fundación nombra pruebas Groth16 sobre BN254 y hashes Poseidon, con un árbol de 32 niveles. Estos detalles importan a los implementadores, pero el principio financiero es más simple: verificar la pertenencia y la autoridad restante para gastar sin publicar la cuenta que aportó el crédito.

El usuario no obtiene uso gratuito ocultando una identidad. El servidor debe comprobar la prueba de gasto y reservar un límite antes de emitir la clave temporal. El proveedor mide el uso. El recibo liquida el importe real después de que expire la clave. Si se reserva un límite de $10 y se consumen $3 de servicio, el sistema está pensado para cobrar $3, no $10. Ese ejemplo ilustra la lógica de reserva, no un precio publicado ni un mínimo garantizado. El saldo restante permanece en el pagaré privado sujeto a las reglas de la implementación.

El nullifier aborda un fallo específico: un intento de gastar un pagaré dos veces. No prueba que el modelo de IA respondiera con precisión, no preserva la confidencialidad del prompt ni impide que el proveedor registre solicitudes. Una prueba de conocimiento cero es una afirmación sobre la validez de una transacción bajo un circuito definido. Sus garantías no se extienden automáticamente a otros datos que se mueven junto con la transacción.

La ruta de salida del contrato también importa. La Fundación dice que un usuario puede cerrar el saldo de la bóveda y retirar onchain incluso si los servidores de zkAPI desaparecen. Esto evita que el servidor de pagos sea la única vía para recuperar fondos. No hace invisibles las salidas: Ethereum registra las transacciones relevantes. La capacidad del usuario de salir depende del contrato y de la posesión del secreto necesario, y un usuario prudente debería inspeccionar las direcciones de despliegue, los permisos y cualquier revisión independiente antes de asignar un valor elevado al mecanismo.

El proveedor puede reconocer lo que la prueba no puede revelar

La prueba de pago puede ocultar una fuente de financiación mientras el cuerpo de la solicitud contiene el nombre de una persona, su empleador, su historial médico o código propietario. Un proveedor de modelo que lee el prompt puede vincularlo a sesiones anteriores usando frases repetidas, archivos subidos, historial de conversación o hechos altamente distintivos. No se necesita ningún vínculo de cartera. Un prompt sobre un producto no publicado con el mismo nombre de proyecto interno en tres sesiones es su propio identificador.

Los metadatos de red proporcionan otra vía. En el modo de clave en tiempo de ejecución, el proveedor puede ver la dirección IP desde la que se conecta el dispositivo. En el modo proxy, el intermediario puede ver el tráfico y potencialmente su información de red de origen. La Fundación dice explícitamente que una IP estable y una sincronización correlacionada pueden debilitar la privacidad, y sugiere herramientas de anonimato de red para los usuarios que buscan una protección más fuerte. Una VPN o Tor pueden alterar la ruta de red, pero ninguna elimina un nombre escrito en el prompt.

Existe una prueba de privacidad de tres capas. La privacidad de pago pregunta si una factura puede vincularse a un pagaré de financiación o a una persona. La privacidad de red pregunta si el servicio puede identificar una conexión por IP, sincronización o características del dispositivo. La privacidad de contenido pregunta si cualquiera que opere el modelo puede leer el prompt. zkAPI está diseñado principalmente para la primera capa. Puede reducir un vínculo a nivel de cuenta entre el registro de uso del proveedor del modelo y la fuente de pago del usuario. No entrega las otras dos por sí solo.

Esto no es un defecto oculto en la letra pequeña. El propio anuncio del proyecto dice que el proveedor ve las solicitudes. La descripción honesta es más fuerte que un eslogan de anonimato expansivo porque indica a los usuarios dónde centrar precauciones adicionales. Una persona que utiliza el servicio para hacer preguntas genéricas puede obtener una desvinculación de pago sustancial. Una persona que pega un contrato firmado y un nombre completo ha revelado su identidad en el contenido independientemente de la ruta de pago.

El conjunto de anonimato puede ser pequeño incluso con pruebas sólidas

El conocimiento cero puede ocultar cuál de varios pagarés pagó, pero la multitud práctica importa. Si solo un usuario financia una bóveda en una ventana temporal estrecha con un importe de depósito inusual, y a una sesión le sigue un retiro igualmente distintivo, un observador puede formar una correlación plausible a partir del momento y los importes públicos. La prueba puede seguir siendo criptográficamente válida e irrompible. La inferencia a partir de información externa es un ataque separado.

El árbol de 32 niveles es un parámetro de capacidad en el diseño, no evidencia de que miles de millones de usuarios distintos estén mezclando sus créditos hoy. Un servicio recién lanzado puede tener un conjunto pequeño de pagarés financiados. Para evaluar el anonimato en la práctica, se querrían recuentos fechados de depósitos, pagarés activos distintos y patrones de retiro, con una agregación que tenga en cuenta la privacidad. Un repositorio o el tamaño teórico del árbol no proporcionan esas cifras.

Supongamos que diez notas son elegibles para una sesión y que hechos públicos descartan nueve de ellas. La prueba matemática aún puede ocultar perfectamente su testigo, mientras que la información circundante apunta a la décima. Este ejemplo de juguete explica por qué el tamaño y la diversidad del conjunto plausible importan más que el número bruto de transacciones en la bóveda. La estandarización de montos, la actividad retrasada y el uso regular pueden ayudar, pero el comportamiento del usuario y el diseño del servicio determinan qué está disponible para correlacionar.

Existe un segundo tipo de conjunto en el proveedor de IA: el grupo de solicitudes que comparten una clave de corta duración. La clave puede vincular solicitudes dentro de su sesión limitada incluso si no puede identificar el depósito. Eso es inherente a la medición de una sesión. Si el cliente envía repetidamente los mismos documentos en sesiones posteriores, el proveedor también puede vincularlos entre claves. Ocultar la cuenta de facturación es valioso, pero no obliga al proveedor a olvidar lo que ha leído.

Dibuja los registros de una sola sesión sin asumir que alguien hace trampa. Ethereum registra la transacción de depósito y su dirección de financiación. El dispositivo del usuario conserva el secreto de la nota y envía una prueba al servidor de pagos. El servidor registra la validez de la prueba, un nullifier y un evento de emisión para una clave limitada. El proveedor del modelo registra esa clave, las solicitudes y el uso que facturó. El recibo firmado vincula la clave a un total medido. Al cierre, el contrato puede registrar una salida. Cada parte tiene un libro mayor parcial.

La propiedad de privacidad prevista es que ningún libro mayor de una sola parte honesta vincule directamente la dirección de financiación con los prompts del proveedor. Una coalición, una filtración de datos o un observador externo con marcas de tiempo pueden tener más información. Si un usuario deposita un monto inusual e inmediatamente envía una única solicitud inusual, correlacionar eventos podría volverse más fácil. Si un proveedor recibe un documento que identifica al usuario, puede saber quién preguntó a pesar de nunca ver la dirección de la bóveda. Este es un problema de composición, no una prueba de conocimiento cero fallida.

El ejercicio del libro mayor también expone la importancia de los tiempos de vida de las claves. Una credencial de sesión agrupa deliberadamente todas las solicitudes que autoriza para que un proveedor pueda medirlas. Un límite de $50 puede permitir muchos prompts bajo una sola clave. Límites más bajos y sesiones más cortas pueden reducir cuánto contenido se vincula dentro de una credencial, pero requieren pruebas más frecuentes y pueden añadir latencia o gasto. No existe una configuración universalmente privada; el usuario y el proveedor eligen entre conveniencia, costo y capacidad de vinculación.

Un modelo de amenaza público debería nombrar exactamente qué registros se conservan y durante cuánto tiempo. Debería decir si el servidor registra las direcciones IP de origen durante el envío de la prueba, si almacena los nullifiers indefinidamente y si el proveedor puede asociar los identificadores de recibo con el contenido de la solicitud después de la liquidación. Eliminar un nombre de facturación de una base de datos es útil. Es insuficiente si un identificador de dispositivo persistente recrea silenciosamente el mismo perfil.

Un recibo de uso firmado traslada la confianza a la medición

El proveedor o el servidor necesita una forma de cobrar por el trabajo realmente realizado. El diseño utiliza un recibo firmado asociado con la clave de corta duración y su uso. Esto traslada una cuestión comercial central a la exactitud de la medición. Si un proveedor cuenta en exceso tokens, solicitudes o tiempo, una prueba de pago válida no puede corregir la factura subyacente. La firma hace que un total afirmado sea difícil de reescribir después; no establece que el uso afirmado fuera justo según la tarifa del proveedor.

Un cliente debería preguntar qué unidad se cobra, quién firma el recibo, cómo se libera la reserva no utilizada y qué sucede cuando una solicitud falla a mitad de camino. Estas son preguntas de facturación ordinarias con un disfraz criptográfico inusual. Un límite limita el tamaño de un cargo inesperado en una sesión, pero muchas sesiones pequeñas aún pueden acumular un costo sustancial. Los límites de velocidad y las facturas pueden necesitar un proceso de disputa que preserve la privacidad.

La compensación es operativa. Las cuentas de API tradicionales simplifican el soporte al cliente, los reembolsos y la investigación de abusos porque un proveedor puede identificar al comprador. zkAPI elimina una identidad de facturación persistente de la ruta de pago prevista. Los proveedores aún pueden necesitar controles de abuso, cribado de sanciones cuando corresponda y aplicación del uso. La Fundación dice que los precios y los límites de velocidad pueden permanecer, pero las integraciones reales mostrarán cómo los servicios equilibran los pagos sin cuenta con sus obligaciones y controles de fraude.

Una prueba práctica es una sesión deliberadamente interrumpida. El cliente obtiene una clave limitada, realiza varias solicitudes, pierde el acceso a la red y luego se reconecta. ¿El recibo refleja solo el uso entregado? ¿Puede un usuario auditar el monto medido localmente sin enviar el prompt al servidor de pagos? Si el servidor desaparece, ¿puede el usuario recuperar el saldo no utilizado a través del contrato como se anunció? Estas pruebas van más allá de si una prueba se verifica para determinar si el producto preserva la separación prometida en caso de fallo.

El contrato en cadena es una vía de escape, no un escudo de privacidad

El contrato de la bóveda puede verificar pruebas para operaciones de depósito, cierre y escape, según la Fundación. Una ruta de salida en cadena importa porque el cierre de un proveedor no debería dejar los fondos de los usuarios atrapados en una base de datos de un operador. El contrato reemplaza parte de la confianza institucional con riesgo de contrato inteligente. Un error en la verificación de pruebas, la contabilidad o la lógica de retiro podría afectar los fondos a pesar de un concepto de privacidad sólido. Una dirección activa es evidencia de despliegue, no un certificado de auditoría.

Los depósitos y retiros públicos también tienen un costo de privacidad. Alguien que conoce la dirección de financiamiento de un usuario puede observar que interactuó con la bóveda. Puede que no vea por qué sesión de API pagó, pero puede ver la participación y los montos. Si el mismo usuario retira rápidamente una cantidad inusual a una dirección ya asociada con él, parte del anonimato circundante puede reducirse. La nota privada rompe un vínculo de facturación determinista; no borra la transacción de financiamiento pública.

El proyecto tiene raíces en un diseño de Ethereum Research para créditos de API de conocimiento cero, que la Fundación identifica como trabajo de Davide Crapis y Vitalik Buterin. Una propuesta de investigación y un sistema de producción responden a preguntas diferentes. La primera establece una construcción; el segundo debe manejar el almacenamiento de claves, el comportamiento del front-end, las interrupciones, las disputas de recibos, las actualizaciones y adversarios reales. El lanzamiento del 1 de octubre traslada la idea a un despliegue testeable, y ese es el gancho fresco relevante.

Los esfuerzos de privacidad más amplios de Ethereum no son el mismo producto. La cobertura de Crypto.news sobre un diseño de privacidad nativo propuesto se refiere a un cambio de protocolo preliminar, mientras que zkAPI es una aplicación que funciona ahora. El reciente lanzamiento de la billetera zk.money se refiere a transferencias privadas en otro entorno. Ninguno de los dos debe citarse como evidencia de que un prompt de IA enviado a través de zkAPI esté oculto para su proveedor de modelo.

Las afirmaciones de privacidad deberían sobrevivir a una prueba reproducible

Un revisor independiente podría crear dos notas financiadas desde direcciones no relacionadas, emitir sesiones cortas con el mismo proveedor de modelo e inspeccionar cada paquete y registro visible para el cliente, el servidor de pagos y el proveedor. El revisor debería probar los modos directo y proxy por separado. Si el servidor de pagos en modo directo recibe un prompt, eso contradice la separación descrita. Si el proveedor recibe una dirección de depósito o un identificador de cuenta de facturación duradero, la desvinculación prevista ha fallado en la capa de integración incluso si el circuito de prueba es sólido.

La prueba más difícil es estadística. Ejecute muchas sesiones con montos y tiempos variados, luego pregunte si una parte que solo tiene datos públicos de la cadena y registros del servidor puede correlacionar el financiamiento y el uso mejor que el azar. El punto de referencia depende del conjunto de anonimato real y de qué datos auxiliares tenga el adversario. Una demostración exitosa en un pequeño laboratorio no establece privacidad con una base de usuarios de producción diminuta, pero crea un método para medir si los despliegues mejoran con el tiempo.

La prueba de contenido es directa y aleccionadora. Envíe el mismo documento distintivo bajo dos claves de sesión nuevas. Si un proveedor puede reconocerlo en ambas, la desvinculación de pago no le ha dado al usuario desvinculación de conversación. Una afirmación sobre el pago debe evaluarse mediante las dos primeras pruebas; una afirmación sobre el uso anónimo de IA también debe superar la tercera. Publicar el modo, el modelo de amenaza y los resultados permitiría a los usuarios elegir la herramienta adecuada para su preocupación real.

El caso más sólido es desvincular la facturación del contenido útil

Hay muchas razones legítimas para hacerle a un proveedor de IA una pregunta sensible sin construir un expediente de uso permanente vinculado a una cuenta. Un periodista que prueba un documento público, un investigador que explora una hipótesis controvertida o un desarrollador que usa una API dentro de un agente pueden querer que el proveedor vea la solicitud actual mientras se corta la relación de facturación duradera. El diseño de zkAPI aborda esa necesidad más limitada. También permite que una máquina pague por servicios medidos sin gestionar una cuenta personal de larga duración para cada solicitud.

El argumento en contra de exagerar las afirmaciones es igualmente sólido. Los proveedores aún ven los prompts, y algunos prompts necesariamente revelan identidad. Una empresa con estrictos requisitos de confidencialidad puede necesitar controles contractuales, modelos locales o computación confidencial además de la desvinculación de pagos. Algunos usuarios pueden preferir una cuenta ordinaria con soporte y reembolsos establecidos en lugar de una capa de pago criptográfica cuyos mecanismos de disputa aún son inmaduros. La elección depende del modelo de amenaza real.

La hoja de ruta de privacidad de Ethereum discutida por crypto.news enmarca la privacidad como un objetivo más amplio. Una hoja de ruta no confiere sus protecciones futuras a esta aplicación hoy. Un usuario de IA debe juzgar la ruta activa del cliente y del proveedor que realmente maneja un prompt.

Crypto.news explicó la mecánica más limitada de las pruebas de conocimiento cero en una introducción aparte. Una prueba revela un hecho definido sin revelar un testigo; no es una capa de invisibilidad de propósito general. Su entrevista sobre infraestructura de Ethereum centrada en la privacidad subraya cómo diferentes productos protegen diferentes datos. La pregunta útil para zkAPI es qué parte ve qué registro en cada paso, no si el proyecto califica para la palabra amplia privado.

La mejor evidencia contraria a una lectura escéptica sería un uso medido sin un vínculo de identidad persistente, etiquetas de modo claras, revisión de seguridad independiente y un modelo de amenazas publicado que cubra IP, telemetría del navegador y recibos. La mejor evidencia contraria a una afirmación de marketing expansiva ya está en la publicación de la Fundación: el proveedor ve el prompt. Ambas observaciones pueden ser verdaderas a la vez.

La Fundación enumera los pagos de API de máquina a máquina como una posible aplicación. Un agente autónomo puede enviar cientos de llamadas usando una nota financiada o muchas sesiones cortas. Si sus tareas llevan registros de clientes, el proveedor del modelo puede aprender sobre esos clientes incluso mientras la fuente de pago del agente permanece privada. El beneficio de privacidad pertenece al vínculo de facturación; no debería transferirse a cada sujeto nombrado en una solicitud.

Un agente también necesita controles de presupuesto. Un límite por clave limita una sesión, pero un bucle puede obtener claves repetidas hasta que la nota se agote a menos que el cliente aplique una política de gasto más amplia. El operador debe definir un límite diario o a nivel de tarea, alertas y un control de pausa separado de la prueba criptográfica. La prueba verifica crédito autorizado, no si la llamada del agente era necesaria o económica.

Cuando varios agentes comparten un fondo de créditos, la contabilidad interna puede convertirse en el sistema de facturación oculto. El operador puede necesitar asignar cargos a equipos o clientes sin exportar sus identidades al proveedor de API. Eso se puede hacer con un libro mayor local, pero crea otro conjunto de datos sensibles que proteger. El paso de la facturación por cuenta a la facturación por nota no abole la conciliación; la reubica.

Finalmente, un agente puede revelarse a través de su comportamiento. Llamadas repetidas con el mismo horario, los mismos encabezados de herramientas y las mismas frases específicas de tareas pueden hacer que claves separadas de corta duración sean fáciles de agrupar. Ocultar una nota de financiación en cadena es útil contra la vigilancia de pagos. No es una defensa contra una huella de comportamiento que el agente envía con cada solicitud.

Un despliegue aún necesita una auditoría del modelo de amenazas

A partir del 2 de octubre, la Fundación dice que el código, el servidor, el cliente y la bóveda están activos. La publicación enlaza un contrato en la red principal y un repositorio. No publica en el anuncio un recuento definitivo de usuarios, un valor total auditado, todas las integraciones de terceros ni una garantía de que cada configuración de cliente use el modo directo de clave de tiempo de ejecución. Esta función no afirma una brecha o mal comportamiento por parte de un proveedor nombrado. Identifica la información que cada parte debe recibir y las filtraciones adicionales que los autores del proyecto reconocen.

Una evaluación externa debería inspeccionar los valores predeterminados del cliente y las conexiones salientes. ¿La demostración del navegador envía telemetría a dominios no relacionados? ¿El cliente local retiene claves o registros de prompts? ¿Puede el servidor de pagos unir las marcas de tiempo de emisión con las direcciones de red? ¿Los recibos son vinculables entre sesiones? ¿Cómo se gobiernan las actualizaciones de circuitos y contratos? Una prueba puede ser matemáticamente sólida mientras una interfaz de usuario entrega accidentalmente la identidad que debía separar.

La misma evaluación debería probar la vista de un proveedor de IA. Verá el contenido que procesa y una credencial de sesión. Puede recopilar metadatos del dispositivo o de la red según la ruta de la solicitud. La política de retención de datos de un proveedor y cualquier término contractual siguen siendo centrales. La capa de pago puede reducir una fuente de información identificativa sin restringir todas las demás.

zkAPI logra un avance real si impide de forma fiable que un proveedor de modelos vincule solicitudes útiles a una cuenta de facturación, al tiempo que preserva la capacidad del usuario de recuperar fondos. Decepcionará a cualquiera que espere una conversación privada simplemente porque el pago se demostró en conocimiento cero. Las dos afirmaciones deben juzgarse por separado.

Qué observar

• Etiquetado de modo: Compruebe si cada cliente hace visible el enrutamiento directo por clave de tiempo de ejecución o por proxy antes de que un usuario envíe prompts.
• Actividad en la mainnet: Busque recuentos fechados de notas financiadas y uso, informados sin comprometer el anonimato de los usuarios.
• Revisiones de seguridad: Lea el alcance de las evaluaciones independientes que cubren las salidas de contratos, los circuitos de prueba, el almacenamiento del cliente y la liquidación de recibos.
• Controles de metadatos: Pruebe el manejo de IP, la telemetría, la vida útil de las claves y la retención del proveedor en integraciones reales.
• Disputas de facturación: Compruebe cómo se gestionan las solicitudes fallidas, la liberación de límites y los recibos impugnados sin forzar la divulgación de identidad.

Preguntas frecuentes