Cómo detectamos vulnerabilidades en DeFi en menos de un segundo

Quicknode

21 de abril de 2026 — 7 minutos de lectura

Compartir

Añadir como fuente preferida

Por Arseniy Reutov, director técnico y cofundador de Decurity Publicado en el blog « Quicknode »

Llevo más de una década desarrollando sistemas de detección de ataques; primero en la Web 2.0, donde trabajé en el análisis de tráfico y en cortafuegos de aplicaciones web (WAF), y después en la Web 3.0, donde los mismos problemas de seguridad se desarrollan más rápidamente y con mayores cantidades de dinero en juego. Fui cofundador de Decurity en 2022. Auditamos protocolos DeFi y desarrollamos las herramientas necesarias para supervisarlos en entorno de producción. Defimon es la parte dedicada a la supervisión: un sistema de detección de vulnerabilidades en tiempo real en el que confían los equipos de los protocolos, las empresas de seguridad y los gestores de riesgos en todas las cadenas en las que realmente se ejecuta DeFi. Emite alertas antes de que los ataques lleguen a los titulares. Si no lo hace, es que no está cumpliendo con su función. Crear algo que funcione a esa velocidad, en tantas cadenas, resultó ser un problema de infraestructura más complejo que uno de seguridad. Esto es lo que aprendimos al desarrollarlo.

Por qué la velocidad de detección es un elemento básico de la seguridad

En DeFi, un protocolo puede quedar totalmente vaciado en una sola transacción atómica. Sin embargo, es muy frecuente que haya un margen de tiempo entre los primeros indicios de un ataque y el vaciado total del protocolo. El incidente de Balancer. El hackeo de Yearn. En ambos casos, la cuestión no era si alguien estaba vigilando, sino si detectaron esos primeros indicios y reaccionaron a tiempo.

Para que la respuesta automatizada ante incidentes funcione, la alerta debe llegar a tiempo para que se puedan tomar medidas: suspender contratos, notificar a los titulares de firmas múltiples, transferir fondos. Un retraso de dos segundos en el procesamiento de bloques puede parecer insignificante. A nivel de protocolo, supone la diferencia entre una advertencia y un análisis a posteriori.

La velocidad de detección no es una característica. Es el producto.

El problema de las encuestas

Cuando empezamos a desarrollar Defimon, obteníamos los datos de la cadena de bloques de la forma habitual: mediante sondeos a través de RPC, solicitando repetidamente a la cadena de bloques bloques, transacciones, registros y trazas recientes.

Funcionó hasta que dejó de hacerlo.

Dado que había que supervisar millones de direcciones de monedero e interacciones entre contratos, el método de sondeo planteaba dos problemas que no podíamos resolver mediante soluciones técnicas.

Latencia. Cada ciclo de sondeo añadía unos dos segundos de latencia de bloqueo. En un producto en el que el tiempo de detección determina si un equipe del protocolo recibe la alerta a tiempo, dos segundos suponen un problema estructural, no una cuestión de optimización del rendimiento.

Escalabilidad. Nuestra lista de direcciones supervisadas no dejaba de crecer. Enviábamos datos de la cadena de bloques a los flujos de trabajo de Apache Flink SQL que se ejecutaban en AWS, con listas dinámicas de direcciones almacenadas en memoria. A medida que se ampliaba la cobertura, los errores de falta de memoria se convirtieron en algo habitual. El sistema no podía escalar al ritmo que exigía lo que teníamos que supervisar. Además, cualquier cambio en el flujo de trabajo de SQL requería un reinicio completo de Apache Flink, lo que suponía hasta 20 minutos de tiempo de inactividad cada vez.

En el peor de los casos, gastábamos 4.000 dólares al mes en AWS para dar servicio a tres cadenas, con tres o cuatro ingenieros dedicados a mantener los procesos en funcionamiento. Nuestra equipe se especializa en lógica de detección. Y nosotros estábamos invirtiendo ese dinero en infraestructura.

Por qué decidimos dar un paso adelante en materia de datos

El cambio fundamental consistió en sustituir el sistema de consulta por un modelo «push» utilizando Quicknode Streams .

En lugar de solicitar los datos a la cadena de bloques, estos llegan en el momento en que un bloque se incorpora a la cadena. La latencia de los bloques se ha reducido de unos dos segundos a menos de 0,5 segundos. Las alertas de Telegram se activan ahora en menos de un segundo desde su detección. No se trata de una mejora incremental, sino de un producto de una categoría totalmente diferente.

Pero la latencia era solo una parte del problema. La mayor ventaja fue el filtrado en el origen.

Nuestro antiguo pipeline de Apache Flink se ejecutaba en SQL. La lógica de detección se basaba en una gran consulta compuesta por numerosas subconsultas, que al principio era fácil de escribir de forma declarativa, pero que resultaba muy complicada de mantener a medida que iba creciendo. Cuando migramos a Streams, también trasladamos nuestra lógica de detección de SQL a JavaScript, de modo que los filtros se ejecutan directamente dentro del nodo de la cadena de bloques. Ese cambio nos aportó tres cosas:

Flexibilidad. Cualquier cambio en la lógica de detección se aplica sin tiempo de inactividad. Contamos con un conjunto completo de pruebas, creado a partir de incidentes anteriores relacionados con las DeFi, que verifica que nuestra lógica se mantenga intacta tras cualquier modificación. Las herramientas de prueba de filtros JS de Quicknode nos permiten ejecutar todo el conjunto de pruebas antes de la implementación.

Ahorro. Ya no procesamos todos los datos de la cadena de bloques. Streams se encarga del filtrado a nivel de nodo y nos envía únicamente los datos que necesitamos. El ancho de banda se ha reducido considerablemente.

Velocidad. Los datos se envían en cuanto aparece un nuevo bloque. Sin intervalo de sondeo. Sin retardo de ida y vuelta.

La arquitectura de detección

Así es como se presenta nuestra cartera de proyectos en la actualidad.

Un bloque se registra en la cadena de bloques de cualquiera de las ocho cadenas que supervisamos. Streams lo filtra a nivel de nodo mediante JavaScript, pasando solo los datos relevantes a las etapas posteriores del proceso. El almacén de clave-valor integrado en Quicknode Streams contiene nuestra lista de seguimiento, con millones de direcciones rastreadas a las que los filtros de JavaScript pueden hacer referencia directamente. La lógica de detección de vulnerabilidades se aplica a los datos filtrados en nuestro servicio de origen. Si se detecta una coincidencia con un patrón, se activa una alerta.

Toda la secuencia se completa en menos de un segundo.

Un ejemplo concreto: al procesar los registros de transacciones con Streams, podemos detectar intentos de introducir puertas traseras en contratos inteligentes proxy no inicializados. Este patrón de ataque, que denominamos CPIMP (Clandestine Proxy In the Middle of Proxy), se produce cuando se despliega un proxy pero no se inicializa de forma atómica en la misma transacción. Esa brecha permite a un actor malintencionado hacerse con el control del proxy y establecer un contrato de implementación malicioso. Para detectarlo, es necesario examinar los datos de rastreo de forma temprana y rápida. Streams lo hace posible.

Escalabilidad a ocho cadenas sin un equipo de operaciones equipe

Comenzamos Defimon con tres cadenas. Ahora supervisamos ocho: Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Optimism e HyperEVM.

Con el sistema anterior, añadir una cadena suponía nueva infraestructura, nuevos servidores, nuevos procesos y más personal. Cada nueva incorporación competía directamente con las tareas de detección por el tiempo de los ingenieros.

Con Streams, añadir una cadena es tan sencillo como realizar un cambio en la configuración. La integración de HyperEVM nos llevó menos de un día. Adaptamos algunas constantes y direcciones relevantes, y eso supuso la mayor parte del trabajo.

Hoy en día, todo el proceso lo gestiona un solo ingeniero. El resto del equipo se centra en la lógica de detección. Con la configuración anterior, se necesitaban entre tres y cuatro personas solo para mantener la infraestructura en funcionamiento.

¿Qué ocurre tras la alerta?

Los suscriptores de Defimon no se limitan a estar atentos a los ataques. Están creando un sistema automatizado de respuesta a incidentes basado en nuestras alertas. Cuanto más rápida sea la alerta, más tiempo habrá para actuar.

Un cliente de un fondo de cobertura, que gestiona una posición en DeFi de nueve cifras, se integró con nuestro sistema a través de WebSockets para cerrar automáticamente sus posiciones en el momento en que detectáramos los primeros indicios de un ataque dirigido contra los protocolos que tenía configurados. Particulares y operadores utilizan nuestras alertas para ajustar sus posiciones cuando se identifica un incidente en curso.

Sin embargo, el caso de uso más significativo es la intervención activa de «whitehat». Gestionamos un bot «whitehat» que ya ha recuperado más de 2 millones de dólares en total. Recientemente, recuperó 512 000 dólares para un usuario que había configurado erróneamente, de forma accidental, sus límites de tokens. Actuamos con la suficiente rapidez como para intervenir antes de que los actores maliciosos se dieran cuenta. La velocidad del proceso subyacente es lo que hizo posible esa intervención.

Cierre

Todo protocolo DeFi debería saber en tiempo real qué está ocurriendo con sus contratos. En una época en la que la inteligencia artificial está acelerando el volumen y la sofisticación de los ataques, detectar los primeros indicios de un ataque no es opcional. Es lo mínimo imprescindible.

La función de Defimon es activar la alerta con tiempo suficiente para que los equipos puedan actuar. El flujo de datos es lo que lo hace posible o lo que lo impide.

Si tu equipe sigue funcionando mediante sondeo, la cuestión no es si la latencia importará, sino cuándo. Recompilar desde el código fuente es una tarea engorrosa. Pero aplicar parches a una arquitectura fundamentalmente lenta no es el camino hacia una detección en menos de un segundo. Para nosotros, pasar a un modelo «push» no fue una preferencia técnica. Era la única forma en que el producto podía funcionar realmente.

Arseniy Reutov es director técnico y cofundador de Decurity, una empresa de seguridad Web3 que cuenta con la confianza de 1inch, Gearbox y la Fundación « Arbitrum ». Defimon es la plataforma de detección de vulnerabilidades en tiempo real de Decurity, que supervisa ocho cadenas EVM para más de 3.500 suscriptores.