Ethereum merge testnet Kintsugi dividido por error, he aquí por qué

El evento de fusión en la red Ethereum es la transición al modelo de consenso de Prueba de participación del modelo de Prueba de trabajo actualmente empleado. Esta fusión significa que el actual sistema de red principal de Ethereum y la nueva cadena Beacon, a menudo denominada Ethereum 2.0, se fusionarán en una sola cadena de bloques.

Para probar la fusión, se implementó la red de prueba Kintsugi en diciembre. El propósito de la red de prueba es ejecutar diferentes casos extremos y observar cómo se comporta el sistema. Uno de los desarrolladores involucrados en la ejecución de pruebas en Kintsugi es Marius van der Wijden, Desarrollador central de Ethereum que trabaja con el equipo cliente de Geth (Go-Ethereum).

“La red de prueba funcionó sin problemas durante un par de semanas. La semana pasada creé un fuzzer que enviaría bloques inválidos. Un bloque contiene mucha información, como las transacciones, el hash del bloque anterior, el límite de gas, etc. ”, dice Marius van der Wijden.

Algunas implementaciones no ejecutaron ni verificaron el bloque.

Un fuzzer es un tipo común de herramienta de prueba que se utiliza entre los desarrolladores para generar entradas aleatorias a funciones u otras piezas de código, y tratar de hacer que se rompan de una forma u otra. Se trata de generar entradas mal formadas e inesperadas y observar lo que le sucede al sistema.

El fuzzer creado por van der Wijden produce un bloque válido y cambia un elemento para hacerlo inválido. Una técnica que utiliza es cambiar un elemento por otro. En este caso, el fuzzer cambió el blockhash al hash padre.

“Los nodos deberían rechazar un bloque tan cambiado. Sin embargo, dado que el hash principal apuntaba a un bloque válido en sí mismo, algunas implementaciones en realidad no ejecutaban ni verificaban el bloque, sino que lo buscaban en un caché. Dado que el bloque anterior era válido y estaba en la memoria caché, asumieron que el nuevo bloque también era válido”, explica van der Wijden.

Red dividida dos veces

El resultado fue que la mitad de la red, los clientes Geth, rechazaron el bloque, mientras que la otra mitad, los clientes Nethermind y Besu, lo aceptaron, lo que provocó que la cadena se dividiera, ya que ahora teníamos dos vistas diferentes del estado correcto. Para empeorar las cosas, había otro problema por encima.

Según van der Wijden, los nodos de la cadena Geth, a su vez, que consisten en Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth y Teku-Geth, también se dividen entre ellos.

“Esta división aún se está investigando, pero parece que Teku también podría tener algún mecanismo de almacenamiento en caché que falló”, dice van der Wijden.

Dado que existen varias bifurcaciones diferentes de la red de prueba de Kintsugi en el momento de la escritura, y cada nodo piensa que está en una bifurcación correcta, la red ya no finaliza.

“Pensaremos en algo para volver a unir la red. Ya hemos actualizado el cliente Nethermind y esos nodos están ahora en la cadena correcta. Todavía necesitamos la corrección de Teku, ya que más del 33 por ciento de los nodos son Teku, de lo contrario, la cadena no finalizará ”, dice van der Wijden.

El incidente trae algo bueno

Según van der Wijden, este incidente no prohíbe ni retrasa más pruebas de la fusión de Ethereum, ni retrasa la fusión en sí. De hecho, van der Wijden dice que el incidente en realidad ayuda a probar casos extremos que hubieran sido difíciles de probar si la red estuviera funcionando correctamente.

“Los largos períodos de no finalización son un desafío para los nodos y es muy importante para nosotros ver cómo se comportan en este momento. Creemos que la red de prueba eventualmente se volverá a unir, pero no creo que intentemos arreglarlo manualmente, ya que nos da la oportunidad de probar casos extremos interesantes”.

“No creo que esto retrase la fusión, ya que la fusión aún no está programada. Pero muestra cuán importantes son las pruebas. Creo que la fusión está progresando muy bien. Necesitamos un par de semanas más para que el software esté en un estado aceptable y luego necesitamos un par de meses para probarlo”, dice van der Wijden.

¿Qué pasa si esto sucede en la red principal?

Una pregunta interesante es qué hubiera pasado si un error como este hubiera ocurrido en la cadena principal.

“Comenzamos a realizar pruebas bastante temprano, por lo que esperábamos un par de errores como este. Sin embargo, un error de este tipo en la red principal sería bastante desagradable, ya que tendríamos que encontrar y corregir el error, en el que somos bastante buenos, liberar el código y luego informar a todos los interesados ​​que deben actualizar sus nodos. La última parte es la más difícil en mi opinión, ya que algunos usuarios no están siguiendo el desarrollo demasiado de cerca ”, dice van der Wijden.

Para más detalles, se anima al lector interesado a leer el libro de Marius van der Wijden Los Tweets sobre el incidente.