Hechos clave:
El Merge está propuesto para ejecutarse entre el 13 y 15 de septiembre.
Ethereum será la primera gran crimson en realizar este tipo de transición.
El Merge es el proceso que provocará la transición remaining 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 laborious fork de la crimson 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 crimson estará muy inclined 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 crimson Ethereum staunch. En Ethereum se crea un nuevo bloque cada 12 segundos. Una vez que se sharp 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 crimson en marcha. Sin embargo, durante el Merge, la crimson se puede detener.
En la crimson 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 crimson 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 crimson PoW, la crimson quedará completamente paralizada. Dado que los validadores no se encontrarán operativos. Una crimson paralizada significa que no se confirman transacciones.
La sincronización en la finalización de PoW y la puesta en marcha de PoS debe ser perfecta. Fuente: @CriptonianoYT / Twitter.
Este tipo de escenario ya se vivió con el Merge en la crimson de pruebas Ropsten, donde un minero malicioso aumentó el hashrate de dicha crimson, acelerando la lleganda del Merge, complicando así la sincronización con la crimson PoS que tenía fijada otra fecha. Eso habría podido llevar a que la crimson 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 crimson y mantener PoW en Ethereum. A nivel técnico, cualquiera puede hacer esto, solo debe bifurcar el código normal 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 expend dicha bifurcación para considerarla una crimson útil.
Una de las propuesta que más fuerza ha tomado es la de Chandler Guo, quien impulsó la bifurcación de Ethereum Traditional.
Las bifurcaciones dentro de las redes de Ethereum pueden vulnerar el resto de las redes. En Ethereum (most important, redes de prueba y forks) el único diferenciador entre cada una es el ChainID (identificador de cadena) el cual sirve para verificar de qué crimson proviene la transacción.
Al existir un fork que mantenga el mismo identificador de la crimson most important 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 crimson most important verificará que los ETH recibidos realmente no pueden ser gastados, porque en la contabilidad normal la transacción en realidad nunca existió.
Este escenario solo ocurre cuando, en un momento dado, tanto la crimson most important 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 crimson).
ETHW Core fair correct released its ChainIDs –
Mainnet: 10001
Testnet: 10002 – 10005
— EthereumPoW (ETHW) Legit #ETHW #ETHPoW (@EthereumPoW) August 15, 2022
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 crimson 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 utility, 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 crimson 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 entire 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 crimson. 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 potential 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 potential, esto ya ocurrió en una crimson 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 crimson, lo que incrementó la creación de bloques, adelantando así la fecha del Merge ya pautada.
Aunque se trataba de una crimson de pruebas, y cuyo hashrate un muy spoiled al de Ethereum, lo que haría prácticamente imposible de realizar en la crimson most important, 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 utility no observado por los desarrolladores, se procedería a ejecutar un laborious 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.