La ilusión de la descentralización: Cómo un error en la base de datos de una sola empresa expuso la fragilidad de la infraestructura de las criptomonedas

El 18 de noviembre de 2025, aproximadamente el 20% de internet se desconectó—no por un ciberataque, sino por una actualización rutinaria de permisos en la base de datos que activó un error oculto en Cloudflare, una empresa que “protege” internet de este tipo de fallos.

En cuestión de minutos, comenzó la cascada: Twitter se cayó a mitad de un tuit, ChatGPT se congeló, Spotify dejó de transmitir. ¿Y en el espacio cripto? Las plataformas de trading se apagaron, los exploradores de blockchain fallaron, las interfaces de las wallets devolvieron errores 500. Durante cinco horas y media, la industria que se posicionó como resistente a la censura e imparable se encontró completamente detenida.

¿La cruel ironía? Las propias blockchains seguían funcionando perfectamente. Bitcoin minaba bloques. Ethereum procesaba transacciones. Sin fallos de consenso, sin colapsos en el protocolo. Los usuarios simplemente no podían acceder a lo que supuestamente “poseían”.

Lo que realmente ocurrió: un tropiezo técnico con alcance catastrófico

Cloudflare no aloja sitios web ni vende potencia de computación como otros grandes proveedores de la nube. En cambio, actúa como controlador del tráfico de internet—interponiéndose entre los usuarios y los servicios en 120 países. La compañía procesa aproximadamente el 20% del tráfico global de internet a través de su red mundial.

El 18 de noviembre a las 11:05 UTC, Cloudflare realizó un cambio aparentemente rutinario en su clúster de bases de datos ClickHouse. El objetivo era razonable: mejorar la seguridad y fiabilidad actualizando los controles de acceso. Pero aquí es donde la pseudo-resiliencia de la infraestructura moderna se desplomó.

La consulta a la base de datos que generaba las configuraciones de protección contra bots no incluía un filtro para los nombres de las bases de datos. Esto significaba que la consulta empezó a devolver entradas duplicadas—una del base de datos por defecto, otra del nivel de almacenamiento subyacente. El archivo de configuración se duplicó de repente en tamaño, pasando de aproximadamente 60 características a más de 200.

Los ingenieros de Cloudflare habían establecido un límite fijo en 200 características, pensando que esto superaba cómodamente su uso real. Lógica clásica de ingeniería: establecer un margen de seguridad generoso y asumir que nunca se superará. Hasta que sí.

El archivo sobredimensionado colapsó el sistema de protección contra bots—un componente clave de toda la capa de control de Cloudflare. Cuando un sistema falla, los sistemas dependientes también siguen. El sistema de monitoreo de salud que indica a los balanceadores de carga “qué servidores están operativos” también falló. El tráfico seguía llegando a los nodos de borde de Cloudflare, pero no había forma de enrutarlo.

Durante las primeras horas, los ingenieros pensaron que estaban bajo un ataque masivo de denegación de servicio distribuido. El sistema alternaba entre “funcionando” y “totalmente roto” cada cinco minutos, mientras la configuración problemática se regeneraba. Pero no había ataque—solo un filtro de base de datos ausente y una suposición que resultó ser falsa.

A las 17:06 UTC, se desplegó la configuración correcta a nivel global. Se restauró el servicio. La crisis se evitó.

La industria cripto no puede celebrar—se expuso

Mientras las plataformas Web2 sufrían primero y de manera más visible—interrupciones en Spotify, desconexiones en sesiones de juego, caídas en sistemas de entrega de comida—el mundo cripto enfrentaba una verdad más incómoda.

Varias plataformas de intercambio no pudieron cargar. Los exploradores de blockchain se desconectaron. Los servicios de wallets fallaron. Las interfaces de trading mostraron mensajes de error. Y toda la industria quería publicar al respecto en Twitter—solo para descubrir que Twitter también estaba caído.

Esto creó un silencio peculiar. Durante la caída de AWS en octubre, el cripto Twitter pasó horas burlándose de la “fragilidad de la infraestructura” y del “riesgo de centralización”. ¿Y esta vez? Nadie pudo burlarse de nada. La plataforma que usas para criticar los puntos únicos de fallo es en sí misma un punto único de fallo.

Aquí está la parte incómoda: los protocolos de blockchain en sí nunca se vieron afectados. Las transacciones podían procesarse en la cadena. El consenso continuaba. Toda la base técnica de la “finanza sin confianza y resistente a la censura” funcionaba exactamente como fue diseñada.

Pero no importaba. Porque sin acceso, una blockchain funcional es solo un registro histórico que nadie puede leer.

El patrón que nadie está rompiendo: Cuatro grandes caídas, el mismo problema subyacente

• Julio 2019: caída de Cloudflare. Coinbase fuera de línea, datos de mercado inaccesibles.
• Junio 2022: otra falla de Cloudflare. Varias plataformas cripto suspenden servicios.
• 20 de octubre de 2025: caída de AWS de 15 horas. Fallos en DynamoDB en cascada por servicios dependientes.
• 18 de noviembre de 2025: otra vez Cloudflare. Cinco horas y media de interrupción generalizada.

Cuatro incidentes importantes en aproximadamente 18 meses. La lección debería ser obvia: la infraestructura centralizada genera fallos centralizados.

Y sin embargo, la industria no la ha aprendido.

Por qué la “Descentralización” sigue siendo un término de marketing más que una realidad técnica

La industria cripto construyó toda su filosofía sobre una premisa: eliminar intermediarios, remover puntos únicos de fallo, crear sistemas que no puedan ser detenidos.

La realidad es diferente.

La “cadena de dependencia de infraestructura” actual del cripto parece una broma que alguien tiene miedo de contar:

• Los exchanges principales dependen de Amazon Web Services
• El DNS y la entrega de contenido dependen de Cloudflare
• Los exploradores de blockchain dependen de Cloudflare
• Las plataformas de análisis dependen de Cloudflare
• Las interfaces de wallets dependen de infraestructura centralizada similar

Así que cuando Cloudflare actualiza una configuración de base de datos y rompe su protección contra bots, toda la industria—supuestamente construida para evitar este escenario—se cae.

La pseudo-descentralización se vuelve evidente: la capa de protocolo está realmente distribuida, pero la capa de acceso está limitada por tres empresas que controlan aproximadamente el 60% de la infraestructura en la nube (Amazon Web Services con un 30%, Microsoft Azure con un 20%, Google Cloud con un 13%).

Tres empresas. Dos de ellas sufrieron caídas en el mismo mes. Eso no es redundancia—es fragilidad concentrada.

La economía de la negligencia

¿Por qué sigue ocurriendo esto? ¿Por qué las plataformas cripto no construyen infraestructura asumiendo que ocurrirán caídas?

La respuesta es desalentadoramente sencilla: es caro y complejo.

Construir tu propia infraestructura implica comprar hardware, garantizar estabilidad eléctrica, mantener ancho de banda dedicado, contratar especialistas en seguridad, establecer redundancia geográfica, diseñar recuperación ante desastres y ofrecer monitoreo 24/7. Requiere capital significativo y gastos operativos continuos.

Usar Cloudflare solo requiere ingresar un número de tarjeta de crédito y desplegar en minutos.

Las startups priorizan la velocidad de lanzamiento. Los inversores exigen eficiencia de capital. Todos eligen la conveniencia sobre la resiliencia.

Hasta que la conveniencia se vuelva profundamente inconveniente—y aparentemente, incluso cuatro caídas importantes en 18 meses no sean suficientes para cambiar el comportamiento.

Existen alternativas descentralizadas: Arweave para almacenamiento, IPFS para transferencia de archivos distribuida, Akash para recursos de computación, Filecoin para hosting descentralizado. Ninguna ha logrado una adopción significativa porque son más lentas, más complejas y a menudo más caras que las alternativas centralizadas.

La industria hace caso omiso a la descentralización, eligiendo sistemáticamente soluciones centralizadas cada vez que surge un verdadero compromiso entre principio y conveniencia.

Lo que ven los reguladores—y por qué empiezan a prestar atención

Tres caídas importantes en 30 días han llamado la atención de los responsables políticos, que ahora ven lo que debería haber sido obvio: unas pocas empresas tecnológicas pueden desactivar infraestructura crítica.

Las preguntas que se hacen:

• ¿Las empresas que controlan el 20% del tráfico global de internet califican como “instituciones de importancia sistémica”?
• ¿Debería regularse la infraestructura de internet como servicios públicos?
• ¿Qué pasa cuando “demasiado grande para fallar” aplica a plataformas tecnológicas?
• ¿Dónde está la redundancia cuando las caídas en cascada afectan a proveedores supuestamente independientes?

Durante fallos anteriores de infraestructura, los expertos en política fueron explícitos: cuando un solo proveedor falla, los medios se vuelven inalcanzables, las comunicaciones seguras dejan de funcionar y la infraestructura que sustenta la sociedad digital colapsa.

Los gobiernos reconocen que la concentración de infraestructura de internet crea riesgos sistémicos.

Pero la regulación por sí sola no resolverá esto. La verdadera solución requiere que la industria adopte voluntariamente infraestructura descentralizada—un cambio que solo ocurrirá cuando el dolor de las fallas centralizadas supere la conveniencia de soluciones centralizadas.

La pregunta que nadie quiere responder

La industria cripto no “falló” el 18 de noviembre. Los protocolos de blockchain continuaron operando. Los nodos mantuvieron el consenso. Las transacciones seguían siendo válidas.

La autopercepción colectiva de la industria fracasó.

El engaño consiste en creer que:

• Puedes construir aplicaciones “imparables” sobre infraestructura “parable”
• La “resistencia a la censura” significa algo cuando tres empresas controlan el canal de acceso
• La “descentralización” es real cuando un solo archivo de configuración de Cloudflare determina si millones pueden transaccionar
• Los “sistemas sin confianza” funcionan cuando la confianza se externaliza en intermediarios centralizados

Si una blockchain sigue produciendo bloques pero los usuarios no pueden enviar transacciones, ¿está realmente funcionando? Técnicamente sí. ¿Prácticamente? No.

La industria no tiene un plan de contingencia para lo que pasa cuando la infraestructura falla en el momento equivocado—durante un desplome del mercado cuando cada segundo cuenta, o cuando los sistemas de verificación de identidad están offline simultáneamente.

La estrategia actual de “recuperación ante desastres” de la industria es simple: esperar a que Cloudflare arregle el problema. Esperar a que AWS restaure el servicio. Esperar a que Microsoft despliegue un parche. Esperar que la caída no coincida con un momento crítico del mercado.

Esto no es un plan. Es parálisis disfrazada de continuidad del negocio.

La certeza de la próxima vez

La caída del 18 de noviembre será seguida por otra falla de infraestructura. Podría originarse en AWS, Azure, Google Cloud, o en otro cambio de configuración de Cloudflare.

Podría ocurrir el mes que viene. La próxima semana.

La infraestructura subyacente no ha cambiado. Las dependencias no han cambiado. Los incentivos de la industria permanecen iguales—las soluciones centralizadas siguen siendo más baratas, rápidas y convenientes que las alternativas distribuidas.

Nada estructural impedirá la próxima falla porque evitarla requeriría invertir en complejidad y redundancia que no ofrecen beneficios visibles hasta que sean necesarios.

Cuando ese momento llegue—cuando la caída cruce con un evento crítico del mercado, o sistemas de identidad, o el momento en que el daño financiero máximo pueda ocurrir—la industria volverá a descubrir que la “descentralización” sigue siendo una filosofía más que una arquitectura.

Y quienes construyeron aplicaciones asumiendo que la infraestructura siempre estaría disponible aprenderán por las malas que esa suposición fue construida sobre arena.