-
El porcentaje de nodos activos cayó por debajo del “66%”, afectando el procesamiento de bloques.
-
Las causas fueron retrasos en la inclusión de bloques y sobrecarga en los nodos.
La implementación de la próxima actualización de Ethereum, conocida como Fusaka, comenzó con «algunas turbulencias», según explicaron los desarrolladores que participaron de la 166ª reunión de “Capa de Consenso de Desarrolladores Principales de Ethereum” (ACDC, por sus siglas en inglés) el 2 de octubre.
Fusaka empezó a probarse el 1 de octubre en Holesky, la red de pruebas (testnet) de Ethereum. Conforme al reporte, si bien «la activación del fork en Holesky fue bien en general», se presentaron inconvenientes.
De acuerdo con lo descrito, Fusaka entró en un estado de «no-finalidad durante aproximadamente dos días, luego se recuperó y reanudó la finalización».
La expresión «no-finalidad» significa que las transacciones y bloques no alcanzan un estado irreversible durante un periodo prolongado, lo que puede comprometer la seguridad temporal de la red.
Es decir que, durante las primeras horas de Fusaka en la red de pruebas, las transacciones y los bloques no consiguieron un estado definitivo que permita que no sean revertidos.
Seguidamente, el informe de los desarrolladores agrega que «inicialmente la participación cayó debido a actualizaciones de clientes no aplicadas» hasta caer a un porcentaje «por debajo del 66% y luego se recuperó».
La participación se refiere al porcentaje de los nodos validadores que están activos en la red. Al haber caído esa participación a cifras menores del “66%” se vio afectada la finalización de bloques.
Pese a las «turbulencias» explicadas, este tipo de conflictos suelen verse en fases tempranas de prueba.
De hecho, como lo informó CriptoNoticias en el debut de Pectra (la actualización anterior de Ethereum) en Holesky, episodios similares ya se habían registrado, reflejando el carácter experimental y de ajuste propio de estas etapas.
¿Cuáles fueron las causas de los problemas en Fusaka en Ethereum?
Entre las causas posibles de los problemas detectados, los desarrolladores señalaron tres factores: retrasos en la inclusión de bloques, sobrecarga de procesamiento en los nodos y un volumen inusual de datos que podría haber saturado la red de pruebas.
Estos elementos combinados pueden reducir la capacidad de la red para validar y confirmar transacciones de forma estable.
El informe también menciona que en Holesky muchos validadores gestionan unas 10.000 claves de firma o validación cada uno. Esta alta carga por servidor puede influir en el rendimiento y aumentar la probabilidad de fallos temporales.
Los colaboradores de Ethereum también estimaron que la próxima actualización de Holesky está prevista para el 7 de octubre.
Después de eso, el calendario de pruebas continuará en las redes Sepolia (14 de octubre) y Hoodi (28 de octubre), otras tesnets del ecosistema, mientras que la activación de Fusaka en la red principal de Ethereum no llegaría antes de diciembre.
Por otro lado, los desarrolladores discutieron el desarrollo de «Glamsterdam«, nombre de la actualización que le seguirá a Fusaka.
Con respecto a Glamsterdam, señalaron que la fecha límite para las «EIP no principales se fijará una semana después de confirmada la fecha de mainnet de Fusaka».
¿Qué traerá Fusaka a Ethereum?
Como reportó CriptoNoticias, Fusaka incorporará 13 propuestas de mejora de Ethereum (EIP).
La más destacada es EIP-7594, que introduce «PeerDAS», un sistema de muestreo de disponibilidad de datos entre pares. Ese sistema permitiría que los nodos se “especialicen” en almacenar y verificar distintos tipos de datos, aumentando la capacidad de almacenamiento y eficiencia de la red.
A través de «PeerDAS», en Ethereum se reducirían los costos de transacción en segundas capas (L2) como Base, Arbitrum y otras; escalar a 128 blobs (paquetes de datos fuera de la cadena) por bloque a lo largo del tiempo; y alojar nodos más ligeros que solo almacenan una fracción de los datos.
