La red de Ethereum 2.0 se bifurca involuntariamente por primera vez

Ayer, 25 de mayo, la red de Ethereum 2.0 tuvo una bifurcación involuntaria que duró 7 bloques (aproximadamente 2 minutos). Este evento es el primero en ocurrir en esta nueva versión de la red creada por Vitalik Buretin.

Un escenario así se presenta al haber una desincronización entre los nodos. Lo que ocurrió fue que parte de ellos no compartían la misma cantidad de bloques que los otros, y esto hizo que los que se encontraban desfasados crearan momentáneamente una nueva cadena. Pasados los 7 bloques, la red detectó el desfase y se reorganizó automáticamente.

Martin Köppelmann, cofundador de la plataforma Gnosis, indicó que no se había visto en años una reorganización de esta magnitud en Ethereum (en este caso Ethereum 1.0).

Según lo informó uno de los desarrolladores de Ethereum, Terence Tsao, la desincronización fue causada por una falla en la actualización, ya que el 25% de los nodos no se actualizaron debidamente a la última versión.

La reciente actualización contaba con una nueva característica llamada proposer boost que les permite a los nodos validadores emitir bloques de forma más rápida. Esta variación entre unos nodos y otros causó el desfase, explicó Tsao.

Para entender mejor lo ocurrido, hay que saber que, en de una red blockchain, cada bloque minado posee información sobre el número (cabecera) del bloque anterior. Cuando se produce una una reorganización, significa que no existe un encadenamiento entre bloques, debido a que un bloque no está apuntando directamente al bloque anterior. En el caso del incidente actual, como se observa en la imagen anterior, el bloque apuntaba a uno que estaba 7 bloques atrás.

Cómo afecta esto a los usuarios

Dado que la red de Ethereum 2.0 aún no se encuentra validando transacciones (y no lo hará hasta que no ocurra la fusión), los usuarios de Ethereum no notaron ningún tipo de irregularidad. Sin embargo, en una red operativa, una reorganización significa que las transacciones que se validaron en los bloques rechazados, se cancelan.

Las reorganizaciones pueden considerarse un comportamiento habitual, de 1 bloque, o incluso 2. No obstante, como el propio Kölppelmann señala, las reorganizaciones de 7 bloques no deberían existir, y los desarrolladores deberían tomar medidas que contrarresten estos escenarios. En este caso, Tsao comentó: “estoy seguro de que veremos menos de esto cuando se actualicen más nodos para la versión habilitada para el boost”.