3 publicaciones etiquetados con "cryptographic proofs"

Cada vez que consultas a ChatGPT, Claude o Gemini, estás confiando en una caja negra invisible. ¿La versión del modelo? Desconocida. ¿Los pesos exactos? Propietarios. ¿Si el resultado fue generado por el modelo que crees que estás usando, o por una variante actualizada silenciosamente? Imposible de verificar. Para los usuarios casuales que preguntan por recetas o curiosidades, esta opacidad es simplemente molesta. Para la toma de decisiones de IA de alto riesgo —algoritmos de trading financiero, diagnósticos médicos, análisis de contratos legales— es una crisis fundamental de confianza.

Judge de Gensyn, lanzado a finales de 2025 y entrando en producción en 2026, ofrece una alternativa radical: evaluación de IA criptográficamente verificable donde cada inferencia es reproducible hasta el último bit. En lugar de confiar en que OpenAI o Anthropic sirvan el modelo correcto, Judge permite que cualquiera verifique que un modelo de IA específico y acordado previamente se ejecutó de forma determinista contra entradas del mundo real, con pruebas criptográficas que garantizan que los resultados no pueden ser falsificados.

El avance técnico es Verde, el sistema de verificación de Gensyn que elimina el no determinismo de punto flotante, la pesadilla de la reproducibilidad de la IA. Al imponer una computación exacta a nivel de bits en todos los dispositivos, Verde asegura que ejecutar el mismo modelo en una NVIDIA A100 en Londres y en una AMD MI250 en Tokio produzca resultados idénticos, demostrables on-chain. Esto desbloquea la IA verificable para las finanzas descentralizadas, los agentes autónomos y cualquier aplicación donde la transparencia no sea opcional, sino existencial.

El problema de las API opacas: Confianza sin verificación​

La industria de la IA funciona con API. Los desarrolladores integran GPT-4 de OpenAI, Claude de Anthropic o Gemini de Google a través de endpoints REST, enviando prompts y recibiendo respuestas. Pero estas API son fundamentalmente opacas:

Incertidumbre de versión: Cuando llamas a gpt-4, ¿qué versión exacta estoy recibiendo? ¿GPT-4-0314? ¿GPT-4-0613? ¿Una variante actualizada silenciosamente? Los proveedores despliegan parches con frecuencia sin anuncios públicos, cambiando el comportamiento del modelo de la noche a la mañana.

Sin rastro de auditoría: Las respuestas de la API no incluyen ninguna prueba criptográfica de qué modelo las generó. Si OpenAI sirve una variante censurada o sesgada para geografías o clientes específicos, los usuarios no tienen forma de detectarlo.

Degradación silenciosa: Los proveedores pueden "lobotomizar" los modelos para reducir costos, degradando la calidad de la inferencia mientras mantienen el mismo contrato de API. Los usuarios informan que GPT-4 se vuelve "más tonto" con el tiempo, pero sin un control de versiones transparente, tales afirmaciones siguen siendo anecdóticas.

Resultados no deterministas: Incluso consultar el mismo modelo dos veces con entradas idénticas puede arrojar resultados diferentes debido a la configuración de temperatura, el procesamiento por lotes (batching) o los errores de redondeo de punto flotante a nivel de hardware. Esto hace que la auditoría sea imposible: ¿cómo se verifica la corrección cuando los resultados no son reproducibles?

Para aplicaciones casuales, estos problemas son inconvenientes. Para la toma de decisiones de alto riesgo, son bloqueadores. Considera lo siguiente:

Trading algorítmico: Un fondo de cobertura despliega un agente de IA que gestiona 50 millones de dólares en posiciones DeFi. El agente confía en GPT-4 para analizar el sentimiento del mercado a partir de publicaciones en X. Si el modelo se actualiza silenciosamente a mitad de la sesión de trading, las puntuaciones de sentimiento cambian de forma impredecible, provocando liquidaciones no deseadas. El fondo no tiene pruebas de que el modelo se comportó mal; los registros de OpenAI no son auditables públicamente.

Diagnósticos médicos: Un hospital utiliza un modelo de IA para recomendar tratamientos contra el cáncer. Las regulaciones exigen que los médicos documenten los procesos de toma de decisiones. Pero si la versión del modelo de IA no se puede verificar, el rastro de auditoría está incompleto. Una demanda por negligencia médica podría depender de demostrar qué modelo generó la recomendación, algo imposible con las API opacas.

Gobernanza de DAO: Una organización descentralizada utiliza un agente de IA para votar sobre propuestas de tesorería. Los miembros de la comunidad exigen pruebas de que el agente utilizó el modelo aprobado, no una variante manipulada que favorezca resultados específicos. Sin verificación criptográfica, el voto carece de legitimidad.

Esta es la brecha de confianza a la que se dirige Gensyn: a medida que la IA se integra en la toma de decisiones críticas, la incapacidad de verificar la autenticidad y el comportamiento del modelo se convierte en un "bloqueador fundamental para desplegar IA agéntica en entornos de alto riesgo".

Judge: El protocolo de evaluación de IA verificable​

Judge resuelve el problema de la opacidad mediante la ejecución de modelos de IA deterministas y acordados previamente contra entradas del mundo real, y consignando los resultados en una blockchain donde cualquiera puede desafiarlos. Así es como funciona el protocolo:

1. Compromiso del modelo: Los participantes se ponen de acuerdo sobre un modelo de IA: su arquitectura, pesos y configuración de inferencia. Este modelo se hashea y se registra on-chain. El hash sirve como una huella digital criptográfica: cualquier desviación del modelo acordado produce un hash diferente.

2. Ejecución determinista: Judge ejecuta el modelo utilizando el Runtime Reproducible de Gensyn, que garantiza una reproducibilidad exacta a nivel de bits en todos los dispositivos. Esto elimina el no determinismo de punto flotante, una innovación crítica que exploraremos en breve.

3. Compromiso público: Después de la inferencia, Judge publica el resultado (o un hash del mismo) on-chain. Esto crea un registro permanente y auditable de lo que produjo el modelo para una entrada determinada.

4. Período de desafío: Cualquiera puede desafiar el resultado volviendo a ejecutar el modelo de forma independiente. Si su resultado difiere, presentan una prueba de fraude. El mecanismo de delegación arbitrada de Verde señala el operador exacto en el grafo computacional donde los resultados divergen.

5. Slashing por fraude: Si un desafiante demuestra que Judge produjo resultados incorrectos, el ejecutor original es penalizado (slashing de tokens en staking). Esto alinea los incentivos económicos: los ejecutores maximizan las ganancias ejecutando los modelos correctamente.

Judge transforma la evaluación de la IA de "confiar en el proveedor de la API" a "verificar la prueba criptográfica". El comportamiento del modelo es público, auditable y exigible; ya no está oculto detrás de endpoints propietarios.

Verde: Eliminando el no determinismo de punto flotante​

El principal desafío técnico en la IA verificable es el determinismo. Las redes neuronales realizan miles de millones de operaciones de punto flotante durante la inferencia. En las GPU modernas, estas operaciones no son perfectamente reproducibles:

No asociatividad: La suma de punto flotante no es asociativa. (a + b) + c puede arrojar un resultado diferente al de a + (b + c) debido a los errores de redondeo. Las GPU paralizan las sumas en miles de núcleos, y el orden en que se acumulan las sumas parciales varía según el hardware y la versión del controlador.

Variabilidad en la programación de kernels: Los kernels de GPU (como la multiplicación de matrices o la atención) pueden ejecutarse en diferentes órdenes según la carga de trabajo, las optimizaciones del controlador o la arquitectura del hardware. Incluso ejecutar el mismo modelo en la misma GPU dos veces puede dar resultados diferentes si la programación del kernel difiere.

Dependencia del tamaño de lote: La investigación ha descubierto que la inferencia de LLM no es determinista a nivel de sistema porque el resultado depende del tamaño del lote (batch size). Muchos kernels (matmul, RMSNorm, atención) cambian la salida numérica según cuántas muestras se procesen juntas; una inferencia con un tamaño de lote de 1 produce valores diferentes a los de la misma entrada en un lote de 8.

Estos problemas hacen que los modelos de IA estándar no sean adecuados para la verificación en blockchain. Si dos validadores vuelven a ejecutar la misma inferencia y obtienen resultados ligeramente diferentes, ¿quién tiene razón? Sin determinismo, el consenso es imposible.

Verde soluciona esto con RepOps (Reproducible Operators), una biblioteca que elimina el no determinismo del hardware al controlar el orden de las operaciones de punto flotante en todos los dispositivos. Así es como funciona:

Órdenes de reducción canónicos: RepOps impone un orden determinista para sumar resultados parciales en operaciones como la multiplicación de matrices. En lugar de dejar que el programador de la GPU decida, RepOps especifica explícitamente: "sumar la columna 0, luego la columna 1, luego la columna 2..." en todo el hardware. Esto asegura que (a + b) + c se compute siempre en la misma secuencia.

Kernels de CUDA personalizados: Gensyn desarrolló kernels optimizados que priorizan la reproducibilidad sobre la velocidad bruta. Las multiplicaciones de matrices de RepOps incurren en una sobrecarga de menos del 30% en comparación con cuBLAS estándar, un intercambio razonable a cambio del determinismo.

Fijación de controladores y versiones: Verde utiliza controladores de GPU con versiones fijas y configuraciones canónicas, lo que garantiza que el mismo modelo ejecutado en diferentes hardwares produzca salidas idénticas bit a bit. Un modelo que se ejecuta en una NVIDIA A100 en un centro de datos coincide con la salida de una AMD MI250 en otro, bit por bit.

Este es el avance que permite la verificación de Judge: la reproducibilidad exacta a nivel de bits significa que los validadores pueden confirmar los resultados de forma independiente sin confiar en los ejecutores. Si el hash coincide, la inferencia es correcta; es matemáticamente demostrable.

Delegación Arbitrada: Verificación Eficiente sin Recomputación Completa​

Incluso con una ejecución determinista, verificar la inferencia de IA de forma ingenua es costoso. Un modelo de 70 mil millones de parámetros que genera 1,000 tokens podría requerir 10 horas de GPU. Si los validadores deben volver a ejecutar cada inferencia para verificar la corrección, el costo de verificación iguala al costo de ejecución, lo que anula el propósito de la descentralización.

El mecanismo de delegación arbitrada de Verde hace que la verificación sea exponencialmente más económica:

Múltiples ejecutores no confiables: En lugar de un solo ejecutor, Judge asigna tareas a múltiples proveedores independientes. Cada uno realiza la misma inferencia y envía los resultados.

El desacuerdo activa una investigación: Si todos los ejecutores están de acuerdo, se acepta el resultado y no se necesita más verificación. Si los resultados difieren, Verde inicia un juego de desafío.

Búsqueda binaria sobre el grafo de computación: Verde no vuelve a ejecutar toda la inferencia. En su lugar, realiza una búsqueda binaria sobre el grafo computacional del modelo para encontrar el primer operador donde los resultados divergen. Esto señala la capa exacta (por ejemplo, "capa de atención 47, cabezal 8") que causa la discrepancia.

Cómputo mínimo del árbitro: Un árbitro (que puede ser un contrato inteligente o un validador con capacidad de cómputo limitada) verifica solo el operador en disputa, no todo el paso hacia adelante (forward pass). Para un modelo de 70B de parámetros con 80 capas, esto reduce la verificación a comprobar unas 7 capas (log₂ 80) en el peor de los casos.

Este enfoque es más de un 1,350% más eficiente que la replicación ingenua (donde cada validador vuelve a ejecutar todo). Gensyn combina pruebas criptográficas, teoría de juegos y procesos optimizados para garantizar la ejecución correcta sin computación redundante.

El resultado: Judge puede verificar cargas de trabajo de IA a escala, permitiendo redes de inferencia descentralizadas donde miles de nodos no confiables aportan cómputo, y los ejecutores deshonestos son detectados y penalizados.

Toma de Decisiones de IA de Alto Riesgo: Por qué la Transparencia es Importante​

El mercado objetivo de Judge no son los chatbots casuales, sino aplicaciones donde la verificabilidad no es algo deseable, sino un requisito regulatorio o económico. Estos son escenarios donde las API opacas fallan catastróficamente:

Finanzas descentralizadas (DeFi): Los agentes de trading autónomos gestionan miles de millones en activos. Si un agente utiliza un modelo de IA para decidir cuándo reequilibrar carteras, los usuarios necesitan pruebas de que el modelo no fue manipulado. Judge permite la verificación on-chain: el agente se compromete con un hash de modelo específico, ejecuta operaciones basadas en sus salidas y cualquiera puede desafiar la lógica de decisión. Esta transparencia evita los rug pulls (fraudes de salida) donde los agentes maliciosos afirman que "la IA me dijo que liquidara" sin evidencia.

Cumplimiento normativo: Las instituciones financieras que despliegan IA para la calificación crediticia, la detección de fraudes o la lucha contra el lavado de dinero (AML) se enfrentan a auditorías. Los reguladores exigen explicaciones: "¿Por qué el modelo marcó esta transacción?". Las API opacas no proporcionan una pista de auditoría. Judge crea un registro inmutable de la versión del modelo, las entradas y las salidas, satisfaciendo los requisitos de cumplimiento.

Gobernanza algorítmica: Las organizaciones autónomas descentralizadas (DAO) utilizan agentes de IA para proponer o votar decisiones de gobernanza. Los miembros de la comunidad deben verificar que el agente utilizó el modelo aprobado, no una variante hackeada. Con Judge, la DAO codifica el hash del modelo en su contrato inteligente, y cada decisión incluye una prueba criptográfica de corrección.

IA médica y legal: Los sistemas sanitarios y legales requieren rendición de cuentas. Un médico que diagnostica cáncer con ayuda de IA necesita documentar la versión exacta del modelo utilizado. Un abogado que redacta contratos con IA debe demostrar que el resultado provino de un modelo examinado y sin sesgos. La pista de auditoría on-chain de Judge proporciona esta evidencia.

Mercados de predicción y oráculos: Proyectos como Polymarket utilizan IA para resolver los resultados de las apuestas (por ejemplo, "¿Sucederá este evento?"). Si la resolución depende de un modelo de IA que analiza artículos de noticias, los participantes necesitan pruebas de que el modelo no fue manipulado. Judge verifica la inferencia de IA del oráculo, evitando disputas.

En cada caso, el hilo común es que la confianza sin transparencia es insuficiente. Como señala VeritasChain, los sistemas de IA necesitan "registradores de vuelo criptográficos": registros inmutables que demuestren lo que sucedió cuando surgen disputas.

La alternativa de prueba de conocimiento cero: comparando Verde y ZKML​

Judge no es el único enfoque para la IA verificable. El aprendizaje automático de conocimiento cero (ZKML) logra objetivos similares utilizando zk-SNARKs: pruebas criptográficas de que un cálculo se realizó correctamente sin revelar las entradas ni los pesos.

¿Cómo se compara Verde con ZKML?

Costo de verificación: ZKML requiere ~ 1,000 × más cómputo que la inferencia original para generar pruebas (estimaciones de investigación). Un modelo de 70 B - parámetros que necesite 10 horas de GPU para la inferencia podría requerir 10,000 horas de GPU para probarse. La delegación arbitrada de Verde es logarítmica: verificar ~ 7 capas en lugar de 80 es una reducción de 10 ×, no de 1,000 ×.

Complejidad del probador: ZKML exige hardware especializado (como ASICs personalizados para circuitos zk-SNARK) para generar pruebas de manera eficiente. Verde funciona en GPUs comerciales — cualquier minero con una PC para juegos puede participar.

Compensaciones de privacidad: La fortaleza de ZKML es la privacidad — las pruebas no revelan nada sobre las entradas o los pesos del modelo. La ejecución determinante de Verde es transparente: las entradas y salidas son públicas (aunque los pesos pueden estar encriptados). Para la toma de decisiones de alto riesgo, la transparencia suele ser deseable. Una DAO que vota sobre la asignación de la tesorería quiere pistas de auditoría públicas, no pruebas ocultas.

Alcance de la prueba: ZKML está prácticamente limitado a la inferencia — probar el entrenamiento es inviable con los costos computacionales actuales. Verde admite tanto la verificación de inferencia como la de entrenamiento (el protocolo más amplio de Gensyn verifica el entrenamiento distribuido).

Adopción en el mundo real: Los proyectos de ZKML como Modulus Labs han logrado avances (verificando modelos de 18 M - parámetros en cadena), pero siguen limitados a modelos más pequeños. El tiempo de ejecución determinante de Verde maneja modelos de más de 70 B + parámetros en producción.

ZKML destaca donde la privacidad es primordial — como al verificar la autenticación biométrica (Worldcoin) sin exponer los escaneos de iris. Verde destaca donde la transparencia es el objetivo — demostrar que un modelo público específico se ejecutó correctamente. Ambos enfoques son complementarios, no competitivos.

El ecosistema Gensyn: de Judge al entrenamiento descentralizado​

Judge es un componente de la visión más amplia de Gensyn: una red descentralizada para el cómputo de aprendizaje automático. El protocolo incluye:

Capa de ejecución: Ejecución consistente de ML a través de hardware heterogéneo (GPUs de consumo, clústeres empresariales, dispositivos de borde). Gensyn estándariza las cargas de trabajo de inferencia y entrenamiento, asegurando la compatibilidad.

Capa de verificación (Verde): Verificación sin confianza utilizando delegación arbitrada. Los ejecutores deshonestos son detectados y penalizados.

Comunicación peer-to-peer: Distribución de la carga de trabajo entre dispositivos sin coordinación centralizada. Los mineros reciben tareas, las ejecutan y envían las pruebas directamente a la cadena de bloques.

Coordinación descentralizada: Los contratos inteligentes en un rollup de Ethereum identifican a los participantes, asignan tareas y procesan los pagos sin necesidad de permisos.

La red de prueba pública de Gensyn se lanzó en marzo de 2025, con la red principal planificada para 2026. La venta pública del token $ AI ocurrió en diciembre de 2025, estableciendo incentivos económicos para mineros y validadores.

Judge encaja en este ecosistema como la capa de evaluación: mientras el protocolo central de Gensyn maneja el entrenamiento y la inferencia, Judge asegura que esos resultados sean verificables. Esto crea un volante de inercia:

Los desarrolladores entrenan modelos en la red descentralizada de Gensyn (más barato que AWS debido a que las GPUs de consumo infrautilizadas aportan cómputo).

Los modelos se despliegan con Judge garantizando la integridad de la evaluación. Las aplicaciones consumen inferencia a través de las APIs de Gensyn, pero a diferencia de OpenAI, cada resultado incluye una prueba criptográfica.

Los validadores ganan tarifas al verificar las pruebas y detectar fraudes, alineando los incentivos económicos con la seguridad de la red.

La confianza escala a medida que más aplicaciones adoptan la IA verificable, reduciendo la dependencia de proveedores centralizados.

El objetivo final: entrenamiento e inferencia de IA que sea demostrablemente correcta, descentralizada y accesible para cualquiera — no solo para las grandes tecnológicas.

Desafíos y preguntas abiertas​

El enfoque de Judge es innovador, pero persisten varios desafíos:

Sobrecarga de rendimiento: La ralentización del 30 % de RepOps es aceptable para la verificación, pero si cada inferencia debe ejecutarse de forma determinante, las aplicaciones sensibles a la latencia (trading en tiempo real, vehículos autónomos) podrían preferir alternativas más rápidas y no verificables. La hoja de ruta de Gensyn probablemente incluye optimizar RepOps aún más — pero existe una compensación fundamental entre velocidad y determinismo.

Fragmentación de versiones de controladores: Verde asume controladores con versiones fijas, pero los fabricantes de GPU lanzan actualizaciones constantemente. Si algunos mineros usan CUDA 12.4 y otros usan 12.5, la reproducibilidad bit a bit se rompe. Gensyn debe imponer una gestión de versiones estricta — complicando la incorporación de mineros.

Secreto de los pesos del modelo: La transparencia de Judge es una ventaja para los modelos públicos, pero un inconveniente para los propietarios. Si un fondo de cobertura entrena un modelo de trading valioso, desplegarlo en Judge expone los pesos a los competidores (a través del compromiso en cadena). Las alternativas basadas en ZKML podrían ser preferidas para modelos secretos — lo que sugiere que Judge se dirige a aplicaciones de IA abiertas o semiabiertas.

Latencia en la resolución de disputas: Si un desafiante alega fraude, resolver la disputa mediante búsqueda binaria requiere múltiples transacciones en cadena (cada ronda estrecha el espacio de búsqueda). Las aplicaciones de alta frecuencia no pueden esperar horas por la finalidad. Gensyn podría introducir la verificación optimista (asumir la corrección a menos que sea desafiada dentro de una ventana) para reducir la latencia.

Resistencia a Sybil en la delegación arbitrada: Si varios ejecutores deben estar de acuerdo, ¿qué impide que una sola entidad controle a todos los ejecutores a través de identidades Sybil? Gensyn probablemente utiliza una selección ponderada por participación (se eligen preferentemente validadores de alta reputación) además del slashing para disuadir la colusión — pero los umbrales económicos deben calibrarse cuidadosamente.

Estos no son obstáculos insuperables — son desafíos de ingeniería. La innovación principal (IA determinante + verificación criptográfica) es sólida. Los detalles de ejecución madurarán a medida que la red de prueba pase a la red principal.

El camino hacia la IA verificable: Vías de adopción y ajuste de mercado​

El éxito de Judge depende de la adopción. ¿Qué aplicaciones implementarán primero la IA verificable?

Protocolos DeFi con agentes autónomos: Las DAO de Aave, Compound o Uniswap podrían integrar agentes verificados por Judge para la gestión de tesorería. La comunidad vota para aprobar el hash de un modelo, y todas las decisiones de los agentes incluyen pruebas. Esta transparencia genera confianza, algo crítico para la legitimidad de DeFi.

Mercados de predicción y oráculos: Plataformas como Polymarket o Chainlink podrían usar Judge para resolver apuestas o entregar feeds de precios. Los modelos de IA que analizan el sentimiento, las noticias o la actividad on-chain producirían resultados verificables, eliminando disputas sobre la manipulación de oráculos.

Identidad descentralizada y KYC: Los proyectos que requieren verificación de identidad basada en IA (estimación de edad a partir de selfies, verificaciones de autenticidad de documentos) se benefician de la pista de auditoría de Judge. Los reguladores aceptan pruebas criptográficas de cumplimiento sin tener que confiar en proveedores de identidad centralizados.

Moderación de contenido para redes sociales: Las redes sociales descentralizadas (Farcaster, Lens Protocol) podrían implementar moderadores de IA verificados por Judge. Los miembros de la comunidad verifican que el modelo de moderación no esté sesgado ni censurado, garantizando la neutralidad de la plataforma.

Plataformas de IA como servicio (AI-as-a-Service): Los desarrolladores que crean aplicaciones de IA pueden ofrecer "inferencia verificable" como una función premium. Los usuarios pagan un extra por las pruebas, diferenciando los servicios de las alternativas opacas.

El punto común: aplicaciones donde la confianza es costosa (debido a la regulación, la descentralización o los altos riesgos) y el costo de verificación es aceptable (en comparación con el valor de la certeza).

Judge no reemplazará a OpenAI para los chatbots de consumo; a los usuarios no les importa si GPT-4 es verificable cuando piden ideas de recetas. Pero para algoritmos financieros, herramientas médicas y sistemas de gobernanza, la IA verificable es el futuro.

La verificabilidad como el nuevo estándar​

Judge de Gensyn representa un cambio de paradigma: la evaluación de la IA está pasando de "confiar en el proveedor" a "verificar la prueba". La base técnica —reproducibilidad exacta a nivel de bits a través de Verde, verificación eficiente mediante delegación arbitrada y pistas de auditoría on-chain— hace que esta transición sea práctica, no solo aspiracional.

Las implicaciones resuenan mucho más allá de Gensyn. Si la IA verificable se convierte en un estándar, los proveedores centralizados pierden sus fosos competitivos (moats). La propuesta de valor de OpenAI no son solo las capacidades de GPT-4, es la conveniencia de no gestionar la infraestructura. Pero si Gensyn demuestra que la IA descentralizada puede igualar el rendimiento centralizado con la verificabilidad añadida, los desarrolladores no tendrán motivos para quedar atrapados en APIs propietarias.

La carrera ha comenzado. Los proyectos de ZKML (Modulus Labs, el sistema biométrico de Worldcoin) apuestan por las pruebas de conocimiento cero. Los entornos de ejecución deterministas (Verde de Gensyn, EigenAI) apuestan por la reproducibilidad. Los enfoques optimistas (oráculos de IA en blockchain) apuestan por las pruebas de fraude. Cada camino tiene sus compensaciones, pero el destino es el mismo: sistemas de IA donde los resultados sean demostrables, no solo plausibles.

Para la toma de decisiones de alto riesgo, esto no es opcional. Los reguladores no aceptarán un "confíe en nosotros" de los proveedores de IA en aplicaciones financieras, de salud o legales. Las DAO no delegarán la gestión de tesorería a agentes de caja negra. Y a medida que los sistemas de IA autónomos se vuelvan más potoresos, el público exigirá transparencia.

Judge es el primer sistema listo para producción que cumple con esta promesa. La red de prueba (testnet) está activa. Los fundamentos criptográficos son sólidos. El mercado — $27 mil millones en criptoactivos de agentes de IA, miles de millones en activos DeFi gestionados por algoritmos y una presión regulatoria creciente — está listo.

La era de las APIs de IA opacas está terminando. La era de la inteligencia verificable está comenzando. Y Judge de Gensyn está iluminando el camino.

---

Fuentes:

• Presentando Judge | Blog de Gensyn
• Gensyn lanza Judge, un sistema de evaluación de IA verificable | Bitget News
• Sistema de verificación Verde en producción | Gensyn
• Verde: un sistema de verificación para el aprendizaje automático sobre nodos no confiables | Gensyn
• Verde: Verificación mediante delegación arbitrada para programas de aprendizaje automático | arXiv
• EigenAI: Inferencia determinista, resultados verificables | arXiv
• Arquitectura de verificación determinista para sistemas de IA | Medium
• El protocolo Gensyn | Documentación de Gensyn
• Gensyn | La red para la inteligencia de máquinas
• Testnet pública de Gensyn | Documentación de Gensyn
• ZKML: Aprendizaje automático verificable mediante pruebas de conocimiento cero | Kudelski Security
• El imperativo de la verificación: Por qué los sistemas de trading de IA necesitan registradores de vuelo criptográficos | Medium
• Agentes de IA verificables: Un enfoque criptográfico para crear un ecosistema financiero transparente | CoinCentral
• Un marco para la verificabilidad criptográfica de canales de IA de extremo a extremo | arXiv

El 2 de febrero de 2026, la economía de agentes de IA dio un paso crítico hacia adelante. Nillion lanzó Blacklight, una capa de verificación que implementa el estándar ERC-8004 para resolver una de las preguntas más urgentes de la blockchain: ¿cómo confiar en un agente de IA que nunca has conocido?

La respuesta no es una simple puntuación de reputación ni un registro centralizado. Es un proceso de verificación de cinco pasos respaldado por pruebas criptográficas, auditorías programables y una red de nodos operados por la comunidad. A medida que los agentes autónomos ejecutan cada vez más operaciones, gestionan tesorerías y coordinan actividades cross-chain, Blacklight representa la infraestructura que permite la coordinación de IA trustless a escala.

El problema de confianza que los agentes de IA no pueden resolver solos​

Las cifras cuentan la historia. Los agentes de IA ahora contribuyen con el 30 % del volumen de operaciones de Polymarket, gestionan estrategias de rendimiento DeFi en múltiples protocolos y ejecutan flujos de trabajo complejos de forma autónoma. Pero existe un cuello de botella fundamental: ¿cómo verifican los agentes la confiabilidad de los demás sin relaciones preexistentes?

Los sistemas tradicionales dependen de autoridades centralizadas que emiten credenciales. La promesa de la Web3 es diferente: verificación trustless a través de la criptografía y el consenso. Sin embargo, hasta el ERC-8004, no existía una forma estandarizada para que los agentes demostraran su autenticidad, rastrearan su comportamiento o validaran su lógica de toma de decisiones on-chain.

Esto no es solo un problema teórico. Como explica Davide Crapis, "ERC-8004 permite interacciones descentralizadas entre agentes de IA, establece el comercio trustless y mejora los sistemas de reputación en Ethereum". Sin él, el comercio entre agentes permanece confinado a ecosistemas cerrados o requiere supervisión manual, lo que anula el propósito de la autonomía.

ERC-8004: La infraestructura de confianza de tres registros​

El estándar ERC-8004, que entró en funcionamiento en la mainnet de Ethereum el 29 de enero de 2026, establece una capa de confianza modular a través de tres registros on-chain:

Registro de Identidad (Identity Registry): Utiliza ERC-721 para proporcionar identificadores de agentes portátiles. Cada agente recibe un token no fungible que representa su identidad única on-chain, lo que permite el reconocimiento multiplataforma y evita la suplantación de identidad.

Registro de Reputación (Reputation Registry): Recopila comentarios y calificaciones estandarizados. A diferencia de los sistemas de revisión centralizados, los comentarios se registran on-chain con firmas criptográficas, creando un rastro de auditoría inmutable. Cualquiera puede rastrear este historial y crear algoritmos de reputación personalizados.

Registro de Validación (Validation Registry): Admite la verificación criptográfica y económica del trabajo de los agentes. Aquí es donde ocurren las auditorías programables: los validadores pueden volver a ejecutar cálculos, verificar pruebas de conocimiento cero o aprovechar Entornos de Ejecución Seguros (TEEs) para confirmar que un agente actuó correctamente.

La brillantez del ERC-8004 es su diseño agnóstico. Como señala la especificación técnica, el estándar admite varias técnicas de validación: "re-ejecución de tareas asegurada por participación (stake) (inspirada en sistemas como EigenLayer), verificación de pruebas de aprendizaje automático de conocimiento cero (zkML) y atestaciones de Entornos de Ejecución Seguros (TEEs)".

Esta flexibilidad es importante. Un agente de arbitraje DeFi podría usar pruebas zkML para verificar su lógica de trading sin revelar su alpha. Un agente de cadena de suministro podría usar atestaciones TEE para demostrar que accedió correctamente a datos del mundo real. Un agente de puente cross-chain podría confiar en la validación criptoeconómica con slashing para garantizar una ejecución honesta.

El proceso de verificación de cinco pasos de Blacklight​

La implementación del ERC-8004 de Nillion en Blacklight añade una capa crucial: nodos de verificación operados por la comunidad. Así es como funciona el proceso:

1. Registro del Agente: Un agente registra su identidad en el Registro de Identidad, recibiendo un NFT ERC-721. Esto crea un identificador único on-chain vinculado a la clave pública del agente.

2. Inicio de la Solicitud de Verificación: Cuando un agente realiza una acción que requiere validación (por ejemplo, ejecutar una operación, transferir fondos o actualizar un estado), envía una solicitud de verificación a Blacklight.

3. Asignación de Comité: El protocolo de Blacklight asigna aleatoriamente un comité de nodos de verificación para auditar la solicitud. Estos nodos son operados por miembros de la comunidad que realizan un stake de 70,000 tokens NIL, alineando los incentivos para la integridad de la red.

4. Comprobaciones de los Nodos: Los miembros del comité vuelven a ejecutar el cálculo o validan las pruebas criptográficas. Si los validadores detectan un comportamiento incorrecto, pueden realizar un slashing del stake del agente (en sistemas que utilizan validación criptoeconómica) o marcar la identidad en el Registro de Reputación.

5. Informes On-Chain: Los resultados se publican on-chain. El Registro de Validación registra si el trabajo del agente fue verificado, creando una prueba permanente de ejecución. El Registro de Reputación se actualiza en consecuencia.

Este proceso ocurre de forma asíncrona y no bloqueante, lo que significa que los agentes no esperan a que se complete la verificación para realizar tareas rutinarias, pero las acciones de alto riesgo (grandes transferencias, operaciones cross-chain) pueden requerir una validación previa.

Auditorías programables: más allá de la confianza binaria​

La característica más ambiciosa de Blacklight es la «verificación programable»: la capacidad de auditar cómo un agente toma decisiones, no solo qué hace.

Considere un agente DeFi que gestiona una tesorería. Las auditorías tradicionales verifican que los fondos se movieron correctamente. Las auditorías programables verifican:

• Consistencia de la lógica de toma de decisiones: ¿Siguió el agente su estrategia de inversión declarada o se desvió de ella?
• Ejecución de flujos de trabajo de varios pasos: Si se suponía que el agente debía reequilibrar carteras en tres cadenas, ¿completó todos los pasos?
• Restricciones de seguridad: ¿Respetó el agente los límites de gas, las tolerancias de deslizamiento y los topes de exposición?

Esto es posible porque el Registro de Verificación de ERC-8004 admite sistemas de prueba arbitrarios. Un agente puede comprometerse con un algoritmo de toma de decisiones on-chain (por ejemplo, un hash de los pesos de su red neuronal o un circuito zk-SNARK que represente su lógica) y luego demostrar que cada acción se ajusta a ese algoritmo sin revelar detalles propietarios.

La hoja de ruta de Nillion apunta explícitamente a estos casos de uso: «Nillion planea expandir las capacidades de Blacklight hacia la "verificación programable", permitiendo auditorías descentralizadas de comportamientos complejos como la consistencia de la lógica de toma de decisiones de los agentes, la ejecución de flujos de trabajo de varios pasos y las restricciones de seguridad».

Esto cambia la verificación de reactiva (detectar errores después del hecho) a proactiva (imponer el comportamiento correcto por diseño).

Computación ciega: la privacidad se une a la verificación​

La tecnología subyacente de Nillion, Nil Message Compute (NMC), añade una dimensión de privacidad a la verificación de agentes. A diferencia de las blockchains tradicionales donde todos los datos son públicos, la «computación ciega» de Nillion permite realizar operaciones con datos encriptados sin necesidad de desencriptarlos.

He aquí por qué esto es importante para los agentes: un agente de IA podría necesitar verificar su estrategia de trading sin revelar su «alpha» a los competidores. O demostrar que accedió correctamente a registros médicos confidenciales sin exponer los datos de los pacientes. O demostrar el cumplimiento de las restricciones regulatorias sin revelar la lógica de negocio propietaria.

El NMC de Nillion logra esto a través de la computación multipartita (MPC), donde los nodos generan colaborativamente «factores cegadores» (aleatoriedad correlacionada utilizada para encriptar datos). Como explica DAIC Capital: «Los nodos generan el recurso de red clave necesario para procesar datos —un tipo de aleatoriedad correlacionada denominada factor cegador—, y cada nodo almacena su parte del factor cegador de forma segura, distribuyendo la confianza a través de la red de una manera segura frente a la computación cuántica».

Esta arquitectura es resistente a la computación cuántica por diseño. Incluso si un ordenador cuántico rompe la criptografía de curva elíptica actual, los factores cegadores distribuidos permanecen seguros porque ningún nodo individual posee información suficiente para desencriptar los datos.

Para los agentes de IA, esto significa que la verificación no requiere sacrificar la confidencialidad. Un agente puede demostrar que ejecutó una tarea correctamente mientras mantiene privados sus métodos, fuentes de datos y lógica de toma de decisiones.

La apuesta por la infraestructura de la economía de agentes de $ 4300 millones​

El lanzamiento de Blacklight se produce en un momento en que el sector de la IA y la blockchain entra en una fase de hipercrecimiento. Se proyecta que el mercado crezca de $680 millones (2025) a$ 4300 millones (2034) a una tasa de crecimiento anual compuesta (CAGR) del 22,9 %, mientras que el mercado más amplio de la computación confidencial alcanzará los $ 350 000 millones para 2032.

Pero Nillion no solo apuesta por la expansión del mercado; se está posicionando como una infraestructura crítica. El cuello de botella de la economía de agentes no es el cómputo ni el almacenamiento; es la confianza a escala. Como señala el informe de perspectivas de KuCoin para 2026, tres tendencias clave están remodelando la identidad de la IA y el flujo de valor:

Sistemas Agent-Wrapping-Agent (agente envuelve agente): Agentes que se coordinan con otros agentes para ejecutar tareas complejas de varios pasos. Esto requiere una identidad y verificación estandarizadas, exactamente lo que proporciona ERC-8004.

KYA (Know Your Agent - Conozca a su agente): Infraestructura financiera que exige credenciales de agentes. Los reguladores no aprobarán agentes autónomos que gestionen fondos sin pruebas de un comportamiento correcto. Las auditorías programables de Blacklight abordan esto directamente.

Nanopagos: Los agentes necesitan liquidar micropagos de manera eficiente. El protocolo de pago x402, que procesó más de 20 millones de transacciones en enero de 2026, complementa a ERC-8004 encargándose de la liquidación mientras Blacklight se encarga de la confianza.

Juntos, estos estándares alcanzaron su madurez para producción con semanas de diferencia, un avance de coordinación que señala la maduración de la infraestructura.

El futuro de Ethereum centrado en los agentes​

La adopción de ERC-8004 se extiende mucho más allá de Nillion. A principios de 2026, múltiples proyectos ya han integrado el estándar:

• Oasis Network: Implementando ERC-8004 para computación confidencial con validación basada en TEE.
• The Graph: Soportando ERC-8004 y x402 para permitir interacciones de agentes verificables en la indexación descentralizada.
• MetaMask: Explorando billeteras de agentes con identidad ERC-8004 integrada.
• Coinbase: Integrando ERC-8004 para soluciones de custodia de agentes institucionales.

Esta rápida adopción refleja un cambio más amplio en la hoja de ruta de Ethereum. Vitalik Buterin ha enfatizado repetidamente que el papel de la blockchain se está convirtiendo en «simplemente la fontanería» para los agentes de IA, no la capa orientada al consumidor, sino la infraestructura de confianza que permite la coordinación autónoma.

Blacklight de Nillion acelera esta visión al hacer que la verificación sea programable, preserve la privacidad y sea descentralizada. En lugar de depender de oráculos centralizados o revisores humanos, los agentes pueden demostrar su corrección criptográficamente.

Lo que viene a continuación: Integración de la Mainnet y expansión del ecosistema​

La hoja de ruta de 2026 de Nillion prioriza la compatibilidad con Ethereum y la descentralización sostenible. El puente de Ethereum se puso en marcha en febrero de 2026, seguido de contratos inteligentes nativos para staking y computación privada (blind computation).

Los miembros de la comunidad que realicen staking de 70,000 tokens NIL pueden operar nodos de verificación Blacklight, obteniendo recompensas mientras mantienen la integridad de la red. Este diseño refleja la economía de validadores de Ethereum, pero añade un rol específico de verificación.

Los próximos hitos incluyen:

• Soporte ampliado para zkML: Integración con proyectos como Modulus Labs para verificar la inferencia de IA on-chain
• Verificación cross-chain: Permitir que Blacklight verifique agentes que operan a través de Ethereum, Cosmos y Solana
• Alianzas institucionales: Colaboraciones con Coinbase y Alibaba Cloud para el despliegue de agentes empresariales
• Herramientas de cumplimiento regulatorio: Creación de marcos KYA (Know Your Agent) para la adopción de servicios financieros

Quizás lo más importante es que Nillion está desarrollando nilGPT, un chatbot de IA totalmente privado que demuestra cómo la computación ciega (blind computation) permite interacciones de agentes confidenciales. Esto no es solo una demostración; es un modelo para agentes que manejan datos sensibles en salud, finanzas y gobierno.

El objetivo final de la coordinación trustless​

El lanzamiento de Blacklight marca un punto de inflexión para la economía de los agentes. Antes del ERC-8004, los agentes operaban en silos: se confiaba en ellos dentro de sus propios ecosistemas, pero no podían coordinarse a través de plataformas sin intermediarios humanos. Después del ERC-8004, los agentes pueden verificar la identidad de los demás, auditar el comportamiento mutuo y liquidar pagos de forma autónoma.

Esto desbloquea categorías de aplicaciones completamente nuevas:

• Fondos de cobertura descentralizados: Agentes que gestionan carteras a través de múltiples cadenas, con estrategias de inversión verificables y auditorías de rendimiento transparentes
• Cadenas de suministro autónomas: Agentes que coordinan la logística, los pagos y el cumplimiento sin supervisión centralizada
• DAOs impulsadas por IA: Organizaciones gobernadas por agentes que votan, proponen y ejecutan basándose en una lógica de toma de decisiones verificada criptográficamente
• Gestión de liquidez entre protocolos: Agentes que reequilibran activos a través de protocolos DeFi con restricciones de riesgo programables

¿El hilo conductor? Todos requieren una coordinación trustless: la capacidad de que los agentes trabajen juntos sin relaciones preexistentes o anclajes de confianza centralizados.

Blacklight de Nillion proporciona exactamente eso. Al combinar la infraestructura de identidad y reputación del ERC-8004 con la verificación programable y la computación ciega, crea una capa de confianza lo suficientemente escalable para la economía de billones de agentes que se vislumbra en el horizonte.

A medida que blockchain se convierte en la infraestructura básica (plumbing) para los agentes de IA y las finanzas globales, la pregunta no es si necesitamos una infraestructura de verificación, sino quién la construye y si es descentralizada o está controlada por unos pocos intermediarios. Los nodos operados por la comunidad de Blacklight y el estándar abierto defienden la primera opción.

La era de los actores autónomos on-chain ha llegado. La infraestructura está activa. La única pregunta que queda es qué se construirá sobre ella.

---

Fuentes:

• Nillion lanza la verificación ERC-8004 en Blacklight | Phemex News
• ERC-8004: Agentes Trustless | Ethereum Improvement Proposals
• ERC-8004: Infraestructura para agentes de IA autónomos | QuillAudits
• Davide Crapis: ERC 8004 permite interacciones descentralizadas de agentes de IA | Unchained
• La computadora ciega de Nillion arregla Internet | Nillion
• Nillion (NIL): La primera red de computación ciega de la humanidad | DAIC Capital
• Perspectiva de la economía de agentes de IA para 2026 | KuCoin
• The Graph respalda los estándares x402 y ERC-8004 para la economía de agentes de IA | Blockchain News
• ERC-8004: Un estándar para agentes trustless | Oasis Network
• Nillion 2.0 se pone en marcha en Ethereum | MEXC News
• Nillion: Blind Compute estalló en 2025 | Medium
• 2026: Cuando blockchain se convierte solo en la infraestructura básica para agentes de IA | Blockmanity

Introducción: La Necesidad de una IA Verificable en la Blockchain​

A medida que los sistemas de IA aumentan su influencia, asegurar que sus resultados sean confiables se vuelve crítico. Los métodos tradicionales se basan en garantías institucionales (esencialmente, “solo confía en nosotros”), que no ofrecen garantías criptográficas. Esto es especialmente problemático en contextos descentralizados como las blockchains, donde un contrato inteligente o un usuario debe confiar en un resultado derivado de la IA sin poder volver a ejecutar un modelo pesado on-chain. El Aprendizaje Automático de Conocimiento Cero (zkML) aborda esto al permitir la verificación criptográfica de los cálculos de ML. En esencia, zkML permite a un probador generar una prueba sucinta de que “el resultado $Y$ provino de ejecutar el modelo $M$ en la entrada $X$” – sin revelar $X$ ni los detalles internos de $M$. Estas pruebas de conocimiento cero (ZKPs) pueden ser verificadas por cualquiera (o cualquier contrato) de manera eficiente, cambiando la confianza en la IA de la “política a la prueba”.

La verificabilidad on-chain de la IA significa que una blockchain puede incorporar cálculos avanzados (como inferencias de redes neuronales) verificando una prueba de ejecución correcta en lugar de realizar el cómputo en sí. Esto tiene amplias implicaciones: los contratos inteligentes pueden tomar decisiones basadas en predicciones de IA, los agentes autónomos descentralizados pueden demostrar que siguieron sus algoritmos, y los servicios de cómputo cross-chain u off-chain pueden proporcionar resultados verificables en lugar de oráculos no verificables. En última instancia, zkML ofrece un camino hacia una IA sin confianza y que preserva la privacidad – por ejemplo, demostrando que las decisiones de un modelo de IA son correctas y autorizadas sin exponer datos privados o los pesos del modelo propietario. Esto es clave para aplicaciones que van desde análisis de salud seguros hasta juegos en blockchain y oráculos de DeFi.

Cómo Funciona zkML: Comprimiendo la Inferencia de ML en Pruebas Sucintas​

A un alto nivel, zkML combina sistemas de pruebas criptográficas con la inferencia de ML para que una evaluación de modelo compleja pueda ser “comprimida” en una pequeña prueba. Internamente, el modelo de ML (por ejemplo, una red neuronal) se representa como un circuito o programa que consta de muchas operaciones aritméticas (multiplicaciones de matrices, funciones de activación, etc.). En lugar de revelar todos los valores intermedios, un probador realiza el cálculo completo off-chain y luego utiliza un protocolo de prueba de conocimiento cero para certificar que cada paso se realizó correctamente. El verificador, con solo la prueba y algunos datos públicos (como el resultado final y un identificador para el modelo), puede estar criptográficamente convencido de la corrección sin volver a ejecutar el modelo.

Para lograr esto, los frameworks de zkML típicamente transforman el cálculo del modelo en un formato adecuado para las ZKPs:

• Compilación de Circuitos: En los enfoques basados en SNARK, el grafo de computación del modelo se compila en un circuito aritmético o un conjunto de restricciones polinómicas. Cada capa de la red neuronal (convoluciones, multiplicaciones de matrices, activaciones no lineales) se convierte en un subcircuito con restricciones que aseguran que las salidas sean correctas dadas las entradas. Debido a que las redes neuronales involucran operaciones no lineales (ReLUs, Sigmoides, etc.) que no se adaptan naturalmente a los polinomios, se utilizan técnicas como las tablas de búsqueda para manejarlas eficientemente. Por ejemplo, una ReLU (salida = max(0, entrada)) puede ser forzada por una restricción personalizada o una búsqueda que verifica que la salida es igual a la entrada si la entrada ≥ 0, y cero en caso contrario. El resultado final es un conjunto de restricciones criptográficas que el probador debe satisfacer, lo que implícitamente demuestra que el modelo se ejecutó correctamente.
• Traza de Ejecución y Máquinas Virtuales: Una alternativa es tratar la inferencia del modelo como una traza de programa, como se hace en los enfoques de zkVM. Por ejemplo, la zkVM JOLT se enfoca en el conjunto de instrucciones RISC-V; se puede compilar el modelo de ML (o el código que lo calcula) a RISC-V y luego probar que cada instrucción de la CPU se ejecutó correctamente. JOLT introduce una técnica de “singularidad de búsqueda”, reemplazando las costosas restricciones aritméticas con búsquedas rápidas en tablas para cada operación válida de la CPU. Cada operación (suma, multiplicación, operación a nivel de bits, etc.) se verifica mediante una búsqueda en una tabla gigante de resultados válidos precalculados, utilizando un argumento especializado (Lasso/SHOUT) para mantener la eficiencia. Esto reduce drásticamente la carga de trabajo del probador: incluso las operaciones complejas de 64 bits se convierten en una sola búsqueda en la tabla en la prueba en lugar de muchas restricciones aritméticas.
• Protocolos Interactivos (GKR Sum-Check): Un tercer enfoque utiliza pruebas interactivas como GKR (Goldwasser–Kalai–Rotblum) para verificar un cálculo en capas. Aquí, el cálculo del modelo se ve como un circuito aritmético en capas (cada capa de la red neuronal es una capa del grafo del circuito). El probador ejecuta el modelo normalmente pero luego participa en un protocolo sum-check para demostrar que las salidas de cada capa son correctas dadas sus entradas. En el enfoque de Lagrange (DeepProve, detallado a continuación), el probador y el verificador realizan un protocolo polinómico interactivo (hecho no interactivo a través de Fiat-Shamir) que verifica la consistencia de los cálculos de cada capa sin rehacerlos. Este método de sum-check evita generar un circuito estático monolítico; en su lugar, verifica la consistencia de los cálculos paso a paso con operaciones criptográficas mínimas (principalmente hashing o evaluaciones de polinomios).

Independientemente del enfoque, el resultado es una prueba sucinta (típicamente de unos pocos kilobytes a unas pocas decenas de kilobytes) que certifica la corrección de toda la inferencia. La prueba es de conocimiento cero, lo que significa que cualquier entrada secreta (datos privados o parámetros del modelo) puede mantenerse oculta – influyen en la prueba pero no se revelan a los verificadores. Solo se revelan las salidas o afirmaciones públicas deseadas. Esto permite escenarios como “probar que el modelo $M$ aplicado a los datos del paciente $X$ produce el diagnóstico $Y$, sin revelar $X$ ni los pesos del modelo”.

Habilitando la verificación on-chain: Una vez que se genera una prueba, se puede publicar en una blockchain. Los contratos inteligentes pueden incluir lógica de verificación para comprobar la prueba, a menudo utilizando primitivas criptográficas precompiladas. Por ejemplo, Ethereum tiene precompilaciones para las operaciones de emparejamiento BLS12-381 utilizadas en muchos verificadores de zk-SNARK, lo que hace que la verificación on-chain de las pruebas SNARK sea eficiente. Las STARKs (pruebas basadas en hash) son más grandes, pero aún pueden verificarse on-chain con una optimización cuidadosa o posiblemente con algunas suposiciones de confianza (la L2 de StarkWare, por ejemplo, verifica las pruebas STARK en Ethereum mediante un contrato verificador on-chain, aunque con un costo de gas más alto que las SNARKs). La clave es que la cadena no necesita ejecutar el modelo de ML – solo ejecuta una verificación que es mucho más barata que el cómputo original. En resumen, zkML comprime la costosa inferencia de IA en una pequeña prueba que las blockchains (o cualquier verificador) pueden comprobar en milisegundos o segundos.

Lagrange DeepProve: Arquitectura y Rendimiento de un Avance en zkML​

DeepProve de Lagrange Labs es un framework de inferencia zkML de última generación centrado en la velocidad y la escalabilidad. Lanzado en 2025, DeepProve introdujo un nuevo sistema de prueba que es dramáticamente más rápido que las soluciones anteriores como Ezkl. Su diseño se centra en el protocolo de prueba interactivo GKR con sum-check y optimizaciones especializadas para circuitos de redes neuronales. Así es como funciona DeepProve y logra su rendimiento:

• Preprocesamiento Único: Los desarrolladores comienzan con una red neuronal entrenada (los tipos actualmente soportados incluyen perceptrones multicapa y arquitecturas CNN populares). El modelo se exporta al formato ONNX, una representación de grafo estándar. La herramienta de DeepProve luego analiza el modelo ONNX y lo cuantiza (convierte los pesos a formato de punto fijo/entero) para una aritmética de campo eficiente. En esta fase, también genera las claves de prueba y verificación para el protocolo criptográfico. Esta configuración se realiza una vez por modelo y no necesita repetirse por cada inferencia. DeepProve enfatiza la facilidad de integración: “Exporta tu modelo a ONNX → configuración única → genera pruebas → verifica en cualquier lugar”.

• Prueba (Inferencia + Generación de Prueba): Después de la configuración, un probador (que podría ser ejecutado por un usuario, un servicio o la red de probadores descentralizada de Lagrange) toma una nueva entrada $X$ y ejecuta el modelo $M$ sobre ella, obteniendo la salida $Y$. Durante esta ejecución, DeepProve registra una traza de ejecución de los cálculos de cada capa. En lugar de traducir cada multiplicación en un circuito estático por adelantado (como hacen los enfoques SNARK), DeepProve utiliza el protocolo GKR de tiempo lineal para verificar cada capa sobre la marcha. Para cada capa de la red, el probador se compromete con las entradas y salidas de la capa (por ejemplo, a través de hashes criptográficos o compromisos polinómicos) y luego participa en un argumento de sum-check para demostrar que las salidas realmente resultan de las entradas según la función de la capa. El protocolo sum-check convence iterativamente al verificador de la corrección de una suma de evaluaciones de un polinomio que codifica el cálculo de la capa, sin revelar los valores reales. Las operaciones no lineales (como ReLU, softmax) se manejan eficientemente a través de argumentos de búsqueda en DeepProve – si se calculó la salida de una activación, DeepProve puede probar que cada salida corresponde a un par de entrada-salida válido de una tabla precalculada para esa función. Capa por capa, se generan pruebas y luego se agregan en una única prueba sucinta que cubre todo el pase hacia adelante del modelo. El trabajo pesado de la criptografía se minimiza – el probador de DeepProve realiza principalmente cálculos numéricos normales (la inferencia real) más algunos compromisos criptográficos ligeros, en lugar de resolver un sistema gigante de restricciones.

• Verificación: El verificador utiliza la prueba sucinta final junto con algunos valores públicos – típicicamente el identificador comprometido del modelo (un compromiso criptográfico con los pesos de $M$), la entrada $X$ (si no es privada) y la salida declarada $Y$ – para verificar la corrección. La verificación en el sistema de DeepProve implica verificar la transcripción del protocolo sum-check y los compromisos finales de polinomios o hashes. Esto es más complejo que verificar un SNARK clásico (que podría ser unos pocos emparejamientos), pero es vastamente más barato que volver a ejecutar el modelo. En los benchmarks de Lagrange, verificar una prueba de DeepProve para una CNN mediana toma del orden de 0.5 segundos en software. Eso es ~0.5s para confirmar, por ejemplo, que una red convolucional con cientos de miles de parámetros se ejecutó correctamente – más de 500× más rápido que re-computar ingenuamente esa CNN en una GPU para verificación. (De hecho, DeepProve midió una verificación hasta 521× más rápida para CNNs y 671× para MLPs en comparación con la re-ejecución). El tamaño de la prueba es lo suficientemente pequeño como para transmitirlo on-chain (decenas de KB), y la verificación podría realizarse en un contrato inteligente si fuera necesario, aunque 0.5s de cómputo podrían requerir una optimización cuidadosa del gas o una ejecución en capa 2.

Arquitectura y Herramientas: DeepProve está implementado en Rust y proporciona un conjunto de herramientas (la biblioteca zkml) para los desarrolladores. Soporta nativamente los grafos de modelos ONNX, lo que lo hace compatible con modelos de PyTorch o TensorFlow (después de exportarlos). El proceso de prueba actualmente apunta a modelos de hasta unos pocos millones de parámetros (las pruebas incluyen una red densa de 4M de parámetros). DeepProve aprovecha una combinación de componentes criptográficos: un compromiso polinómico multilineal (para comprometerse con las salidas de las capas), el protocolo sum-check para verificar los cálculos y argumentos de búsqueda para operaciones no lineales. Notablemente, el repositorio de código abierto de Lagrange reconoce que se basa en trabajos anteriores (la implementación de sum-check y GKR del proyecto Ceno de Scroll), lo que indica una intersección de zkML con la investigación de rollups de conocimiento cero.

Para lograr escalabilidad en tiempo real, Lagrange combina DeepProve con su Red de Probadores – una red descentralizada de probadores ZK especializados. La generación de pruebas pesadas puede ser delegada a esta red: cuando una aplicación necesita probar una inferencia, envía el trabajo a la red de Lagrange, donde muchos operadores (con staking en EigenLayer para seguridad) calculan las pruebas y devuelven el resultado. Esta red incentiva económicamente la generación de pruebas confiables (los trabajos maliciosos o fallidos resultan en el slashing del operador). Al distribuir el trabajo entre los probadores (y potencialmente aprovechar GPUs o ASICs), la Red de Probadores de Lagrange oculta la complejidad y el costo a los usuarios finales. El resultado es un servicio zkML rápido, escalable y descentralizado: “inferencias de IA verificables, rápidas y asequibles”.

Hitos de Rendimiento: Las afirmaciones de DeepProve están respaldadas por benchmarks contra el estado del arte anterior, Ezkl. Para una CNN con ~264k parámetros (modelo a escala de CIFAR-10), el tiempo de prueba de DeepProve fue de ~1.24 segundos frente a ~196 segundos para Ezkl – aproximadamente 158× más rápido. Para una red densa más grande con 4 millones de parámetros, DeepProve probó una inferencia en ~2.3 segundos frente a ~126.8 segundos para Ezkl (~54× más rápido). Los tiempos de verificación también se redujeron: DeepProve verificó la prueba de la CNN de 264k en ~0.6s, mientras que verificar la prueba de Ezkl (basada en Halo2) tomó más de 5 minutos en CPU en esa prueba. Las mejoras de velocidad provienen de la complejidad casi lineal de DeepProve: su probador escala aproximadamente O(n) con el número de operaciones, mientras que los probadores SNARK basados en circuitos a menudo tienen una sobrecarga superlineal (FFT y compromisos polinómicos que escalan). De hecho, el rendimiento del probador de DeepProve puede estar dentro de un orden de magnitud del tiempo de ejecución de la inferencia simple – los sistemas GKR recientes pueden ser <10× más lentos que la ejecución sin procesar para grandes multiplicaciones de matrices, un logro impresionante en ZK. Esto hace que las pruebas en tiempo real o bajo demanda sean más factibles, allanando el camino para la IA verificable en aplicaciones interactivas.

Casos de Uso: Lagrange ya está colaborando con proyectos de Web3 e IA para aplicar zkML. Los casos de uso de ejemplo incluyen: rasgos de NFT verificables (probar que una evolución generada por IA de un personaje de juego o coleccionable es calculada por el modelo autorizado), procedencia de contenido de IA (probar que una imagen o texto fue generado por un modelo específico, para combatir los deepfakes), modelos de riesgo de DeFi (probar la salida de un modelo que evalúa el riesgo financiero sin revelar datos propietarios), e inferencia de IA privada en salud o finanzas (donde un hospital puede obtener predicciones de IA con una prueba, asegurando la corrección sin exponer los datos del paciente). Al hacer que los resultados de la IA sean verificables y preserven la privacidad, DeepProve abre la puerta a una “IA en la que puedes confiar” en sistemas descentralizados – pasando de una era de “confianza ciega en modelos de caja negra” a una de “garantías objetivas”.

zkML Basado en SNARK: Ezkl y el Enfoque Halo2​

El enfoque tradicional de zkML utiliza zk-SNARKs (Argumentos de Conocimiento Sucintos No Interactivos) para probar la inferencia de redes neuronales. Ezkl (de ZKonduit/Modulus Labs) es un ejemplo líder de este enfoque. Se basa en el sistema de prueba Halo2 (un SNARK de estilo PLONK con compromisos polinómicos sobre BLS12-381). Ezkl proporciona una cadena de herramientas donde un desarrollador puede tomar un modelo de PyTorch o TensorFlow, exportarlo a ONNX, y hacer que Ezkl lo compile en un circuito aritmético personalizado automáticamente.

Cómo funciona: Cada capa de la red neuronal se convierte en restricciones:

• Las capas lineales (densas o de convolución) se convierten en colecciones de restricciones de multiplicación-suma que fuerzan los productos punto entre entradas, pesos y salidas.
• Las capas no lineales (como ReLU, sigmoide, etc.) se manejan mediante búsquedas o restricciones por partes porque tales funciones no son polinómicas. Por ejemplo, una ReLU puede implementarse mediante un selector booleano $b$ con restricciones que aseguren que $y = x \cdot b$ y $0 \le b \le 1$y$b=1$si$x>0$(una forma de hacerlo), o más eficientemente mediante una tabla de búsqueda que mapea$x \mapsto \max(0,x)$para un rango de valores de$x$. Los argumentos de búsqueda de Halo2 permiten mapear trozos de valores de 16 bits (o más pequeños), por lo que los dominios grandes (como todos los valores de 32 bits) generalmente se “trocean” en varias búsquedas más pequeñas. Este troceado aumenta el número de restricciones.
• Las operaciones con enteros grandes o divisiones (si las hay) se dividen de manera similar en piezas pequeñas. El resultado es un gran conjunto de restricciones R1CS/PLONK adaptadas a la arquitectura específica del modelo.

Ezkl luego utiliza Halo2 para generar una prueba de que estas restricciones se cumplen dadas las entradas secretas (pesos del modelo, entradas privadas) y las salidas públicas. Herramientas e integración: Una ventaja del enfoque SNARK es que aprovecha primitivas bien conocidas. Halo2 ya se utiliza en rollups de Ethereum (por ejemplo, Zcash, zkEVMs), por lo que está probado en batalla y tiene un verificador on-chain fácilmente disponible. Las pruebas de Ezkl utilizan la curva BLS12-381, que Ethereum puede verificar a través de precompilaciones, lo que hace sencillo verificar una prueba de Ezkl en un contrato inteligente. El equipo también ha proporcionado APIs fáciles de usar; por ejemplo, los científicos de datos pueden trabajar con sus modelos en Python y usar la CLI de Ezkl para producir pruebas, sin un conocimiento profundo de los circuitos.

Fortalezas: El enfoque de Ezkl se beneficia de la generalidad y el ecosistema de los SNARKs. Soporta modelos razonablemente complejos y ya ha visto “integraciones prácticas (desde modelos de riesgo de DeFi hasta IA en juegos)”, probando tareas de ML del mundo real. Debido a que opera a nivel del grafo de computación del modelo, puede aplicar optimizaciones específicas de ML: por ejemplo, podar pesos insignificantes o cuantizar parámetros para reducir el tamaño del circuito. También significa que la confidencialidad del modelo es natural – los pesos pueden tratarse como datos de testigo privados, por lo que el verificador solo ve que algún modelo válido produjo la salida, o en el mejor de los casos un compromiso con el modelo. La verificación de las pruebas SNARK es extremadamente rápida (típicamente unos pocos milisegundos o menos on-chain), y los tamaños de las pruebas son pequeños (unos pocos kilobytes), lo cual es ideal para el uso en blockchain.

Debilidades: El rendimiento es el talón de Aquiles. La prueba basada en circuitos impone grandes sobrecargas, especialmente a medida que los modelos crecen. Se ha señalado que, históricamente, los circuitos SNARK podrían requerir un millón de veces más trabajo para el probador que simplemente ejecutar el modelo. Halo2 y Ezkl optimizan esto, pero aún así, operaciones como grandes multiplicaciones de matrices generan toneladas de restricciones. Si un modelo tiene millones de parámetros, el probador debe manejar correspondientemente millones de restricciones, realizando pesadas FFTs y multiexponenciaciones en el proceso. Esto conduce a altos tiempos de prueba (a menudo minutos u horas para modelos no triviales) y un alto uso de memoria. Por ejemplo, probar incluso una CNN relativamente pequeña (por ejemplo, unos pocos cientos de miles de parámetros) puede llevar decenas de minutos con Ezkl en una sola máquina. El equipo detrás de DeepProve citó que Ezkl tardó horas para ciertas pruebas de modelos que DeepProve puede hacer en minutos. Los modelos grandes podrían ni siquiera caber en la memoria o requerir dividirse en múltiples pruebas (que luego necesitan agregación recursiva). Si bien Halo2 está “moderadamente optimizado”, cualquier necesidad de “trocear” búsquedas o manejar operaciones de bits anchos se traduce en una sobrecarga adicional. En resumen, la escalabilidad es limitada – Ezkl funciona bien para modelos pequeños a medianos (y de hecho superó a algunas alternativas anteriores como las VMs ingenuas basadas en Stark en benchmarks), pero tiene dificultades a medida que el tamaño del modelo crece más allá de un punto.

A pesar de estos desafíos, Ezkl y bibliotecas zkML similares basadas en SNARK son importantes peldaños. Demostraron que la inferencia de ML verificada es posible on-chain y tienen un uso activo. Notablemente, proyectos como Modulus Labs demostraron la verificación de un modelo de 18 millones de parámetros on-chain usando SNARKs (con una fuerte optimización). El costo no fue trivial, pero muestra la trayectoria. Además, el Protocolo Mina tiene su propio kit de herramientas zkML que utiliza SNARKs para permitir que los contratos inteligentes en Mina (que están basados en Snark) verifiquen la ejecución de modelos de ML. Esto indica un creciente soporte multiplataforma para zkML basado en SNARK.

Enfoques Basados en STARK: ZK Transparente y Programable para ML​

Los zk-STARKs (Argumentos de Conocimiento Escalables y Transparentes) ofrecen otra ruta hacia zkML. Los STARKs utilizan criptografía basada en hash (como FRI para compromisos polinómicos) y evitan cualquier configuración de confianza. A menudo operan simulando una CPU o VM y probando que la traza de ejecución es correcta. En el contexto de ML, se puede construir un STARK personalizado para la red neuronal o usar una VM STARK de propósito general para ejecutar el código del modelo.

VMs STARK Generales (RISC Zero, Cairo): Un enfoque directo es escribir código de inferencia y ejecutarlo en una VM STARK. Por ejemplo, Risc0 proporciona un entorno RISC-V donde cualquier código (por ejemplo, una implementación en C++ o Rust de una red neuronal) puede ser ejecutado y probado a través de un STARK. De manera similar, el lenguaje Cairo de StarkWare puede expresar cálculos arbitrarios (como una inferencia de LSTM o CNN) que luego son probados por el probador STARK de StarkNet. La ventaja es la flexibilidad – no necesitas diseñar circuitos personalizados para cada modelo. Sin embargo, los primeros benchmarks mostraron que las VMs STARK ingenuas eran más lentas en comparación con los circuitos SNARK optimizados para ML. En una prueba, una prueba basada en Halo2 (Ezkl) fue aproximadamente 3× más rápida que un enfoque basado en STARK en Cairo, e incluso 66× más rápida que una VM STARK RISC-V en un cierto benchmark en 2024. Esta brecha se debe a la sobrecarga de simular cada instrucción de bajo nivel en un STARK y las constantes más grandes en las pruebas STARK (el hashing es rápido pero se necesita mucho; los tamaños de las pruebas STARK son más grandes, etc.). Sin embargo, las VMs STARK están mejorando y tienen el beneficio de una configuración transparente (sin configuración de confianza) y seguridad post-cuántica. A medida que el hardware y los protocolos amigables con STARK avancen, las velocidades de prueba mejorarán.

El enfoque de DeepProve vs STARK: Curiosamente, el uso de GKR y sum-check por parte de DeepProve produce una prueba más parecida a un STARK en espíritu – es una prueba interactiva, basada en hash, sin necesidad de una cadena de referencia estructurada. La contrapartida es que sus pruebas son más grandes y la verificación es más pesada que la de un SNARK. Sin embargo, DeepProve muestra que un diseño de protocolo cuidadoso (especializado en la estructura en capas de ML) puede superar ampliamente tanto a las VMs STARK genéricas como a los circuitos SNARK en tiempo de prueba. Podemos considerar a DeepProve como un probador zkML de estilo STARK a medida (aunque usan el término zkSNARK por brevedad, no tiene la verificación de tamaño constante pequeño de un SNARK tradicional, ya que una verificación de 0.5s es más grande que la verificación típica de un SNARK). Las pruebas STARK tradicionales (como las de StarkNet) a menudo involucran decenas de miles de operaciones de campo para verificar, mientras que un SNARK verifica en quizás unas pocas docenas. Por lo tanto, una contrapartida es evidente: los SNARKs producen pruebas más pequeñas y verificadores más rápidos, mientras que los STARKs (o GKR) ofrecen una escalabilidad más fácil y sin configuración de confianza a costa del tamaño de la prueba y la velocidad de verificación.

Mejoras emergentes: La zkVM JOLT (discutida anteriormente bajo JOLTx) en realidad está produciendo SNARKs (usando compromisos tipo PLONK) pero encarna ideas que también podrían aplicarse en el contexto de STARK (las búsquedas Lasso teóricamente podrían usarse con compromisos FRI). StarkWare y otros están investigando formas de acelerar la prueba de operaciones comunes (como usar puertas personalizadas o pistas en Cairo para operaciones con enteros grandes, etc.). También está Circomlib-ML de Privacy & Scaling Explorations (PSE), que proporciona plantillas de Circom para capas de CNN, etc. – eso está orientado a SNARK, pero conceptualmente se podrían hacer plantillas similares para lenguajes STARK.

En la práctica, los ecosistemas no-Ethereum que aprovechan los STARKs incluyen StarkNet (que podría permitir la verificación on-chain de ML si alguien escribe un verificador, aunque el costo es alto) y el servicio Bonsai de Risc0 (que es un servicio de prueba off-chain que emite pruebas STARK que pueden ser verificadas en varias cadenas). A partir de 2025, la mayoría de las demos de zkML en blockchain han favorecido los SNARKs (debido a la eficiencia del verificador), pero los enfoques STARK siguen siendo atractivos por su transparencia y potencial en entornos de alta seguridad o resistentes a la cuántica. Por ejemplo, una red de cómputo descentralizada podría usar STARKs para permitir que cualquiera verifique el trabajo sin una configuración de confianza, útil para la longevidad. Además, algunas tareas de ML especializadas podrían explotar estructuras amigables con STARK: por ejemplo, los cálculos que usan intensivamente operaciones XOR/bit podrían ser más rápidos en STARKs (ya que son baratos en álgebra booleana y hashing) que en la aritmética de campo de los SNARKs.

Resumen de SNARK vs STARK para ML:

• Rendimiento: Los SNARKs (como Halo2) tienen una enorme sobrecarga de prueba por puerta pero se benefician de potentes optimizaciones y constantes pequeñas para la verificación; los STARKs (genéricos) tienen una sobrecarga constante mayor pero escalan de manera más lineal y evitan criptografía costosa como los emparejamientos. DeepProve muestra que personalizar el enfoque (sum-check) produce un tiempo de prueba casi lineal (rápido) pero con una prueba similar a un STARK. JOLT muestra que incluso una VM general puede hacerse más rápida con un uso intensivo de búsquedas. Empíricamente, para modelos de hasta millones de operaciones: un SNARK bien optimizado (Ezkl) puede manejarlo pero podría tardar decenas de minutos, mientras que DeepProve (GKR) puede hacerlo en segundos. Las VMs STARK en 2024 probablemente estaban en un punto intermedio o peor que los SNARKs a menos que fueran especializadas (Risc0 fue más lento en las pruebas, Cairo fue más lento sin pistas personalizadas).
• Verificación: Las pruebas SNARK se verifican más rápidamente (milisegundos, y datos mínimos on-chain ~ unos pocos cientos de bytes a unos pocos KB). Las pruebas STARK son más grandes (decenas de KB) y tardan más (decenas de ms a segundos) en verificarse debido a muchos pasos de hashing. En términos de blockchain, una verificación de SNARK podría costar, por ejemplo, ~200k de gas, mientras que una verificación de STARK podría costar millones de gas – a menudo demasiado alto para L1, aceptable en L2 o con esquemas de verificación sucintos.
• Configuración y Seguridad: Los SNARKs como Groth16 requieren una configuración de confianza por circuito (poco amigable para modelos arbitrarios), pero los SNARKs universales (PLONK, Halo2) tienen una configuración única que puede reutilizarse para cualquier circuito hasta un cierto tamaño. Los STARKs no necesitan configuración y solo usan suposiciones de hash (más suposiciones de complejidad polinómica clásica), y son seguros post-cuánticos. Esto hace que los STARKs sean atractivos para la longevidad – las pruebas permanecen seguras incluso si surgen las computadoras cuánticas, mientras que los SNARKs actuales (basados en BLS12-381) serían rotos por ataques cuánticos.

Consolidaremos estas diferencias en una tabla comparativa en breve.

FHE para ML (FHE-o-ML): Cómputo Privado vs. Cómputo Verificable​

El Cifrado Totalmente Homomórfico (FHE) es una técnica criptográfica que permite realizar cálculos directamente sobre datos cifrados. En el contexto de ML, FHE puede habilitar una forma de inferencia que preserva la privacidad: por ejemplo, un cliente puede enviar una entrada cifrada a un host de modelo, el host ejecuta la red neuronal sobre el texto cifrado sin descifrarlo, y devuelve un resultado cifrado que el cliente puede descifrar. Esto asegura la confidencialidad de los datos – el propietario del modelo no aprende nada sobre la entrada (y potencialmente el cliente solo aprende la salida, no los detalles internos del modelo si solo obtiene la salida). Sin embargo, FHE por sí solo no produce una prueba de corrección de la misma manera que lo hacen las ZKPs. El cliente debe confiar en que el propietario del modelo realmente realizó el cálculo honestamente (el texto cifrado podría haber sido manipulado). Por lo general, si el cliente tiene el modelo o espera una cierta distribución de salidas, el engaño flagrante puede ser detectado, pero los errores sutiles o el uso de una versión incorrecta del modelo no serían evidentes solo a partir de la salida cifrada.

Compensaciones en el rendimiento: FHE es notoriamente pesado en cómputo. Ejecutar una inferencia de aprendizaje profundo bajo FHE incurre en una ralentización de órdenes de magnitud. Los primeros experimentos (por ejemplo, CryptoNets en 2016) tardaron decenas de segundos en evaluar una pequeña CNN sobre datos cifrados. Para 2024, mejoras como CKKS (para aritmética aproximada) y mejores bibliotecas (Microsoft SEAL, Concrete de Zama) han reducido esta sobrecarga, pero sigue siendo grande. Por ejemplo, un usuario informó que usar Concrete-ML de Zama para ejecutar un clasificador CIFAR-10 tardó 25–30 minutos por inferencia en su hardware. Después de optimizaciones, el equipo de Zama logró ~40 segundos para esa inferencia en un servidor de 192 núcleos. Incluso 40s es extremadamente lento en comparación con una inferencia en texto plano (que podría ser de 0.01s), mostrando una sobrecarga de ~$10^3–\10^4\times$. Modelos más grandes o mayor precisión aumentan aún más el costo. Además, las operaciones FHE consumen mucha memoria y requieren un bootstrapping ocasional (un paso de reducción de ruido) que es computacionalmente costoso. En resumen, la escalabilidad es un problema importante – el estado del arte de FHE podría manejar una pequeña CNN o una regresión logística simple, pero escalar a grandes CNNs o Transformers está más allá de los límites prácticos actuales.

Ventajas de privacidad: El gran atractivo de FHE es la privacidad de los datos. La entrada puede permanecer completamente cifrada durante todo el proceso. Esto significa que un servidor no confiable puede computar sobre los datos privados de un cliente sin aprender nada sobre ellos. Por el contrario, si el modelo es sensible (propietario), se podría concebir cifrar los parámetros del modelo y hacer que el cliente realice la inferencia FHE de su lado – pero esto es menos común porque si el cliente tiene que hacer el pesado cómputo FHE, niega la idea de delegarlo a un servidor potente. Típicamente, el modelo es público o está en manos del servidor en texto claro, y los datos son cifrados por la clave del cliente. La privacidad del modelo en ese escenario no se proporciona por defecto (el servidor conoce el modelo; el cliente aprende las salidas pero no los pesos). Hay configuraciones más exóticas (como el cómputo seguro de dos partes o FHE de múltiples claves) donde tanto el modelo como los datos pueden mantenerse privados entre sí, pero eso incurre en aún más complejidad. En contraste, zkML a través de ZKPs puede asegurar la privacidad del modelo y la privacidad de los datos a la vez – el probador puede tener tanto el modelo como los datos como testigo secreto, revelando solo lo necesario al verificador.

No se necesita verificación on-chain (y ninguna es posible): Con FHE, el resultado sale cifrado para el cliente. El cliente luego lo descifra para obtener la predicción real. Si queremos usar ese resultado on-chain, el cliente (o quien tenga la clave de descifrado) tendría que publicar el resultado en texto plano y convencer a otros de que es correcto. Pero en ese punto, la confianza vuelve a estar en juego – a menos que se combine con una ZKP. En principio, se podría combinar FHE y ZKP: por ejemplo, usar FHE para mantener los datos privados durante el cómputo, y luego generar una prueba ZK de que el resultado en texto plano corresponde a un cálculo correcto. Sin embargo, combinarlos significa que pagas la penalización de rendimiento de FHE y ZKP – extremadamente impráctico con la tecnología actual. Por lo tanto, en la práctica, FHE-of-ML y zkML sirven para diferentes casos de uso:

• FHE-of-ML: Ideal cuando el objetivo es la confidencialidad entre dos partes (cliente y servidor). Por ejemplo, un servicio en la nube puede alojar un modelo de ML y los usuarios pueden consultarlo con sus datos sensibles sin revelar los datos a la nube (y si el modelo es sensible, quizás desplegarlo a través de codificaciones amigables con FHE). Esto es excelente para servicios de ML que preservan la privacidad (predicciones médicas, etc.). El usuario todavía tiene que confiar en que el servicio ejecute fielmente el modelo (ya que no hay prueba), pero al menos se previene cualquier fuga de datos. Algunos proyectos como Zama incluso están explorando una “EVM habilitada para FHE (fhEVM)” donde los contratos inteligentes podrían operar sobre entradas cifradas, pero verificar esos cálculos on-chain requeriría que el contrato de alguna manera imponga el cálculo correcto – un desafío abierto que probablemente requiera pruebas ZK o hardware seguro especializado.
• zkML (ZKPs): Ideal cuando el objetivo es la verificabilidad y la auditabilidad pública. Si quieres que cualquiera (o cualquier contrato) esté seguro de que “el Modelo $M$ fue evaluado correctamente en $X$ y produjo $Y$”, las ZKPs son la solución. También proporcionan privacidad como un extra (puedes ocultar $X$ o $Y$ o $M$ si es necesario tratándolos como entradas privadas para la prueba), pero su característica principal es la prueba de ejecución correcta.

Una relación complementaria: Vale la pena señalar que las ZKPs protegen al verificador (no aprenden nada sobre los secretos, solo que el cálculo se realizó correctamente), mientras que FHE protege los datos del probador de la parte que computa. En algunos escenarios, estos podrían combinarse – por ejemplo, una red de nodos no confiables podría usar FHE para computar sobre los datos privados de los usuarios y luego proporcionar pruebas ZK a los usuarios (o a la blockchain) de que los cálculos se realizaron de acuerdo con el protocolo. Esto cubriría tanto la privacidad como la corrección, pero el costo de rendimiento es enorme con los algoritmos actuales. Más factibles a corto plazo son los híbridos como Entornos de Ejecución Confiable (TEE) más ZKP o Cifrado Funcional más ZKP – estos están más allá de nuestro alcance, pero apuntan a proporcionar algo similar (los TEEs mantienen los datos/modelo secretos durante el cómputo, luego una ZKP puede certificar que el TEE hizo lo correcto).

En resumen, FHE-of-ML prioriza la confidencialidad de las entradas/salidas, mientras que zkML prioriza la corrección verificable (con posible privacidad). La Tabla 1 a continuación contrasta las propiedades clave:

Enfoque	Rendimiento del Probador (Inferencia y Prueba)	Tamaño de la Prueba y Verificación	Características de Privacidad	¿Configuración de Confianza?	¿Post-Cuántico?
zk-SNARK (Halo2, Groth16, PLONK, etc)	Sobrecarga pesada del probador (hasta 10^6× el tiempo de ejecución normal sin optimizaciones; en la práctica 10^3–10^5×). Optimizado para un modelo/circuito específico; tiempo de prueba en minutos para modelos medianos, horas para grandes. Los SNARKs de zkML recientes (DeepProve con GKR) mejoran esto enormemente (sobrecarga casi lineal, por ejemplo, segundos en lugar de minutos para modelos de millones de parámetros).	Pruebas muy pequeñas (a menudo < 100 KB, a veces ~unos pocos KB). La verificación es rápida: unos pocos emparejamientos o evaluaciones de polinomios (típicamente < 50 ms on-chain). Las pruebas basadas en GKR de DeepProve son más grandes (decenas–cientos de KB) y se verifican en ~0.5 s (aún mucho más rápido que volver a ejecutar el modelo).	Confidencialidad de datos: Sí – las entradas pueden ser privadas en la prueba (no reveladas). Privacidad del modelo: Sí – el probador puede comprometerse con los pesos del modelo y no revelarlos. Ocultación de salida: Opcional – la prueba puede ser de una declaración sin revelar la salida (por ejemplo, “la salida tiene la propiedad P”). Sin embargo, si la salida misma se necesita on-chain, típicamente se vuelve pública. En general, los SNARKs ofrecen flexibilidad completa de conocimiento cero (oculta las partes que quieras).	Depende del esquema. Groth16/EZKL requieren una configuración de confianza por circuito; PLONK/Halo2 usan una configuración universal (una vez). El sum-check GKR de DeepProve es transparente (sin configuración) – una ventaja de ese diseño.	Los SNARKs clásicos (curvas BLS12-381) no son seguros PQ (vulnerables a ataques cuánticos sobre el logaritmo discreto de curvas elípticas). Algunos SNARKs más nuevos usan compromisos seguros PQ, pero Halo2/PLONK como se usan en Ezkl no son seguros PQ. GKR (DeepProve) usa compromisos de hash (por ejemplo, Poseidon/Merkle) que se conjetura son seguros PQ (dependiendo de la resistencia a la preimagen del hash).
zk-STARK (FRI, prueba basada en hash)	La sobrecarga del probador es alta pero con un escalado más lineal. Típicamente 10^2–10^4× más lento que nativo para tareas grandes, con espacio para paralelizar. Las VMs STARK generales (Risc0, Cairo) mostraron un rendimiento más lento vs SNARK para ML en 2024 (por ejemplo, 3×–66× más lento que Halo2 en algunos casos). Los STARKs especializados (o GKR) pueden acercarse a una sobrecarga lineal y superar a los SNARKs para circuitos grandes.	Las pruebas son más grandes: a menudo decenas de KB (creciendo con el tamaño del circuito/log(n)). El verificador debe hacer múltiples comprobaciones de hash y FFT – tiempo de verificación ~O(n^ε) para un ε pequeño (por ejemplo, ~50 ms a 500 ms dependiendo del tamaño de la prueba). On-chain, esto es más costoso (el verificador L1 de StarkWare puede costar millones de gas por prueba). Algunos STARKs soportan pruebas recursivas para comprimir el tamaño, a costa del tiempo del probador.	Privacidad de datos y modelo: Un STARK puede hacerse de conocimiento cero aleatorizando los datos de la traza (agregando cegamiento a las evaluaciones de polinomios), por lo que puede ocultar entradas privadas de manera similar a un SNARK. Muchas implementaciones de STARK se centran en la integridad, pero las variantes zk-STARK sí permiten la privacidad. Así que sí, pueden ocultar entradas/modelos como los SNARKs. Ocultación de salida: igualmente posible en teoría (el probador no declara la salida como pública), pero rara vez se usa ya que usualmente la salida es lo que queremos revelar/verificar.	Sin configuración de confianza. La transparencia es una característica de los STARKs – solo requieren una cadena aleatoria común (que Fiat-Shamir puede derivar). Esto los hace atractivos para un uso abierto (cualquier modelo, en cualquier momento, sin ceremonia por modelo).	Sí, los STARKs se basan en suposiciones de seguridad de hash e información teórica (como el oráculo aleatorio y la dificultad de decodificar ciertas palabras de código en FRI). Se cree que son seguros contra adversarios cuánticos. Por lo tanto, las pruebas STARK son resistentes a PQ, una ventaja para la IA verificable a prueba de futuro.
FHE para ML (Cifrado Totalmente Homomórfico aplicado a la inferencia)	Probador = parte que realiza el cómputo sobre datos cifrados. El tiempo de cómputo es extremadamente alto: 10^3–10^5× más lento que la inferencia en texto plano es común. Hardware de alta gama (servidores de muchos núcleos, FPGA, etc.) puede mitigar esto. Algunas optimizaciones (inferencia de baja precisión, parámetros FHE nivelados) pueden reducir la sobrecarga, pero hay un impacto fundamental en el rendimiento. FHE es actualmente práctico para modelos pequeños o modelos lineales simples; las redes profundas siguen siendo un desafío más allá de tamaños de juguete.	No se genera ninguna prueba. El resultado es una salida cifrada. La verificación en el sentido de comprobar la corrección no es proporcionada por FHE solo – se confía en que la parte que computa no haga trampa. (Si se combina con hardware seguro, se podría obtener una atestación; de lo contrario, un servidor malicioso podría devolver un resultado cifrado incorrecto que el cliente descifraría a una salida errónea sin saber la diferencia).	Confidencialidad de datos: Sí – la entrada está cifrada, por lo que la parte que computa no aprende nada sobre ella. Privacidad del modelo: Si el propietario del modelo está haciendo el cómputo sobre la entrada cifrada, el modelo está en texto plano de su lado (no protegido). Si los roles se invierten (el cliente tiene el modelo cifrado y el servidor computa), el modelo podría mantenerse cifrado, pero este escenario es menos común. Hay técnicas como el ML seguro de dos partes que combinan FHE/MPC para proteger ambos, pero van más allá del FHE simple. Ocultación de salida: Por defecto, la salida del cómputo está cifrada (solo descifrable por la parte con la clave secreta, usualmente el propietario de la entrada). Así que la salida está oculta para el servidor que computa. Si queremos que la salida sea pública, el cliente puede descifrarla y revelarla.	No se necesita configuración. Cada usuario genera su propio par de claves para el cifrado. La confianza se basa en que las claves permanezcan secretas.	La seguridad de los esquemas FHE (por ejemplo, BFV, CKKS, TFHE) se basa en problemas de retículos (Learning With Errors), que se cree que son resistentes a los ataques cuánticos (al menos no se conoce ningún algoritmo cuántico eficiente). Por lo tanto, FHE se considera generalmente seguro post-cuántico.

Tabla 1: Comparación de los enfoques zk-SNARK, zk-STARK y FHE para la inferencia de aprendizaje automático (compensaciones de rendimiento y privacidad).

Casos de Uso e Implicaciones para Aplicaciones Web3​

La convergencia de la IA y la blockchain a través de zkML desbloquea nuevos y potentes patrones de aplicación en Web3:

• Agentes Autónomos Descentralizados y Toma de Decisiones On-Chain: Los contratos inteligentes o las DAOs pueden incorporar decisiones impulsadas por IA con garantías de corrección. Por ejemplo, imagina una DAO que utiliza una red neuronal para analizar las condiciones del mercado antes de ejecutar operaciones. Con zkML, el contrato inteligente de la DAO puede requerir una prueba zkSNARK de que el modelo de ML autorizado (con un compromiso de hash conocido) se ejecutó con los datos más recientes y produjo la acción recomendada, antes de que se acepte la acción. Esto evita que actores maliciosos inyecten una predicción falsa – la cadena verifica el cómputo de la IA. Con el tiempo, incluso se podrían tener agentes autónomos completamente on-chain (contratos que consultan IA off-chain o contienen modelos simplificados) tomando decisiones en DeFi o juegos, con todos sus movimientos probados como correctos y conformes a las políticas a través de pruebas zk. Esto aumenta la confianza en los agentes autónomos, ya que su “pensamiento” es transparente y verificable en lugar de una caja negra.

• Mercados de Cómputo Verificable: Proyectos como Lagrange están creando efectivamente mercados de computación verificable – los desarrolladores pueden externalizar la inferencia de ML pesada a una red de probadores y recibir a cambio una prueba con el resultado. Esto es análogo a la computación en la nube descentralizada, pero con confianza incorporada: no necesitas confiar en el servidor, solo en la prueba. Es un cambio de paradigma para los oráculos y la computación off-chain. Protocolos como la próxima DSC (capa de secuenciación descentralizada) de Ethereum o las redes de oráculos podrían usar esto para proporcionar fuentes de datos o análisis con garantías criptográficas. Por ejemplo, un oráculo podría suministrar “el resultado del modelo X en la entrada Y” y cualquiera puede verificar la prueba adjunta on-chain, en lugar de confiar en la palabra del oráculo. Esto podría habilitar IA-como-servicio verificable en la blockchain: cualquier contrato puede solicitar un cómputo (como “califica estos riesgos crediticios con mi modelo privado”) y aceptar la respuesta solo con una prueba válida. Proyectos como Gensyn están explorando mercados de entrenamiento e inferencia descentralizados utilizando estas técnicas de verificación.

• NFTs y Juegos – Procedencia y Evolución: En los juegos de blockchain o coleccionables NFT, zkML puede probar que los rasgos o movimientos del juego fueron generados por modelos de IA legítimos. Por ejemplo, un juego podría permitir que una IA evolucione los atributos de una mascota NFT. Sin ZK, un usuario astuto podría modificar la IA o el resultado para obtener una mascota superior. Con zkML, el juego puede requerir una prueba de que “las nuevas estadísticas de la mascota fueron calculadas por el modelo de evolución oficial sobre las estadísticas antiguas de la mascota”, evitando trampas. De manera similar para los NFTs de arte generativo: un artista podría lanzar un modelo generativo como un compromiso; más tarde, al acuñar NFTs, probar que cada imagen fue producida por ese modelo dada una semilla, garantizando la autenticidad (e incluso haciéndolo sin revelar el modelo exacto al público, preservando la propiedad intelectual del artista). Esta verificación de procedencia asegura la autenticidad de una manera similar a la aleatoriedad verificable – excepto que aquí es creatividad verificable.

• IA que Preserva la Privacidad en Dominios Sensibles: zkML permite la confirmación de resultados sin exponer las entradas. En el sector de la salud, los datos de un paciente podrían ser procesados por un modelo de diagnóstico de IA por un proveedor de la nube; el hospital recibe un diagnóstico y una prueba de que el modelo (que podría ser propiedad privada de una compañía farmacéutica) se ejecutó correctamente sobre los datos del paciente. Los datos del paciente permanecen privados (solo se usó una forma cifrada o comprometida en la prueba), y los pesos del modelo permanecen propietarios – sin embargo, el resultado es confiable. Los reguladores o las aseguradoras también podrían verificar que solo se usaron modelos aprobados. En finanzas, una empresa podría demostrar a un auditor o regulador que su modelo de riesgo se aplicó a sus datos internos y produjo ciertas métricas sin revelar los datos financieros sensibles subyacentes. Esto permite el cumplimiento y la supervisión con garantías criptográficas en lugar de confianza manual.

• Interoperabilidad Cross-Chain y Off-Chain: Debido a que las pruebas de conocimiento cero son fundamentalmente portátiles, zkML puede facilitar resultados de IA cross-chain. Una cadena podría tener una aplicación intensiva en IA ejecutándose off-chain; puede publicar una prueba del resultado en una blockchain diferente, que lo aceptará sin necesidad de confianza. Por ejemplo, considera una DAO multi-cadena que utiliza una IA para agregar el sentimiento en las redes sociales (datos off-chain). El análisis de IA (NLP complejo sobre grandes datos) se realiza off-chain por un servicio que luego publica una prueba en una pequeña blockchain (o múltiples cadenas) de que “el análisis se realizó correctamente y la puntuación de sentimiento de salida = 0.85”. Todas las cadenas pueden verificar y usar ese resultado en su lógica de gobernanza, sin que cada una necesite volver a ejecutar el análisis. Este tipo de cómputo verificable interoperable es lo que la red de Lagrange pretende soportar, sirviendo a múltiples rollups o L1s simultáneamente. Elimina la necesidad de puentes confiables o suposiciones de oráculos al mover resultados entre cadenas.

• Alineación y Gobernanza de la IA: En una nota más prospectiva, zkML ha sido destacado como una herramienta para la gobernanza y seguridad de la IA. Las declaraciones de visión de Lagrange, por ejemplo, argumentan que a medida que los sistemas de IA se vuelven más poderosos (incluso superinteligentes), la verificación criptográfica será esencial para asegurar que sigan las reglas acordadas. Al requerir que los modelos de IA produzcan pruebas de su razonamiento o restricciones, los humanos retienen un grado de control – “no puedes confiar en lo que no puedes verificar”. Si bien esto es especulativo e involucra tanto aspectos sociales como técnicos, la tecnología podría hacer cumplir que un agente de IA que se ejecuta de forma autónoma todavía demuestre que está utilizando un modelo aprobado y que no ha sido manipulado. Las redes de IA descentralizadas podrían usar pruebas on-chain para verificar las contribuciones (por ejemplo, una red de nodos que entrena colaborativamente un modelo puede probar que cada actualización se calculó fielmente). Por lo tanto, zkML podría desempeñar un papel en asegurar que los sistemas de IA sigan siendo responsables ante los protocolos definidos por humanos, incluso en entornos descentralizados o no controlados.

En conclusión, zkML y la IA verificable on-chain representan una convergencia de la criptografía avanzada y el aprendizaje automático que promete mejorar la confianza, la transparencia y la privacidad en las aplicaciones de IA. Al comparar los principales enfoques – zk-SNARKs, zk-STARKs y FHE – vemos un espectro de compensaciones entre rendimiento y privacidad, cada uno adecuado para diferentes escenarios. Los frameworks basados en SNARK como Ezkl y las innovaciones como DeepProve de Lagrange han hecho factible probar inferencias sustanciales de redes neuronales con un esfuerzo práctico, abriendo la puerta a implementaciones en el mundo real de IA verificable. Los enfoques basados en STARK y VM prometen una mayor flexibilidad y seguridad post-cuántica, que se volverán importantes a medida que el campo madure. FHE, aunque no es una solución para la verificabilidad, aborda la necesidad complementaria de la computación de ML confidencial, y en combinación con ZKPs o en contextos privados específicos puede empoderar a los usuarios para aprovechar la IA sin sacrificar la privacidad de los datos.

Las implicaciones para Web3 son significativas: podemos prever contratos inteligentes reaccionando a predicciones de IA, sabiendo que son correctas; mercados de cómputo donde los resultados se venden sin confianza; identidades digitales (como la prueba de humanidad de Worldcoin a través de IA de iris) protegidas por zkML para confirmar que alguien es humano sin filtrar su imagen biométrica; y en general una nueva clase de “inteligencia demostrable” que enriquece las aplicaciones de blockchain. Quedan muchos desafíos – rendimiento para modelos muy grandes, ergonomía para desarrolladores y la necesidad de hardware especializado – pero la trayectoria es clara. Como señaló un informe, “las ZKPs de hoy pueden soportar modelos pequeños, pero los modelos de moderados a grandes rompen el paradigma”; sin embargo, los rápidos avances (mejoras de velocidad de 50×–150× con DeepProve sobre el estado del arte anterior) están empujando ese límite hacia afuera. Con la investigación en curso (por ejemplo, sobre aceleración de hardware y prueba distribuida), podemos esperar que modelos de IA progresivamente más grandes y complejos se vuelvan demostrables. zkML podría evolucionar pronto de demos de nicho a un componente esencial de la infraestructura de IA confiable, asegurando que a medida que la IA se vuelve ubicua, lo haga de una manera que sea auditable, descentralizada y alineada con la privacidad y seguridad del usuario.