Este fin de semana detecté un pico de latencia que resultó apuntar a algo que antes no había separado correctamente.
Estaba observando una bóveda protegida por la integración de Chainalysis Hexagate de Newton, y una transacción específica — nada sospechoso, solo un depósito normal — tardó perceptiblemente más en procesarse que otras a su alrededor. Mi primera suposición fue congestión de red. Me pareció la explicación aburrida y obvia, y seguí adelante.
No era tan simple.
Porque Hexagate no es una búsqueda estática en listas de sanciones, como yo me lo había imaginado al principio. Son modelos de ML que evalúan continuamente la actividad on-chain y el estado del protocolo, combinando inteligencia sobre amenazas y analítica conductual para detectar patrones de riesgo en tiempo real. Eso es, fundamentalmente, un tipo de verificación distinto al de "¿está esta dirección en una lista?" Una consulta de lista es casi instantánea. La detección de patrones de comportamiento frente al estado vivo del protocolo es un cálculo, y los cálculos no tardan todos lo mismo según lo inusual o borderline que se vea la actividad en comparación con el nivel de referencia con el que se entrenó.
La presencia de monitorización ≠ velocidad de evaluación uniforme. Había asumido que una capa de seguridad o te deja pasar rápido o te bloquea; no había considerado un tercer estado, en el que en realidad todavía está decidiendo, y que esa decisión toma un tiempo variable según a qué se parezca el patrón de tu transacción.
Rastrear la cadena de dependencias lo aclaró: el depósito se inicia → Hexagate ingiere la transacción junto con el estado más amplio del protocolo → los modelos de ML comparan contra patrones de explotación conocidos, firmas de manipulación de la gobernanza y formas de ataque de flash-loan → surge una lectura de riesgo → la capa de políticas de Newton usa eso para permitir o retener la transacción → sigue la liquidación. En algún punto del paso tres, mi depósito ordinario aparentemente se pareció a algo que valía una mirada más de cerca, aunque se resolvió sin problemas unos segundos después.
La dependencia oculta en la que no había pensado es lo que “en tiempo real” cuesta computacionalmente cuando el objetivo de la detección es conductual y no categórico. Detectar ataques de flash-loan, claves comprometidas y manipulación de la gobernanza antes de que se muevan los fondos implica ejecutar inferencias contra un modelo entrenado con un rango enorme de actividad on-chain, para cada transacción, de forma continua. Eso no es gratis, y tampoco es uniforme: una transacción con una forma parecida a patrones de ataque conocidos, incluso si es inocente, probablemente requiere un pase más pesado por los modelos que una que se ve completamente rutinaria.
Me sacudieron de una posición a principios de esta semana porque leí mal un retraso y creí que el mercado se movía en mi contra, cuando en realidad era mi propio enrutamiento de órdenes, que estaba en una cola de validación más larga de lo habitual. Un sistema diferente, la misma lección: una pausa no siempre es una señal; a veces es simplemente la maquinaria trabajando más de lo esperado.
Lo que aún no logro resolver: durante un evento real de alto volumen —muchos depósitos en bóvedas, muchas entradas y salidas simultáneas, intentos de explotación reales mezclados con tráfico legítimo—, ¿la velocidad de evaluación de Hexagate se mantiene constante en todos los casos, o el tiempo de inferencia empieza a aumentar justo cuando el volumen de transacciones menos se parece a su línea base de entrenamiento, justo cuando la rapidez es más importante?