El 20 de octubre, un contratiempo en la región EE.UU. ESTE-1 de Amazon desencadenó una reacción en cadena en toda la industria de la criptografía. Coinbase informó un servicio degradado, Infura y Alchemy publicaron notas de incidentes relacionados con AWS y varias billeteras y paquetes acumulativos comenzaron a agotarse.
Ninguna de estas fallas provino de las propias cadenas de bloques. El consenso estuvo bien. El problema era todo lo que lo rodea: las bases de datos en la nube, las puertas de enlace RPC, los DNS, los indexadores y los sistemas de administración de claves que convierten una cadena de bloques en una aplicación utilizable.
Fue un claro recordatorio de que gran parte de Web3 todavía depende en gran medida de Web2. Cuando una región de AWS estornudó, una cuarta parte de la interfaz de usuario de las criptomonedas se resfrió.
El monocultivo invisible
Detrás de la retórica de la descentralización se esconde un silencioso mapa de dependencia que parece sorprendentemente centralizado. Una dApp típica comienza con una interfaz alojada en S3 o Cloudflare Pages, servida a través de una CDN como Fastly y resuelta por Route 53 o Cloudflare DNS.
Debajo se encuentran los RPC de lectura y escritura, a menudo Infura, Alchemy o QuickNode, la mayoría de los cuales se ejecutan en AWS u otra de las “tres grandes” nubes. Luego vienen indexadores como The Graph o Covalent, servicios de secuenciación en rollups y sistemas de custodia o gestión de claves como Fireblocks. Cada capa introduce un único punto de falla.
Cuando los servicios DynamoDB y DNS de AWS fallaron, varias capas se vieron afectadas simultáneamente. La API de Coinbase se desaceleró, Infura y Alchemy informaron problemas de AWS y varios paquetes acumulativos vieron sus secuenciadores detenerse hasta la intervención manual. Incluso el indexador de The Graph para zkSync ya había mostrado una fragilidad similar semanas antes.
La ilusión de redundancia también se rompió. Dos proveedores de RPC independientes prometen cada uno un tiempo de actividad de “cuatro nueves”, pero si ambos están en la misma región de la nube, sus fallas están correlacionadas. Estadísticamente, la independencia colapsa: el coeficiente de correlación efectivo entre pilas centradas en AWS puede llegar a 0,9.
Esta concentración no se limita a las criptomonedas. AWS todavía posee aproximadamente entre el 30% y el 32% de la participación global en la nube, Azure alrededor del 20% y Google Cloud el 13%. Una interrupción de seis horas en una región importante afecta a los servicios de DNS, almacenamiento de objetos y bases de datos utilizados por miles de empresas.
Para las aplicaciones criptográficas, esto significa que entre el 10 % y el 30 % de las interfaces o funciones de lectura basadas en EVM pueden degradarse durante dicho evento. Las escrituras y transacciones que dependen de secuenciadores o rutas de firma de custodia pueden congelarse por completo.
El mito de la independencia
Es fácil combinar la resiliencia en cadena con la resiliencia de las aplicaciones. Las cadenas de bloques como Ethereum o Solana pueden mantener el consenso a través de nodos globales; sin embargo, las herramientas que la gente realmente utiliza a menudo dependen de intermediarios centralizados. La parada de cinco horas de Solana en febrero de 2024 fue una falla en la cadena, pero la interrupción de AWS no lo fue. Era uno fuera de la cadena y mucho más común.
Cada capa añade su propio talón de Aquiles.
- Los secuenciadores en L2 siguen siendo en su mayoría configuraciones de un solo operador. Si su conexión con el RPC de Ethereum se interrumpe, también se interrumpe su capacidad para publicar nuevos lotes.
- La entrega de contenido y el DNS introducen una mayor fragilidad: el problema de resolución de Cloudflare del 14 de julio dejó partes de Internet inaccesibles durante casi una hora.
- Incluso el almacenamiento “descentralizado” puede depender de una sola empresa. La interrupción de la puerta de enlace IPFS de Infura el 20 de septiembre detuvo el acceso a los activos que teóricamente estaban reflejados en toda la red.
- Las plataformas de custodia y gestión de claves, como Fireblocks, utilizadas por las bolsas y los fondos, experimentaron retrasos en el procesamiento el 26 de octubre y el 17 de septiembre, lo que paralizó los retiros y las liquidaciones.
Estas fallas son importantes porque afectan la confianza del usuario más que el tiempo de actividad del protocolo. Una billetera que muestra un saldo obsoleto o una transacción puente atrapada en el limbo erosiona la confianza en la descentralización que dice ofrecer.
Los reguladores han empezado a darse cuenta. La Ley de Resiliencia Operacional Digital (DORA) de la UE, vigente desde enero de 2025, obliga a las entidades financieras a probar e informar sobre las dependencias de TIC de terceros. Se espera que el régimen de “Terceros Críticos” del Reino Unido ponga a los hiperescaladores bajo supervisión directa el próximo año.
Dado que la custodia de criptomonedas, los emisores de monedas estables y las plataformas de activos tokenizados ahora se superponen con las finanzas reguladas, las mismas expectativas para la diversificación de la nube pronto se aplicarán aquí también. La dependencia de la nube de un solo proveedor se está convirtiendo en un riesgo a nivel de junta directiva.
La solución no es glamorosa, pero está por llegar
Las soluciones se están enviando. A corto plazo, los desarrolladores están introduciendo RPC de quórum de proveedor que consultan múltiples puntos finales, autohospedados, SaaS y descentralizados (como Pocket Network), y muestran un resultado solo si dos de tres están de acuerdo. Herramientas como Helios llevan la verificación ligera del cliente directamente a billeteras y aplicaciones móviles, lo que permite a los usuarios validar datos sin depender de una puerta de enlace centralizada.
Los equipos de infraestructura están adoptando configuraciones de múltiples CDN y múltiples DNS con conmutación por error activa. Para el almacenamiento, ejecutar la propia puerta de enlace IPFS o duplicar los activos en Arweave o Irys se está convirtiendo en un estándar. En el mundo acumulativo, proyectos como Espresso, Radius y Astria están creando secuenciadores compartidos o descentralizados, mientras que OP Stack ha comenzado a implementar pruebas de fallas sin permiso.
Más adelante en la hoja de ruta, la propuesta PeerDAS de Ethereum tiene como objetivo hacer que las comprobaciones de disponibilidad de datos sean lo suficientemente asequibles como para ejecutarse a nivel de billetera. Combinado con clientes ligeros, esto podría impulsar la verificación hacia los bordes de la red en lugar del centro de la nube.
La presión institucional reforzará estos cambios. Según las reglas de DORA y CTP del Reino Unido, las arquitecturas de múltiples nubes se están convirtiendo en una política, no en una preferencia. Espere que los grandes custodios e intercambios exijan la diversificación de proveedores entre RPC, indexadores y proveedores de administración de claves.
Nada de esto hará que las criptomonedas sean completamente independientes de la infraestructura tradicional, pero reducirá la brecha entre los ideales de descentralización y la confusa realidad operativa. La lección del 20 de octubre no es que las cadenas de bloques fallaron, sino que el andamiaje de soporte aún no se ha puesto al día.
Una aplicación verdaderamente descentralizada no significará que cada usuario ejecute un servidor; significará que ningún servidor podrá desactivar el sistema. Hasta que esa sea la opción predeterminada, cada interrupción de “Web3” comenzará de la misma manera: cuando la nube estornuda, la cadena de bloques se estremece.