Este artículo es compilado y organizado por BlockWeeks
Merge es la transición de Ethereum del consenso de prueba de trabajo (PoW) a la prueba de participación (PoS), y también el cambio de código más complejo y radical en la historia de Ethereum. Su proceso de activación es diferente al de cualquier hard fork anterior: consta de tres grandes pasos y requiere que los operadores de nodos pasen de ejecutar solo un cliente de software a ejecutar dos clientes simultáneamente. Como la blockchain de propósito general más grande del mundo por capitalización de mercado y valor total bloqueado, el valor y la reputación en juego en la transición de Ethereum son enormes.
Qué se pretende resolver con The Merge: la fusión de dos cadenas
Actualmente, las transacciones de Ethereum se finalizan mediante un protocolo de consenso PoW llamado ethash. Ejecutándose en paralelo a esta cadena PoW está la Beacon Chain, una blockchain independiente que ha estado ejecutando por su cuenta el nuevo protocolo de consenso PoS de Ethereum, Gasper, desde diciembre de 2020.
El objetivo de The Merge es fusionar las dos cadenas: hacer que la blockchain existente de Ethereum dependa completamente de la Beacon Chain para producir el consenso de la red y abandonar por completo la prueba de trabajo. El Ethereum que conocemos hoy ya no procesará transacciones mediante ethash, sino que existirá únicamente como la Capa de Ejecución (EL), para que las aplicaciones descentralizadas y los usuarios transmitan transacciones. La Máquina Virtual de Ethereum (EVM), el motor de cómputo de Ethereum, continuará operando normalmente en la Capa de Ejecución.
La Beacon Chain se convierte entonces en la Capa de Consenso (CL) de Ethereum: las transacciones de la Capa de Ejecución se reciben, procesan y finalizan aquí. Empaquetar las transacciones de la Capa de Ejecución en bloques y finalizarlas mediante el protocolo Gasper será responsabilidad de los validadores de la Beacon Chain. Después de The Merge, para seguir la cadena principal de Ethereum, todos los validadores y operadores de nodos completos deben ejecutar dos clientes de software simultáneamente: un cliente de Capa de Ejecución y un cliente de Capa de Consenso.
Paso uno: el hard fork Bellatrix
Primero, la Capa de Consenso de Ethereum ejecuta un hard fork llamado Bellatrix. Bellatrix introduce una nueva estructura de bloque de la Beacon Chain en la Capa de Consenso para acomodar bloques que transportan transacciones de la Capa de Ejecución. También incorpora un conjunto de instrucciones para que los nodos de la Capa de Consenso no comiencen a insertar transacciones de la Capa de Ejecución en los bloques beacon hasta que la Capa de Ejecución alcance una "Dificultad Total Terminal" (TTD) específica. Todos los nodos de la Capa de Consenso deben actualizarse a Bellatrix antes de una altura de slot especificada (equivalente a la altura de bloque en la cadena PoW). Una vez completado Bellatrix, los nodos de la Capa de Consenso comienzan a monitorear la TTD.
Diseño clave: por qué usar TTD en lugar de la altura de bloque
La Dificultad Total Terminal mide la dificultad de minería acumulada de la Capa de Ejecución de Ethereum. Aquí, "dificultad" se refiere a lo difícil que es para los mineros añadir un nuevo bloque a la blockchain, lo que representa cuántas combinaciones necesitan probar típicamente los mineros para encontrar el hash correcto que genere el siguiente bloque. A medida que crece la potencia de cómputo (tasa de hash) que aportan los mineros, la dificultad aumenta automáticamente. La TTD es la suma de la dificultad de minería de todos los bloques en la historia de Ethereum.
Históricamente, las activaciones de hard forks de la Capa de Ejecución nunca dependieron de una TTD específica, sino de una altura de bloque preestablecida. The Merge abandonó este enfoque debido a la posibilidad de un ataque de "fork rápido": un atacante podría usar una minoría de potencia de hash para bifurcar la Capa de Ejecución y minar hasta el número de bloque especificado más rápido que la cadena principal. Si esto ocurriera, la Capa de Consenso podría completar erróneamente la fusión con la cadena minoritaria del atacante en lugar de la cadena principal. Por lo tanto, los desarrolladores eligieron usar la TTD como umbral para desencadenar The Merge, porque es mucho más difícil de manipular para actores maliciosos.
Pero usar la TTD como umbral también tiene un costo: la TTD es un valor extremadamente difícil de predecir, lo que también hace que predecir el momento de activación de The Merge después de Bellatrix sea complicado e impreciso. Esta consecuencia quedó expuesta cuando los desarrolladores principales intentaron por primera vez activar The Merge en la testnet Ropsten: la configuración original de la TTD era inexacta, lo que provocó que el tiempo de activación se desviara de lo esperado.
Paso dos y paso tres: París y el interruptor de la capa de ejecución
Cuando la capa de ejecución alcanza el umbral de TTD, se activan dos propuestas de actualización de la capa de ejecución, una de las cuales es la EIP-4399: cambia la forma en que se genera la aleatoriedad en la cadena, ya no depende de la dificultad de minería para generar números enteros aleatorios para las dApps. Ambas EIP se activan simultáneamente en el momento en que se alcanza el TTD. Al mismo tiempo, los nodos de la capa de consenso que han estado esperando y monitoreando ese valor de TTD también comienzan a procesar transacciones de la capa de ejecución a partir de ese momento.
Debe enfatizarse el ritmo de las versiones de los clientes y la comunicación con las partes interesadas. Para prepararse para la bifurcación dura Bellatrix, se espera que la Fundación Ethereum publique una entrada de blog varias semanas antes en la que se listen las versiones de los clientes correspondientes a las actualizaciones París y Bellatrix para que los operadores de nodos las descarguen con antelación. Estas versiones iniciales se poblarán con un valor de TTD inusualmente grande como marcador de posición. Debido a que Bellatrix se activa en una altura de slot específica, la fecha y la hora estimada de esa actualización también se comunicarán a las partes relevantes.
Una vez completada Bellatrix, el nuevo valor de TTD se comunicará nuevamente a los operadores de nodos mediante una segunda entrada de blog. Esta vez, no se requiere una actualización completa de los clientes de la capa de consenso o de la capa de ejecución; como mínimo, solo es necesario agregar una línea de código a cada uno de los dos tipos de clientes para anular manualmente el valor de TTD anterior. También se pueden ofrecer actualizaciones opcionales de clientes en este momento, pero esa es una decisión de cada equipo de clientes y de ninguna manera es una versión obligatoria requerida para seguir la etapa final de la Fusión.
Después de que se anuncie el valor de anulación del TTD, comienza la fase de espera para alcanzar el nuevo umbral. Aunque habrá estimaciones aproximadas de tiempo, la fecha y hora exactas de la activación de París no se pueden conocer con precisión de antemano.
Riesgos de ejecución que no se pueden ignorar
1. El vacío operativo causado por una sincronización impredecible
La incapacidad de predecir con precisión el TTD significa que todos los servicios que dependen de Ethereum no pueden fijar de antemano la hora exacta de "el momento de la Fusión". Para las empresas que necesitan pausar o congelar depósitos y retiros, esto plantea un verdadero desafío operativo.
2. La presión operativa de la arquitectura de doble cliente
Después de la Fusión, los operadores de nodos deben ejecutar simultáneamente clientes de la capa de ejecución y de la capa de consenso, y cualquier configuración incorrecta o discrepancia de versión en cualquiera de los lados podría hacer que un nodo se quede atrás. Por lo tanto, los ensayos previos en redes de prueba (Sepolia, Goerli) se vuelven cruciales.
3. Un cambio fundamental en la producción de bloques y la lógica de finalidad
Después de la Fusión, los bloques ya no se finalizarán en unidades de altura de bloque, sino en unidades de slots y épocas. Los validadores procesan un slot cada 12 segundos, y 32 slots componen una época, es decir, una época cada 6,4 minutos. Las transacciones en la Beacon Chain alcanzan la finalidad después de 2 épocas, aproximadamente 12,8 minutos. Para los intercambios, DEX y otras aplicaciones DeFi construidas sobre diferentes supuestos sobre la finalidad de las transacciones y la velocidad de confirmación, estos próximos cambios deben anticiparse y prepararse con antelación para evitar interrupciones del servicio o explotación.
Conclusión: pequeña probabilidad, gran impacto
La transición de Ethereum de PoW a PoS es la actualización de blockchain de capa 1 más seguida y de mayor alcance en la historia de las criptomonedas; nunca antes una red comparable en escala e importancia a Ethereum había experimentado un cambio tan drástico. Debido a que los desarrolladores han invertido enormes esfuerzos en pruebas y preparación, la probabilidad de que los riesgos anteriores afecten gravemente a los usuarios y a las dApps no es alta; pero si ocurre cualquiera de los escenarios descritos en este artículo, hasta el punto de que la red necesite revertir la actualización mediante una bifurcación dura de emergencia, el valor y la reputación de Ethereum como blockchain de propósito general podrían verse dañados.
Por lo tanto, todas las partes interesadas deben tener claros estos riesgos y tomar medidas para mitigar el impacto de posibles problemas en su propio uso de la red, por ejemplo, pausando o congelando depósitos y retiros durante ventanas críticas en las que pueden producirse interrupciones. Al mismo tiempo, los validadores, las dApps y los proveedores de servicios deben prepararse participando en los ensayos de activación posteriores en las redes de prueba Sepolia y Goerli, lo que puede garantizar que los operadores de nodos dominen las mejores prácticas para seguir la actualización Merge y exponer problemas en el proceso antes de la activación en la red principal. Además, la vigilancia de la Fundación Ethereum, los equipos de clientes y los medios de confianza contra la desinformación relacionada con Merge durante la activación es especialmente crítica—incluidos valores TTD incorrectos, versiones de clientes incorrectas, expectativas de tiempo incorrectas y orientación operativa incorrecta—y deben coordinarse rápidamente para informar claramente a las partes relevantes qué preparar a continuación, hasta que la actualización Merge haya finalizado por completo.
