¿Quién valida la información que ve el AI Agent y las órdenes que emite cuando obtiene derechos de ejecución en la cadena?

I. ¿Qué expone el incidente de KelpDAO?

El 18 de abril de 2026, el puente cross-chain rsETH de KelpDAO fue atacado, liberando de manera anómala 116,500 rsETH, que en ese momento tenían un valor aproximado de 292 millones de dólares. El informe de incidentes de LayerZero muestra que el atacante obtuvo la clave de sesión del desarrollador a través de ingeniería social, contaminando el RPC interno del que dependía LayerZero Labs DVN, y suprimió el RPC externo mediante un ataque de denegación de servicio, lo que llevó a que el servicio de firma emitiera pruebas de mensajes falsificados basándose en datos erróneos. En ese momento, KelpDAO cambió la ruta de verificación de 2 de 2 a 1 de 1 DVN. Una vez que el DVN designado emite una prueba errónea, el sistema ya no requiere que un segundo DVN independiente valide el mismo mensaje. CrowdStrike y Mandiant atribuyeron el incidente con alta confianza a TraderTraitor (UNC4899), relacionado con Corea del Norte.

Este tipo de incidentes no son aislados. Muchos eventos de seguridad importantes en la cadena no se deben a que las suposiciones criptográficas sean refutadas, sino a problemas en el control de claves, fuentes de datos, configuración de validadores, implementación de protocolos y permisos operativos. El sistema no solo debe responder a "¿es válida esta firma?", sino también a "¿quién tiene derecho a firmar, en base a qué información se firma, y si el estado correspondiente a la firma realmente ocurrió?".

Cada vez más AI Agents están obteniendo capacidades de ejecución en la cadena a través de cuentas inteligentes, billeteras estratégicas o servicios de firma restringidos. Una firma válida solo puede probar que se ha invocado un camino de autorización, pero no puede probar que los datos en los que se basa el agente son confiables, que la decisión cumple con la estrategia establecida, o que la transacción debería haber ocurrido en ese momento. El objeto de la verificación está pasando de "la autenticidad de la firma" a "si la entrada, la decisión y la ejecución son coherentes".

II. ¿Qué resuelven las soluciones existentes y qué dejan sin resolver?

Las soluciones existentes abordan parcialmente algunos problemas de confianza, pero cada una deja la confianza restante en diferentes roles:

Oráculos y arbitraje de disputas: Los resultados del mercado de Polymarket son propuestos inicialmente por los participantes y solo entran en el proceso de votación de los poseedores de tokens de UMA si son cuestionados durante el período de impugnación. El problema no es "la falta de revisión", sino si la revisión es confiable. Cuando las reglas son ambiguas, los eventos reales tienen múltiples interpretaciones, o el poder de voto está concentrado en unas pocas direcciones, el sistema en realidad está delegando la cuestión de "quién define los hechos" a otra estructura de gobernanza.

Multifirma de puentes cross-chain y DVN: Ambos tienen diferentes métodos de implementación, pero requieren que la parte aplicante configure claramente el conjunto de validadores y el umbral. Después de que KelpDAO configuró la ruta como 1 de 1 DVN, toda la ruta de verificación dependía de un único servicio de validación; y los datos y mecanismos de respuesta a fallos de los que depende ese servicio pueden formar un nuevo punto único.

Custodia MPC: El atractivo de la firma umbral es que la clave no existe completamente en un solo lugar, pero el fragmentado criptográfico no lleva automáticamente a una descentralización del poder a nivel organizacional. Según lo revelado por el equipo de Multichain, después de que el fundador fue detenido por la policía china, el equipo perdió inmediatamente el acceso a los servidores de nodos MPC relacionados, que operaban en la cuenta de nube personal del fundador. Una vez que la cuenta de nube, los permisos operativos y la respuesta a emergencias se concentran en una sola persona, el diseño de umbral de MPC aún puede dejar un punto único a nivel organizacional.

TEE: El entorno de ejecución confiable puede aislar el código y los datos sensibles, pero no elimina la confianza, solo cambia el punto de confianza. La raíz de confianza del hardware y la actualización del microcódigo generalmente dependen de los fabricantes de chips, mientras que el código del enclave, los permisos de actualización y las políticas de certificación pueden ser controlados por el proyecto o la parte operativa. TEE puede proteger el proceso de cálculo, pero no puede automáticamente descentralizar estos permisos de gobernanza.

Los modos de falla de estas soluciones no son los mismos, pero apuntan a la misma clase de problemas: los umbrales y la descentralización escritos en el libro blanco solo constituyen un verdadero límite de seguridad si se implementan realmente en las fuentes de datos, permisos de cuenta, claves de actualización y procesos de gobernanza.

III. CRVA: rediseñando la forma de asignar derechos de verificación

DeepSafe fue renombrado de Bool Network en 2025. CRVA continúa la línea de pensamiento técnico propuesta por investigadores de Bool Network en 2022. El documento relacionado fue publicado en IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072), proponiendo una plataforma de notarización cross-chain basada en un "comité oculto en evolución" (evolving hidden committee).

La forma específica de hacerlo es: los nodos participan en una selección aleatoria a través de Ring-VRF, los seleccionados presentan pruebas y claves públicas temporales, los observadores externos pueden verificar su elegibilidad, pero es difícil identificar su identidad a largo plazo. El comité temporal seleccionado luego firma conjuntamente a través de MPC umbral, y ningún nodo individual puede producir resultados de forma independiente. La gestión de claves y otros procesos clave se ejecutan en TEE (por ejemplo, Intel SGX) según el diseño del documento, con el objetivo de reducir la posibilidad de que el operador del host lea o modifique las partes de la clave. El comité también rotará por época, obteniendo nuevas partes a través de un intercambio de claves verificable, mientras que las partes antiguas se invalidan, y el ciclo de rotación específico se determina por los parámetros de la red real.

El proyecto también espera que el estado de trabajo del comité oculto a través de TEE dificulte que los operadores de nodos determinen si su nodo participó en una verificación determinada. Hasta qué punto se puede lograr este objetivo depende del código de la red actual, la autenticación remota, los metadatos del lado del host y la protección contra canales laterales, no es una conclusión automática que "usar TEE" lo haga posible.

Sin embargo, estos mecanismos abordan la cuestión de "quién verifica y cómo se emiten resultados de manera segura", pero no definen automáticamente "qué resultado es correcto". En el contexto de los AI Agents, el comité aún debe llegar a conclusiones basadas en estrategias preestablecidas, fuentes de datos y reglas de juicio ejecutables. Si estas reglas tienen problemas, las fuentes de datos son poco confiables, o el objeto de verificación no tiene una respuesta objetivamente determinable, incluso el comité más seguro puede confirmar un resultado erróneo.

CRVA intenta reducir el riesgo de la exposición a largo plazo de validadores fijos y la concentración de permisos de firma, pero no puede eliminar completamente los puntos únicos a nivel de gobernanza e implementación. La admisión de nodos, la actualización de protocolos, la certificación TEE y la seguridad del software aún deben someterse a auditorías continuas. Con la premisa de que las partes antiguas sean confiables y se invaliden, y que el nuevo comité mantenga suficiente independencia, la rotación puede acortar la ventana de ataque contra grupos de firma fijos, pero no puede cubrir riesgos sistémicos como la cadena de suministro de software o permisos de actualización.

IV. Base técnica y progreso de implementación

La línea técnica de CRVA se remonta al documento publicado en IEEE TIFS Volumen 17 (2022), con DOI 10.1109/TIFS.2022.3209546. El modelo de protocolo, las pruebas de seguridad y la evaluación del prototipo en el documento fueron revisados por pares, proporcionando una base académica para el comité oculto dinámico, Ring-VRF, gestión de claves umbral y protección TEE. Es importante distinguir que la revisión por pares se refiere a los modelos y la implementación en el documento; cómo se corresponde el CRVA actualmente implementado por DeepSafe con el esquema del documento aún debe ser evaluado en función de las especificaciones técnicas actuales, auditorías de código y parámetros de red.

Según lo revelado por DeepSafe en octubre de 2025, la red había procesado casi 120 millones de verificaciones, con más de 2.65 millones de cuentas activas. El proyecto también indicó que sus relaciones ecológicas superan las 70, involucrando compatibilidad de billeteras, integración técnica, inversiones y colaboraciones de mercado de diferentes tipos.

En octubre de 2025, DeepSafe anunció la finalización de una ronda de semillas de 3 millones de dólares, con inversores que incluyen Antalpha Global, ViaBTC Capital y Gate. Desde la línea de tiempo, esta ronda de financiamiento corresponde principalmente al desarrollo técnico y la expansión ecológica después del cambio de marca.

V. De soluciones de verificación a infraestructura general

A medida que la infraestructura de blockchain se modulariza gradualmente, el consenso, la ejecución, la disponibilidad de datos, la interoperabilidad y el sistema de cuentas comienzan a ser asumidos por diferentes componentes. La modularización no ha hecho desaparecer los problemas de confianza, sino que ha hecho que los límites de seguridad de cada capa sean más claros. Los desarrolladores no solo deben elegir qué tecnología utilizar, sino también juzgar quién proporciona la garantía de seguridad de esa capa y quién es responsable en caso de problemas. Una vez que los AI Agents obtienen capacidades de ejecución en la cadena, surgen nuevas preguntas: ¿quién confirma que los datos que lee son confiables, que las decisiones no exceden la autoridad y que la transacción final es coherente con la autorización del usuario? Estas preguntas no obtendrán respuestas automáticamente debido a una firma válida.

DeepSafe espera abstraer la capacidad de verificación de un módulo accesorio dentro de una aplicación única a una infraestructura que pueda ser llamada por diferentes protocolos y AI Agents: "Pruebas, no promesas", utilizando evidencia verificable en lugar de promesas del ejecutor. CRVA ya ha combinado selección anónima, colaboración umbral y TEE en un camino técnico; si puede cubrir aún más oráculos, cross-chain y diferentes escenarios de AI Agents, y desarrollarse en una infraestructura de verificación general, dependerá de la acumulación continua de capacidades en la red actual, auditorías independientes e integración real.

Este artículo proviene de una contribución y no representa la opinión de BlockBeats.