Ethereum ha mantenido una producción ininterrumpida de bloques durante más de una década al separar la creación de bloques de la liquidación final, un diseño que permite a la red sobrevivir a fallos de validadores y errores de cliente sin detenerse.
Atrás
El uptime de 10 años de Ethereum se basa en un compromiso de consenso de dos capas
El investigador de Ethereum Luca Zanolini explicó cómo la arquitectura de consenso de dos capas de la red separa la producción de bloques de la liquidación final, una estructura que ha mantenido el flujo de transacciones durante más de 10 años.
"El protocolo solo castiga lo que puede probar", escribió Zanolini, describiendo cómo la capa de finalidad de Ethereum protege el historial liquidado mediante votos firmados de validadores, mientras que la capa de producción continúa añadiendo bloques independientemente.
La distinción se hizo visible en mayo de 2023, cuando fallos de cliente interrumpieron la finalidad dos veces en 24 horas — la primera interrupción duró unos 25 minutos y la segunda cerca de una hora. Los bloques siguieron llegando, las transacciones permanecieron disponibles y la red se recuperó sin necesidad de un reinicio coordinado. Un fallo de Prysm tras la actualización Fusaka en diciembre de 2025 redujo la participación de validadores a aproximadamente el 75%, lo que provocó que la red perdiera 41 épocas y los validadores perdieran cerca de 382 ETH en recompensas, pero otros clientes siguieron funcionando y Ethereum evitó perder la finalidad.
Zanolini señaló que una detención en la capa base congelaría más que las transferencias de tokens: las plataformas de préstamo no podrían procesar liquidaciones, los oráculos no podrían actualizar precios, los rollups no podrían publicar datos y los puentes no podrían confirmar nuevo estado. El equipo de Protocol Consensus de la Ethereum Foundation ahora estudia formas de reducir el tiempo de finalidad de las dos épocas actuales, con Vitalik Buterin respaldando Minimmit, un sistema de finalidad de una sola ronda propuesto que podría liquidar bloques más rápido, aunque su diseño actual acepta una tolerancia a fallos formal menor que Casper FFG.
Cómo las Fugas de Inactividad Restauran la Finalidad Sin un Hard Fork
Cuando la finalidad permanece indisponible durante más de cuatro épocas, Ethereum activa una fuga de inactividad. Los validadores desconectados pierden gradualmente su participación efectiva, con penalizaciones que aumentan durante una interrupción prolongada. Esto desplaza el equilibrio de votación hasta que los validadores participantes vuelven a controlar suficiente participación para finalizar la cadena automáticamente. Zanolini describió esta ruta de recuperación como una parte central del diseño de Ethereum, porque el protocolo puede volver a la finalidad sin esperar a que cada validador desconectado se reconecte.
La Diversidad de Clientes Limita el Alcance de los Errores Compartidos
El modelo de Ethereum se vuelve más frágil cuando un solo cliente de consenso controla demasiada participación. Un cliente por encima de un tercio puede amenazar la finalidad durante un fallo importante. El control por encima de la mitad puede distorsionar la elección de bifurcación, mientras que un cliente por encima de dos tercios podría ayudar a finalizar un historial inválido antes de que los operadores puedan reaccionar. El incidente de Prysm en diciembre de 2025 demostró esta dinámica: el fallo redujo la participación al 75%, pero debido a que otros clientes continuaron operando, la red evitó perder la finalidad por completo.
Lo que Está en Juego
El análisis de Zanolini presenta la resiliencia de Ethereum como un conjunto de elecciones vinculadas. Los bloques continuos preservan el acceso, la finalidad protege el historial liquidado, el slashing castiga la mala conducta demostrable, las penalizaciones por inactividad respaldan la recuperación automática y los múltiples clientes reducen el alcance de un error compartido en la red más amplia de validadores. Una propuesta de investigación de marzo sugirió utilizar un comité muestreado para bloques más rápidos mientras un proceso separado finaliza la cadena detrás de él, permitiendo que ambos sistemas utilicen diferentes configuraciones de sincronización y seguridad.
Este artículo es solo para fines informativos y no constituye asesoramiento de inversión.
Características
© 2026 Edgen impulsado por