Las pruebas en la red de prueba de Zhejiang de Ethereum antes de la actualización de Shanghai-Capella revelaron algunos errores, pero nada que afectará la línea de tiempo para la introducción de la participación en la red.
Desarrollador Marius VanDerWijden documentado un error de sincronización encontrado por otros clientes que los desarrolladores confían que se puede reparar, según un hilo de Tim Beiko de la Fundación Ethereum. El error no afectará los plazos establecidos para el conjunto de actualizaciones propuesto para la red de prueba Sepolia programada para el 28 de febrero, señaló.
La última actualización de devnet de retiro detalló una prueba de esfuerzo que constaba de 600,000 360,000 validadores, XNUMX XNUMX de los cuales realizaron actualizaciones de credenciales de retiro en el momento de la bifurcación. Se produjeron picos de clientes en RAM y CPU y los desarrolladores medirán la cantidad de mensajes de actualización de credenciales perdidos versus registrados en los próximos días, dijo Beiko.
La prueba de estrés también reveló un error entre un cliente de prueba de participación, Prysm, y el cliente Besu, que está diseñado para casos de uso autorizados. Para sincronizar correctamente, el cliente de Prysm espera una cierta cantidad de respuestas; sin embargo, Besu impone limitaciones de respuesta que lo llevan por debajo del umbral de sincronización necesario, dijo Beiko. El equipo de Besu está investigando el asunto.
prohibición sin manchas
Después de una discusión sobre cómo optimizar mejor la orientación inicial al cliente, los desarrolladores finalmente decidido para prohibir por completo las transacciones 4844 sin blobles, lo que cambiaría las suposiciones de los clientes sobre las transacciones y podría complicar la configuración.
Los desarrolladores también discutieron cómo avanzar con la desaprobación de la palabra clave SELFDESTRUCT, que rescinde un contrato, elimina el código de bytes del contrato de la cadena de bloques y redirige los fondos del contacto a una dirección específica.
Si bien el camino a seguir sigue sin estar claro, hay tres propuestas actuales sobre el tema en discusión, ya que los desarrolladores buscan encontrar "opciones de desactivación que no rompan las cosas", dijo Beiko.
“El desafío aquí es que abre un vector de ataque desagradable: implemente un contrato, llene el almacenamiento de cierta manera y cuando vuelva a implementar el contrato, el almacenamiento anterior todavía está allí y se puede acceder de manera maliciosa”, dijo Beiko.
Fuente: https://www.theblock.co/post/212636/latest-round-of-ethereum-shapella-testnet-development-reveals-a-few-bugs?utm_source=rss&utm_medium=rss