Vitalik Buterin acaba de publicar una propuesta de investigación que elude la pregunta que todo el mundo sigue planteándose: ¿pueden las cadenas de bloques ejecutar modelos de IA?
En cambio, la investigación afirma que Ethereum es la capa de liquidación que preserva la privacidad para el uso medido de IA y API. La publicación, en coautoría con Davide Crapis en Ethereum Research, sostiene que la verdadera oportunidad no es poner los LLM en cadena.
La verdadera oportunidad radica en construir la infraestructura que permita a los agentes y usuarios pagar miles de llamadas API sin comprometer la identidad ni crear rastros de vigilancia a través de los datos de facturación.
El momento es crítico porque la IA agente está pasando de las demostraciones a las hojas de ruta empresariales. Gartner pronostica que el 40% de las aplicaciones empresariales incluirán agentes de IA para tareas específicas para fines de 2026, frente a menos del 5% en 2025.
Ese cambio implica un mundo en el que el software genera de forma autónoma volúmenes masivos de llamadas API, lo que hace que la facturación se centre en la infraestructura estratégica en lugar de en las tuberías administrativas.
Los sistemas de medición actuales obligan a elegir entre la facturación de identidad Web2, que se basa en claves API y tarjetas de crédito y filtra datos de perfiles, y modelos de pago por llamada en cadena que son demasiado lentos, demasiado costosos y vinculan la actividad a través de gráficos de transacciones transparentes.
La propuesta introduce créditos de uso de API de ZK, una primitiva anti-abuso y de pago basada en anuladores limitadores de tasas.
RLN es un dispositivo de conocimiento cero diseñado para prevenir el spam en sistemas anónimos, y la investigación lo reutiliza para el acceso medido a los servicios.
El flujo se desarrolla de la siguiente manera: los usuarios depositan fondos una vez en un contrato inteligente y su compromiso se agrega a un árbol Merkle en cadena.
Cada solicitud de API incluye una prueba de conocimiento cero que demuestra que el usuario es un depositante válido con crédito suficiente para el índice solicitado.
Si un usuario intenta reutilizar un índice de boletos, gastando el doble de su asignación, RLN permite que el sistema recupere su secreto y reduzca su apuesta como penalización económica.
La publicación incluye ejemplos concretos. Un usuario deposita 100 USDC y realiza 500 consultas LLM alojadas. Otro deposita 10 USDC por 10,000 llamadas RPC de Ethereum.
La arquitectura está diseñada explícitamente para “muchas llamadas por depósito”, lo que significa que la actividad en la cadena aumenta con la cantidad de cuentas y la frecuencia de liquidación en lugar del volumen de inferencia bruta.
El soporte de costo variable agrega flexibilidad: los usuarios pagan por adelantado un costo máximo por llamada, los servidores devuelven boletos de reembolso firmados por los montos no utilizados y los usuarios acumulan reembolsos de forma privada para desbloquear más llamadas sin depósitos adicionales.
La infraestructura ya existe
La propuesta llega cuando el sustrato de pago para créditos de uso ya existe a escala.
Las monedas estables tienen una capitalización de mercado circulante de aproximadamente $ 307,6 mil millones, según DefiLlama, lo que indica que la capa de dólares en cadena es lo suficientemente líquida para respaldar la facturación basada en depósitos para servicios de alta frecuencia.
La pila de escalamiento de Ethereum ha madurado hasta el punto en que los paquetes acumulativos procesan mucha más actividad que la capa 1, con L2Beat mostrando un factor de escala de aproximadamente 100 veces, con paquetes acumulativos que manejan miles de operaciones por segundo en comparación con decenas en la red principal de Ethereum.
Las tarifas promedio de transacción de Ethereum midieron recientemente alrededor de $0,21 el 7 de febrero, lo que sugiere que los flujos ocasionales de medición y liquidación en cadena son factibles sin costos prohibitivos.
El diseño evita explícitamente poner LLM en cadena. Ethereum compite en liquidación neutral, depósito en garantía programable y aplicación verificable, no en ciclos de TPU o velocidad de inferencia.
La arquitectura trata la inferencia como un servicio fuera de la cadena y la cadena de bloques como la capa que hace que el pago, la medición y la resolución de disputas sean creíbles, sin exigir a los usuarios que confíen en proveedores individuales o que revelen sus identidades.
Si los proveedores de servicios de IA aceptan depósitos y dependen de Ethereum o de contratos inteligentes de capa 2 para resolver recortes, reembolsos y disputas, Ethereum se convierte en la capa de cumplimiento para el comercio de IA.
El modelo es paralelo a cómo Ethereum se convirtió en la capa de liquidación para las monedas estables y DeFi, no al alojar la pila completa de aplicaciones en la cadena, sino al proporcionar un sustrato neutral donde los acuerdos económicos se aplican programáticamente.
Escenarios sin exageraciones
La huella en la cadena está limitada por la cadencia de liquidación, no por el volumen bruto de llamadas.
En un escenario de cuña criptonativa dirigido a RPC y API de infraestructura, supongamos que 250.000 usuarios avanzados o agentes adoptan créditos de uso.
Si cada uno realiza dos acciones en cadena por mes, un depósito o recarga más un retiro, eso genera aproximadamente 500.000 transacciones mensuales atribuibles al ferrocarril.
En un escenario de adopción de un proveedor de IA, imagine que un millón de usuarios emplean créditos para preservar la privacidad en servicios LLM alojados, pero aun así realizan solo de una a tres acciones en cadena mensualmente.
Eso implica entre un millón y tres millones de transacciones por mes vinculadas a vías comerciales de IA, probablemente concentradas en la capa 2, donde la ejecución es más barata.
Los escenarios de agentes empresariales aumentan el tamaño de los depósitos, lo que aumenta los riesgos para una aplicación creíble de la aplicación de la ley y hace que los mecanismos de reducción tengan más consecuencias.
El problema de los metadatos
La propuesta intenta hacer que los pagos no sean vinculables, pero el propio hilo de investigación destaca una debilidad potencial.
Un comentarista sostiene que incluso si los anuladores no son criptográficamente vinculables, los servidores pueden correlacionar a los usuarios a través de metadatos basados en inferencias, como patrones de tiempo, recuentos de tokens y aciertos de caché.
La crítica propone precios divididos, con clases fijas de insumos y productos, para reducir las fugas. Esa tensión entre la privacidad criptográfica y los metadatos de comportamiento es fundamental para determinar si el diseño realmente cumple con sus objetivos de anonimato.
La realidad de la implementación presenta otro obstáculo. La propuesta utiliza RLN como primitivo, pero la página del proyecto Exploraciones de privacidad y escalamiento señala que RLN está inactivo o ha expirado.
La producción de créditos de uso de API de ZK probablemente requiera mantener bifurcaciones o implementar nuevas soluciones en lugar de depender de herramientas existentes.
Los puntos de referencia de RLNJS informan aproximadamente 800 milisegundos para la generación de pruebas y 130 milisegundos para la verificación en una Mac M2, lo que proporciona una verificación temprana del rendimiento, pero deja preguntas abiertas sobre las limitaciones móviles y los circuitos de producción a escala.
La propuesta también supone que los proveedores integrarán el flujo de depósito y prueba, aceptarán acuerdos con monedas estables y adoptarán Ethereum o contratos de capa 2 para la resolución de disputas.
Ése es un problema de coordinación, no sólo técnico. Los proveedores de API Web2 cuentan con una infraestructura de facturación existente y claridad regulatoria en torno a las transacciones vinculadas a la identidad.
Convencerlos de adoptar una alternativa basada en ZK requiere demostrar una ventaja de costos convincente o un segmento de mercado diferenciado en el que la facturación que preserva la privacidad desbloquea ingresos que de otro modo no podrían capturar.
| Modelo | como se factura | Lo que gotea/se rompe | a quien le conviene |
|---|---|---|---|
| Facturación de identidad Web2 (claves API + tarjetas) | Facturación basada en cuenta vinculada a la identidad (clave API + método de pago); El proveedor mide las solicitudes y facturas de forma centralizada. | Fugas: vinculación de identidad + seguimiento de perfiles entre solicitudes. Descansos: normas de seudonimato/autocustodia. Riesgo: control centralizado (suspensión/censura, confianza en un único proveedor) | Proveedores convencionales de SaaS/API; Empresas que priorizan el cumplimiento, la simplicidad y las vías de facturación existentes. |
| Pago por llamada en cadena | Cada solicitud (o lote) paga en cadena por llamada a través de transacciones/contratos inteligentes | Descansos: Costo/latencia para llamadas de alta frecuencia. Fugas: vinculabilidad en cadena (el gráfico de transacciones une el uso). Fricción: Gastos generales de UX para txs repetidos | Servicios cripto nativos con baja frecuencia de llamadas; Casos en los que la transparencia/auditabilidad es más importante que la privacidad/rendimiento. |
| Créditos de uso de API de ZK (depósito una vez, muchas llamadas) | El usuario deposita una vez; cada solicitud lleva un comprobante de membresía ZK + crédito restante; cortes para doble uso; Boletos de reembolso opcionales por costo variable. | Riesgo: correlación de metadatos (los patrones de tiempo/token pueden volver a vincularse). Carga: integración de proveedores + coordinación. Madurez: Complejidad de herramientas/operaciones ZK, mantenimiento de circuitos | API de alta frecuencia (LLM, RPC, datos) donde la privacidad es un punto de venta; cadenas de herramientas de agentes; usuarios que necesitan medición sin vigilancia basada en identidad |
Lo que esto significa para Ethereum
Si el diseño gana fuerza, la propuesta de valor de Ethereum se desplaza aún más hacia servir como una capa de aplicación neutral para el comercio digital en lugar de una plataforma informática de propósito general.
La propuesta trata a blockchain como el sustrato de asentamiento donde las reglas económicas se hacen cumplir de manera creíble, no el lugar donde se ejecutan las aplicaciones.
La velocidad de las monedas estables podría aumentar a medida que los depósitos fluyan hacia los contratos de crédito de uso, creando una nueva categoría de actividad económica en cadena distinta de la especulación DeFi o el comercio de NFT.
La utilización de la capa 2 podría aumentar a medida que los proveedores y usuarios resuelvan disputas, procesen reembolsos y manejen eventos de reducción en cadenas optimizadas para el rendimiento.
La pregunta es si surge un ecosistema paralelo en el que la facturación que preserva la privacidad se convierta en un requisito previo para ciertos segmentos de usuarios.
Las empresas preocupadas por la fuga de datos a través de los registros de facturación, los desarrolladores que crean cadenas de herramientas para agentes que requieren mediciones auditables sin vigilancia y los usuarios avanzados que valoran el acceso seudónimo a servicios de alta frecuencia son posibles primeros usuarios.
La oportunidad de Ethereum es servir como capa en la que se asientan los mercados de servicios de IA, sin exigir a los participantes que confíen en plataformas individuales o que sacrifiquen la privacidad en aras de la infraestructura de facturación.
La propuesta afirma que Ethereum puede hacer cumplir acuerdos de pago, resolver disputas y permitir el acceso medido sin vinculación de identidad de maneras que los sistemas tradicionales estructuralmente no pueden.
Que esa afirmación se mantenga depende de resolver el problema de correlación de metadatos, mantener implementaciones sólidas de ZK y convencer a los proveedores de que el mercado justifica el costo de integración que desbloquea.
