Ethereum no se creó para hacer que las finanzas sean eficientes o que las aplicaciones sean convenientes. Fue diseñado para liberar a la gente.
Esa frase del Trustless Manifesto generó críticas cuando se publicó, y Vitalik Buterin la repitió el 5 de enero.
El argumento: la misión de Ethereum difiere fundamentalmente del juego de eficiencia en el que compiten los protocolos DeFi. El objetivo no es un rendimiento del 4,5% frente al 5,3%, ni reducir la latencia de 473 milisegundos a 368, ni recortar el registro de tres clics a uno.
El juego de Ethereum es la resiliencia: evitar pérdidas totales cuando la infraestructura colapsa, los gobiernos se vuelven hostiles o los desarrolladores desaparecen. Resiliencia significa mantener una latencia de 2000 milisegundos en 2000 milisegundos incluso cuando Cloudflare falla, los patrocinadores se declaran en quiebra o los usuarios pierden la plataforma.
La resiliencia es seguir siendo un participante de primera clase independientemente de la geografía o la política.
Esto es importante porque Ethereum ancla casi $74 mil millones de valor de contrato inteligente solo en su capa 1, y más del 65% de activos tokenizados del mundo real.
Sin embargo, el sistema diseñado para ser la computadora mundial se encuentra sobre una pila sorprendentemente frágil de puntos de estrangulamiento centralizados.
El protocolo de consenso siguió finalizando bloques, pero el cliente desactualizado del proveedor de RPC provocó que los intercambios fallaran. La cadena de bloques siguió funcionando, pero la CDN se apagó, desconectando la mitad del ecosistema.
Evitar catástrofes en lugar de optimizar el rendimiento
Un informe reciente cuantifica lo que está en juego: las fallas de infraestructura producen shocks de volatilidad 5,7 veces mayores que los anuncios regulatorios en los principales criptoactivos. El riesgo extremo de pérdida total de acceso, bloqueo permanente de fondos y interrupción de la red importa más que los rendimientos incrementales.
Un protocolo que ofrece un rendimiento del 5,3% no sirve de nada si un error de configuración puede destruir la infraestructura.
El encuadre de Vitalik Buterin capta esto. La resiliencia no se trata de velocidad cuando todo funciona, sino de si su aplicación se ejecuta cuando los proveedores de infraestructura desaparecen o las plataformas de alojamiento eliminan a los usuarios.
La latencia de 2.000 milisegundos que ofrece Ethereum puede ser más lenta que la de Web2, pero sigue funcionando incluso cuando los sistemas Web2 se detienen por completo.
Aún así, la promesa de resiliencia de Ethereum enfrenta pruebas prácticas.
En noviembre de 2020, Infura, el proveedor de RPC predeterminado para MetaMask y la mayoría de las aplicaciones DeFi, ejecutó un cliente Geth obsoleto que se apartaba de la cadena canónica.
Los intercambios detuvieron los retiros de Ethereum, los exploradores mostraron estados en conflicto y MakerDAO y Uniswap rompieron para los usuarios.
Aunque el error en sí se ha solucionado y se están logrando avances en implementaciones RPC alternativas, la centralización sigue siendo la norma. Simplemente es menos exclusivo de Infura y más “pequeño cartel.”
El protocolo funcionó, pero los puntos de unión fallaron.
En noviembre de 2025, un error de configuración de Cloudflare eliminó aproximadamente el 20% del tráfico web, incluidos Arbiscan, DefiLlama y múltiples interfaces de intercambio y DeFi. Ethereum continuó procesando bloques. Los usuarios no pudieron acceder a él.
Durante la locura de las inscripciones de 2024, el secuenciador único de Arbitrum se detuvo durante 78 minutos. No se procesaron transacciones ni se publicaron lotes en Ethereum.
Arbitrum, Optimism, Base y zkSync actualmente dependen de secuenciadores únicos y centralizados. La capa base descentralizada funcionó correctamente, pero la infraestructura centralizada impidió que los usuarios se beneficiaran.
| Capa | Dependencia actual | Métrica de fragilidad | Alternativa resiliente |
|---|---|---|---|
| Acceso/RPC | Infura, Alquimia, QuickNode; MetaMask por defecto es Infura | ~90% del tráfico de aplicaciones Web3; Noviembre de 2020 La interrupción de Infura detuvo los retiros de ETH y rompió MetaMask, MakerDAO y Uniswap. | Múltiples proveedores RPC, clientes ligeros locales, clientes sin estado como estándar; Diversidad RPC como característica de cara al usuario |
| Relé / Constructor | Relés MEV-Boost (Ultra Sound, Titan, bloXroute) que median en >90 % de los bloques | Cuatro relevos controlan >85% de las propuestas; Titan, Beaverbuild y Rsync producen >80% de los bloques constructores | Más relevos por entidades distintas; neutralidad del relé; PBS consagrado donde las fallas del relé no pueden detener el espacio de bloques |
| Secuenciación L2 | Secuenciadores individuales (Arbitrum Foundation, Optimism Foundation, Coinbase for Base) | Arbitrum: tiempo de inactividad de 78 minutos; Base capta el 70,9% de los beneficios de la L2, Arbitrum el 14,9%, Optimismo el 5,4% | Conjuntos de secuenciadores descentralizados o respaldo L1; inclusión forzada cuando el secuenciador censura; pista % L2 TVL bajo control único |
| DNS/CDN | Cloudflare para almacenamiento en caché de DNS, TLS y dApps | Cloudflare ~20% de la web global; La interrupción de noviembre de 2025 eliminó las interfaces de Arbiscan, DefiLlama y Exchange/DeFi | IPFS/Arweave con respaldos de ENS; CDN múltiple; billeteras que llaman a contratos sin interfaz web |
| Protocolo básico | Consenso de Ethereum (Lighthouse 52,65%, Prysm 17,66%); ejecución (Geth ~41%, Nethermind 38%) | Septiembre de 2025 El error Reth detuvo el 5,4 % de los nodos; la diversidad impidió un impacto más amplio | Ningún cliente >33% de participación; apuesta por la vivienda; minimizar las fallas correlacionadas; verificación fácil de cliente ligero/sin estado |
El protocolo base demuestra una resiliencia genuina, con múltiples clientes, cientos de miles de validadores y prueba de participación que distribuye el riesgo entre diversas bases de código.
Cuando Reth sufrió un error en septiembre de 2025, detuvo el 5,4 % de los nodos, pero la continuidad de la red se mantuvo porque Geth, Nethermind y Besu continuaron. La diversidad de clientes funcionó.
El problema se concentra arriba: el acceso RPC, los relés, los secuenciadores y las interfaces web introducen dependencias que deshabilitan el acceso de los usuarios incluso cuando la capa base funciona.
Aquí es donde se rompe la resiliencia de Ethereum: no en la criptografía o el consenso, sino en el andamiaje que conecta a los usuarios con el protocolo.
Secuenciadores centralizados como puntos de estrangulamiento económicos
Los secuenciadores de capa 2 concentran tanto el control como las ganancias. Base capturó más del 50% de todas las ganancias acumuladas de manera constante durante 2025, seguida de Arbitrum.
El secuenciador de Arbitrum está administrado por la Fundación Arbitrum, el de Optimism por la Fundación Optimism, el de Base por Coinbase y el de zkSync está centralizado.
Como resultado, más del 80% de las tarifas capturadas por la capa 2 de Ethereum en 2025 fluyeron a cadenas de bloques con secuenciadores centralizados.
El camino técnico existe: redes de secuenciadores compartidos como Espresso, o paquetes acumulativos basados que devuelven la secuenciación a los validadores de Ethereum. Astria intentó diseños similares pero cerró en 2025.
La brecha no es técnica, sino económica. Los secuenciadores centralizados ofrecen una mejor experiencia de usuario y generan ingresos sustanciales. La resiliencia requiere aceptar que un secuenciador que produce confirmaciones ligeramente más lentas, pero imposible de apagar por un solo operador, supera las mejoras de milisegundos con un control de un solo punto.
Dependencias de RPC y CDN
MetaMask por defecto es Infura. Los informes señalan que la mayoría de las aplicaciones Web3 utilice Infura, Alchemy o QuickNode.
El incidente de Infura de noviembre de 2020 demostró la consecuencia: la resiliencia a nivel de protocolo se volvió irrelevante cuando falló la capa de acceso.
La interrupción de Cloudflare en noviembre de 2025 reveló cuánto dependen las “finanzas descentralizadas” de la CDN de una corporación. Ethereum procesó los bloques normalmente, pero los usuarios no pudieron acceder a las interfaces, exploradores o paneles de control.
Las alternativas resistentes incluyen billeteras que utilizan de forma predeterminada múltiples RPC, clientes ligeros locales, almacenamiento distribuido en IPFS o Arweave, direccionamiento ENS e implementaciones de múltiples CDN.
Sin embargo, esto impone costos, como una mayor complejidad, mayores requisitos de ancho de banda y una gestión más compleja.
La mayoría de los proyectos eligen la conveniencia, razón por la cual la compensación por la eficiencia es importante. La capa base de Ethereum proporciona propiedades de supervivencia, mientras que el ecosistema las envuelve principalmente en dependencias que reintroducen cada fragilidad.
La compensación real
La propuesta de valor de Ethereum, tal como la plantea Buterin, no es más rápida, más barata ni más conveniente. Está funcionando cuando todo lo demás se estropea.
Eso requiere opciones de infraestructura que prioricen la supervivencia sobre la optimización: múltiples implementaciones de clientes cuando uno es técnicamente superior, diversos proveedores de RPC cuando uno ofrece mejor latencia, secuenciadores descentralizados cuando los operadores centralizados entregan confirmaciones más rápidas y front-end distribuidos cuando el alojamiento centralizado es más simple.
La industria no ha aceptado esta compensación. Los paquetes acumulativos se optimizan para UX y aceptan el riesgo de un solo secuenciador. Las aplicaciones utilizan de forma predeterminada RPC convenientes y aceptan el riesgo de concentración. Los front-end se implementan en CDN comerciales y toleran fallas de un solo proveedor.
La elección: construir para el caso en que Cloudflare, Infura y Coinbase sigan funcionando, o construir para cuando no lo hagan.
La capa base de Ethereum permite la segunda opción. El ecosistema circundante ocupa abrumadoramente el primer lugar.
El protocolo proporciona una latencia de 2000 milisegundos que persiste a través de fallas de infraestructura, desmontaje de plataformas y perturbaciones geopolíticas.
El hecho de que alguien construya sistemas que realmente aprovechen esa propiedad en lugar de envolverla en dependencias que reintroduzcan todas las fragilidades que Ethereum fue diseñado para eliminar determina si la resiliencia se vuelve real o sigue siendo teórica.
El espacio en bloques es abundante. El espacio de bloques descentralizado, sin permisos y resistente no lo es.