Cuando un archivo de características hizo tropezar a Internet

Un mal artefacto del plano de control, un plano de datos frágil y errores 5xx por todas partes

Esta publicación explica cómo pensamos sobre incidentes como la caída de Cloudflare de esta semana, por qué los planos de control de Smart Contract puros con timelocks cambian los modos de fallo, y dónde encajan las Pruebas de conocimiento cero.

Resumen de la caída del martes

El 18 de noviembre de 2025 a las 11:20 UTC, el borde de Cloudflare comenzó a devolver errores 5xx para una gran parte del tráfico. El desencadenante principal no fue un atacante; fue un cambio de permisos en ClickHouse que hizo que una consulta devolviera filas duplicadas. Esa consulta generó un "archivo de características" de Bot Management que se enviaba a cada caja de borde cada pocos minutos.

Los duplicados duplicaron el tamaño del archivo y elevaron el recuento de características por encima de 200. El módulo de bot tenía un límite estricto y un unwrap() que entraba en pánico en caso de desbordamiento. A medida que los nodos alternaban entre salidas "antiguas-buenas" y "nuevas-malas" cada cinco minutos, la flota oscilaba hasta que todos los fragmentos se actualizaron y permanecieron malos.

Cloudflare detuvo el publicador a las 14:24, envió un archivo del último estado bueno conocido a las 14:30, e informó de una recuperación completa a las 17:06. Los seguimientos que enumeraron: fortalecer la ingesta de configuración interna, añadir interruptores globales de apagado y revisar los modos de fallo en todos los módulos.

Consulta el post-mortem de Cloudflare para ver la cronología completa y fragmentos de código.

Hay dos problemas separados en esa historia:

1. Fallo del plano de control: un generador emitió un artefacto fuera de especificación (duplicados, demasiadas características, demasiado grande).
2. Fragilidad del plano de datos: el consumidor se bloqueó en lugar de degradarse con elegancia.

Todavía puedes arreglar el (2) en revisiones de código. Pero (1) es donde brillan las blockchains: como una puerta programable y a prueba de manipulaciones frente a los despliegues.

"Configuración con prueba incorporada" en una blockchain pública

Si comprimes la idea en una frase: ninguna configuración se convierte en "actual" a menos que un Smart Contract lo diga, y el contrato solo cambia esa bandera después de un timelock y una prueba de que el artefacto obedece invariantes. Esa frase implica una arquitectura completa.

Resulta que las blockchains públicas, especialmente construidas sobre Ethereum, las cadenas EVM que ejecutan la Máquina Virtual Ethereum y la capa de consenso, ofrecen una buena solución a ese problema.

Un Registro de Configuración en cadena como puerta de promoción

• Un Smart Contract en un EVM rápido y creíble (a menudo una L2) registra cada artefacto candidato y compromisos con cualquier prueba.
• Las escrituras están controladas por un timelock y un multisig; un interruptor de pausa/apagado y un puntero de rollback son de primera clase.
• Solo los hashes o incluso los scripts completos pueden ir en cadena. Si está fuera de la cadena, el blob vive en un almacén de objetos pero proporcionará menos garantías. Una gran idea si no es posible estar completamente en cadena debido al tamaño, y cuando los datos son temporales, es usar blobs EIP-4844. Aunque es un almacenamiento separado, puedes emparejar un hash verdaderamente en cadena y un blob con 18 días de retención, lo cual es excelente para una ventana de rollback continua.

Ajuste de latencia. Ethereum finaliza en épocas, pero las L2 confirman en segundos (OP Stack apunta a ~2s; zkSync ~1s; muchos sistemas exponen atestación rápida). Es suficiente para cadencias de plano de control de cinco minutos, ver por ejemplo la discusión sobre el tiempo de bloque de OP o los tiempos de atestación de Circle).

Pruebas obligatorias: hacer inteligente la puerta

Adjunta una prueba sucinta con cada artefacto y verifica en cadena. ¡Eso es exactamente lo que hacemos para nuestro protocolo Chainwall, aunque para un tipo diferente de datos!

El objetivo principal es probar propiedades básicas: row_count <= 200, ordenado + único por clave, el esquema coincide con regex y reglas de tipo, tamaño de archivo <= N. Puedes ajustar toda la lógica en cadena o confiar en circuitos Plonk/Groth para expresiones más grandes. Por ejemplo, un invitado zk-VM puede analizar CSV/Parquet/JSON y emitir un SNARK. No tienes que revelar el contenido, solo el compromiso. Existen sistemas de investigación y producción para regex en ZK (por ejemplo, Reef y trabajo relacionado con zk-regex), lo que hace que las comprobaciones de esquema sean realistas.

Hay dos caminos prácticos:

• Ruta zkVM: Ejecuta tu verificador dentro de un zkVM y verifica los recibos en cadena; consulta los contratos de verificador RISC Zero y el envoltorio de prueba en cadena SP1 de Succinct.
• Ruta de circuito: Pequeños circuitos fijos para los invariantes anteriores; para CSV/JSON + regex puedes combinar gadgets de análisis con técnicas zk-regex.

Distribución que no introduce nueva confianza

Los bordes consultan el registro y solo adoptan artefactos que están autorizados en cadena. Para evitar confiar en un RPC de terceros, ejecuta un cliente ligero en tu plano de control (por ejemplo, Helios) o planifica para la Red Portal. De esa manera, los bordes verifican los encabezados y las pruebas de inclusión localmente antes de aceptar cualquier estado "nuevo actual".

El interruptor de apagado y rollback son solo bits en el contrato, respetados por el borde. Cloudflare mencionó explícitamente la necesidad de interruptores globales de apagado más fuertes; poner ese interruptor en un contrato pequeño y auditado te da una única fuente de verdad bajo estrés.

¿Esto realmente habría cambiado el fallo de CloudFlare?

• El archivo inflado por duplicados supera un límite de recuento/tamaño que se aplica mediante una prueba, no por mejor esfuerzo. La promoción falla.
• Incluso si alguien cargara manualmente el blob al almacenamiento, los bordes se negarían a adoptarlo sin la bandera "actual" en cadena y la verificación de prueba.
• Todavía arreglas el pánico en el proxy, pero has movido el borde más afilado del riesgo a un dominio donde los sistemas de prueba y los timelocks son muy buenos.

Por qué insistimos en planos de control puramente en cadena para activos digitales

El evento de CloudFlare no fue un ataque, ¡pero inicialmente pensaron que lo era y de hecho era probable! Como hemos visto en la seguridad cripto: los atacantes no solo persiguen claves; coaccionan el plano de control.

• Manipulación de front-end o UI de firmante: El robo de Bybit mostró cómo manipular lo que ven los firmantes puede impulsar una aprobación catastrófica. Los análisis apuntan al phishing y la manipulación de UI del flujo de aprobación de transacciones, no a una explotación de Smart Contract. Lee la nota técnica del Grupo NCC y la cobertura de Ledger Insights.
• Autoridad de API de terceros: SwissBorg/Kiln no fue un error de solidity; fue una ruta API fuera de cadena que permitió a un atacante reorganizar las autoridades de staking y drenar ~193k SOL como se explica en la declaración conjunta de Kiln.
• Del portátil del desarrollador a las credenciales en la nube a todo: Lazarus/TraderTraitor sigue demostrando que las máquinas de desarrolladores comprometidas y los flujos de compilación engañados te compran puntos de apoyo en la nube y el poder de doblar lo que el equipo ve y firma. Ver por ejemplo el aviso de CISA o la simulación de Elastic sobre cómo se filtran las credenciales de AWS desde las máquinas de desarrollo.

Conclusión

Nuestra posición: el control de los activos digitales debe residir en Smart Contracts protegidos por timelocks y multisigs, no en credenciales privadas, tokens CI, ACLs en la nube o paneles de administración. Si tu despliegue o acción de "cambio de propietario" debe atravesar la ruta schedule() y execute() de un contrato, incluso un rootkit en un portátil de desarrollador no puede saltarse la cola. El retraso de tiempo es un disyuntor con el que puedes contar, y la pista de auditoría en cadena es objetiva. Eso solo deja la pregunta "¿qué pasa si lo que estamos promoviendo está malformado?", que es exactamente lo que responde la "configuración con prueba incorporada".

También creemos que hay un mercado considerable para aplicaciones con confianza minimizada. Solo estamos construyendo los cimientos correctos ahora para un primer caso de uso bien definido en OKcontract Labs.

---

Cuando un archivo de características hizo tropezar a Internet fue publicado originalmente en Coinmonks en Medium, donde la gente continúa la conversación destacando y respondiendo a esta historia.