5 cosas que pueden salir mal con el Merge de Ethereum

El Merge es el proceso que provocará la transición final de la prueba de trabajo (PoW) a la prueba de participación (PoS) en Ethereum. 

Ante un cambio de tal magnitud, que representa un gran desafío técnico, los desarrolladores se mantienen expectantes de qué podría pasar. Si bien han sido múltiples las pruebas que se han realizado a la espera del gran día, todavía hay una serie de cosas que pueden salir mal.  

La fusión o merge, según se ha pautado, ocurrirá entre el 10 y 20 de septiembre. La expectativa está al máximo, y los desarrolladores se encuentran puliendo detalles para Paris, el hard fork de la red PoW de Ethereum, que se encargará de dar la transición. El Merge, se estima que dure aproximadamente 12 minutos en completarse en su totalidad. En este tiempo, la red estará muy vulnerable a posibles errores.  

Los problemas que presentamos a continuación se tratan de escenarios posibles. Aunque vale tener en cuenta que los desarrolladores de Ethereum consideran que hay muy bajas posibilidades de que ocurran.  

Ethereum podría paralizarse

Los mineros PoW son los encargados de crear nuevos bloques en la red Ethereum actual. En Ethereum se crea un nuevo bloque cada 12 segundos. Una vez que se active el Merge, este trabajo pasará a manos de los nodos validadores quienes serán los encargados de la validación de nuevos bloques, y consecuentemente de mantener la red en marcha. Sin embargo, durante el Merge, la red se puede detener.  

En la red PoW ya está activado el protocolo de la bomba de dificultad, que incrementa paulatinamente la dificultad para minar un bloque. Esta aumentará hasta un punto en que será imposible para los mineros confirmar nuevos bloques, llegando a lo que se conoce como era de hielo. Aquí la red se «congela» y es entonces cuando los validadores comienzan a trabajar. Entre la transición de un protocolo de consenso a otro debe existir mucha sincronización. Mientras los mineros se apagan se activan los validadores.

En este proceso, se necesita que se sincronicen ambas redes que actualmente funcionan de forma independiente. Si, por ejemplo, la era del hielo se adelanta en la red PoW, la red quedará completamente paralizada. Dado que los validadores no se encontrarán operativos. Una red paralizada significa que no se confirman transacciones.  

Este tipo de escenario ya se vivió con el Merge en la red de pruebas Ropsten, donde un minero malicioso aumentó el hashrate de dicha red, acelerando la lleganda del Merge, complicando así la sincronización con la red PoS que tenía fijada otra fecha. Eso habría podido llevar a que la red se detuviese. 

Para evitar este escenario, los desarrolladores han fijado dos TDD o dificultad total terminal, que es la dificultad máxima alcanzada por la bomba de dificultad. En principio se fijó el valor de 58.750.000.000.000.000.000.000. Sin embargo, los desarrolladores agregaron que se coordinará para colocar un valor más bajo estimado, que dará por sentado la fecha definitiva del Merge. Esta estrategia intenta evitar que se pueda adelantar el Merge.  

Ataques de replicación

Con el Merge, existen actualmente propuestas para bifurcar la red y mantener PoW en Ethereum. A nivel técnico, cualquiera puede hacer esto, solo debe bifurcar el código original de Ethereum, cambiar las reglas del protocolo sobre el Merge, y mantener PoW. No obstante, se requiere conocimiento técnico y una comunidad que acepte y use dicha bifurcación para considerarla una red útil.  

Una de las propuesta que más fuerza ha tomado es la de Chandler Guo, quien impulsó la bifurcación de Ethereum Classic.  

Las bifurcaciones dentro de las redes de Ethereum pueden vulnerar el resto de las redes. En Ethereum (principal, redes de prueba y forks) el único diferenciador entre cada una es el ChainID (identificador de cadena) el cual sirve para verificar de qué red proviene la transacción.  

Al existir un fork que mantenga el mismo identificador de la red principal de Ethereum, un usuario puede simular enviar ETH de Ethereum PoW a Ethereum PoS. La transacción puede ser detectada como recibida, e incluso confirmada en primera instancia por los validadores, pero no podrá ser gastada, ya que el protocolo de la red principal verificará que los ETH recibidos realmente no pueden ser gastados, porque en la contabilidad original la transacción en realidad nunca existió.  

Este escenario solo ocurre cuando, en un momento dado, tanto la red principal como la bifurcada, poseen la misma información en su contabilidad, una vez que cada una valida nuevos bloques, la contabilidad de la cadena es totalmente diferente.  

Para mitigar estas situaciones, cada fork debe modificar su ChainID. Por ejemplo, la propuesta de Guo dice haber modificado su identificador, aunque, según muestra su código fuente, tal parece que no es así (lo que podría traer problemas a la red).

Fallas en los nodos

Con la llegada del nuevo protocolo a Ethereum, las actualizaciones también jugarán un papel fundamental. Actualmente, cerca del 90% de nodos de Ethereum está actualizado, esperando para recibir las siguientes órdenes para el Merge. Sin embargo, ese 10% restante puede causar problemas. 

En primer lugar, que un nodo no se encuentre actualizado significa que no estará recibiendo las indicaciones para el Merge. Esto resulta en que, si el Merge ocurriera en este preciso momento, ese 10% no comenzaría a trabajar con PoS, validando transacciones que no pertenecen a la red correcta, y bifurcando a Ethereum de manera involuntaria.  

Para combatir esto, Fundación Ethereum, ha lanzado una amplia campaña informativa, pidiendo a los nodos que se actualicen a su última versión.  

Ahora, además de estas fallas, dentro de los nodos validadores de Ethereum 2.0 también puede existir el problema de que los nuevos nodos, por fallas de software, validen incorrectamente transacciones, por lo que no completarían correctamente la creación de nuevos bloques. A esto se le conoce como falla de finalización. Este tipo de problema ya fue observado al migrar la red de pruebas Sepolia.  

Con la actualización de Bellatrix, la cual fue aplicada a la Beacon Chain, cadena de bloques de Ethereum 2.0, se detectó un problema de este tipo, en el que los validadores no estaban finalizando correctamente, ya que el 0,5% de los nuevos bloques se marcaban como validación fallida.  

Vale señalar que la magnitud de este error puede considerarse pequeña, tomando en cuenta que la Beacon Chain aún no se encuentra operativa, hasta que no ocurra finalmente el Merge. Una vez que se complete la migración, esta puede acentuar la cantidad de bloques inválidos.  

Aplicaciones descentralizadas pueden dejar de funcionar

El cambio de protocolo también tendrá cambios en cómo los contratos inteligentes interactúan con la red. Uno de los cambios más importante es que, a nivel técnico, lo que se conoce como bloque, se comenzarán a finalizar en ranuras y epoch. Una ranura es básicamente un bloque que se mina cada 12 segundos, y un epoch son 32 ranuras. Este cambio podría tener repercusiones en aplicaciones que no se hayan actualizado correctamente. Ya que pueden estar desactualizadas en la forma de sincronización entre bloques y epoch o ranuras.  

A este nivel, los cambios deben ser realizados por los desarrolladores de las diferentes aplicaciones, dado que se trata de desarrollos independientes. Por lo tanto, cualquier tipo de falla de esta naturaleza, será responsabilidad de sus desarrolladores y no error del protocolo.  

El Merge se podría postergar

Este es, quizás, el escenario menos probable de todos, tomando en cuenta todas las pruebas y retrasos que ha tomado llegar a este evento. Pero aún existe una pequeña probabilidad.  

Si bien es poco probable, esto ya ocurrió en una red de pruebas: Ropsten. Se tuvo que pausar y modificar la fecha pautada para el Merge, como lo reportó CriptoNoticias, debido a la eventualidad de que un minero malicioso aumentó en exceso el hashrate de la red, lo que incrementó la creación de bloques, adelantando así la fecha del Merge ya pautada.  

Aunque se trataba de una red de pruebas, y cuyo hashrate un muy inferior al de Ethereum, lo que haría prácticamente imposible de realizar en la red principal, aún existe la ínfima posibilidad de que el Merge se postergue.  

Por ahora, en un caso hipotético, si existiera algún error a nivel de software no observado por los desarrolladores, se procedería a ejecutar un hard fork para retrasar la bomba de dificultad. Recordemos que desde diciembre de 2021, la bomba recibió 3 retrasos en total, hasta finalmente llegar a una fecha definida para mediados de septiembre. Así que un nuevo retraso, irónicamente, no sorprendería.