Por qué Ethereum necesitaba The Merge

Si una red funciona y sus contratos custodian dinero real, ¿por qué cambiarle el motor de consenso en marcha? El 15 de septiembre de 2022 Ethereum lo hizo: el último bloque minado con proof-of-work fue el 15,537,393 y el siguiente lo propuso un validador de proof-of-stake. Saldos, contratos e historial siguieron intactos. Este capítulo explica por qué valía la pena el riesgo y cómo se ejecutó.

La documentación oficial define The Merge como la unión de la capa de ejecución original con su nueva capa de consenso, la Beacon Chain. Dejó de hacer falta la minería y la red pasó a asegurarse con ETH en stake. [1]

Preguntas guía

• ¿Qué es la bomba de dificultad y por qué se retrasó tantas veces?
• ¿Qué problemas de proof-of-work resolvía proof-of-stake y cuáles no?
• ¿Cómo supo cada nodo en qué bloque exacto dejar de aceptar proof-of-work?
• Después del Merge, ¿qué software tiene que correr un operador y cómo se comunican sus piezas?

Conexiones dentro de la serie

• Antes: Berlin, London y EIP-1559: gas deja de ser solo subasta cierra la evolución de la capa de ejecución bajo proof-of-work.
• Después: Cuentas, claves y direcciones sin humo abre el arco de ejecución.
• Profundización: The Merge: cómo se apagó proof-of-work sin apagar Ethereum detalla la transición; Beacon Chain desde cero y Casper FFG como gadget de finalidad explican el consenso nuevo.

Historia de una migración anunciada: la bomba de dificultad

Proof-of-stake no fue una idea tardía. Desde el fork Frontier thawing de 2015, la fórmula de dificultad incluyó una bomba: un término que crece de forma exponencial con el número de bloque, con el fin declarado de forzar un futuro hard fork hacia proof-of-stake. Cuanto más avanza la cadena, más difícil es minar y más lentos son los bloques.

La bomba se retrasó una y otra vez porque proof-of-stake no estaba listo. Los EIPs de Byzantium y Constantinople lo dicen en su motivación: el desarrollo de Casper y el cambio a proof-of-stake se habían demorado. [3] Muir Glacier, Arrow Glacier y Gray Glacier fueron forks cuyo único contenido era otro retraso.

El plan original también cambió de forma. Durante años se habló de "Eth1" y "Eth2" como dos cadenas, y de migrar usuarios a una cadena nueva. Lo que se hizo al final fue conservar la cadena existente y cambiarle el consenso. Por eso hoy se habla de capa de ejecución y capa de consenso, no de Eth2. [4]

Cuello de botella de proof-of-work: energía, emisión y finalidad

ethereum.org resume la motivación en tres palabras: proof-of-stake es más seguro, consume menos energía y facilita soluciones de escalado. [5] Conviene ver cada una como un cuello de botella concreto.

Energía. En proof-of-work, la seguridad depende de gastar electricidad en hardware dedicado. La documentación oficial estima que el Merge redujo el consumo energético de Ethereum en un 99,95 % aproximadamente.

Emisión. Los mineros tienen costos reales y hay que pagarles con ETH nuevo. Según la estimación de ethereum.org, antes del Merge la emisión anual era de un 4,61 %, y cerca del 88,7 % iba a los mineros. Desde el Merge, la emisión en la capa de ejecución es cero; queda la de la capa de consenso, mucho menor. [6] Esos porcentajes son una estimación de la página, calculada con el stake de ese momento.

Finalidad. En proof-of-work, un bloque nunca es definitivo; solo se vuelve más improbable revertirlo con cada bloque nuevo encima. Proof-of-stake introdujo un concepto que antes no existía: un checkpoint finalizado con votos de al menos dos tercios del stake no puede revertirse sin que una gran cantidad de ETH sea destruida por penalización (slashing). Para un backend que acredita depósitos, la diferencia es enorme: hay un punto a partir del cual el orden no cambia.

Traza de la transición: del bloque 15,537,393 al 15,537,394

La transición tenía un problema de coordinación: ¿cómo saben miles de nodos cuándo dejar de aceptar bloques minados, si los tiempos de bloque en proof-of-work varían? La respuesta de EIP-3675 fue usar la dificultad total acumulada, no un número de bloque. El primer bloque minado cuya dificultad total alcanzara TERMINAL_TOTAL_DIFFICULTY (58750000000000000000000 en la red principal) sería el último de proof-of-work. [7]

La transición tuvo dos fases, como explicó el anuncio oficial. Primero Bellatrix, en la capa de consenso, activada en la época 144,896 el 6 de septiembre de 2022. Después Paris, en la capa de ejecución, disparada al alcanzar la dificultad total terminal. [8] El registro de forks indica que la dificultad terminal se alcanzó en el bloque 15,537,393 y que Paris se activó en el siguiente.

Figura 1

Antes y después del Merge

Fuentes:

[7][1]

Cómo leer esta figura

Diagrama en dos columnas separadas por una línea discontinua vertical rotulada TTD alcanzado en el bloque 15,537,393. A la izquierda, antes: dos cadenas en paralelo. Arriba, Mainnet proof-of-work, con transacciones, estado y EVM, donde los mineros eligen el bloque. Abajo, Beacon Chain desde diciembre de 2020, con validadores con stake y sin transacciones de usuarios. A la derecha, después: un nodo, dos clientes. Arriba, el cliente de ejecución, con la misma EVM y el mismo estado, que ya no decide el bloque. Abajo, el cliente de consenso, que propone, vota, finaliza y ordena al de ejecución. Una flecha doble entre ambos está rotulada Engine API con JWT. Flechas discontinuas unen la red proof-of-work con el cliente de ejecución y la Beacon Chain con el cliente de consenso.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Desde el bloque de transición, varios campos del encabezado que solo tenían sentido con minería se fijaron como constantes: difficulty vale 0, nonce vale 0x0000000000000000 y la lista de ommers (bloques "tío") queda vacía. Las recompensas por producir bloques en la capa de ejecución se eliminaron.

Un detalle afecta a contratos existentes. El opcode DIFFICULTY (0x44) pasó a llamarse PREVRANDAO y a devolver la salida del generador de aleatoriedad de la Beacon Chain. [9] Un contrato que usaba la dificultad como fuente de aleatoriedad siguió funcionando, pero con otra semántica.

Riesgo operativo: lo que el Merge no cambió

Para un operador, el cambio más visible fue el software. Desde el Merge, un nodo necesita un cliente de ejecución y uno de consenso. Se comunican por la Engine API, autenticada con un secreto JWT que ambos comparten. Si falta uno, el nodo no sigue la cadena.

Para todo lo demás, la página oficial desmiente tres creencias habituales. El Merge fue un cambio de mecanismo de consenso, no una ampliación de capacidad, y nunca pretendió bajar las fees. No cambió de forma significativa los parámetros que determinan el throughput. Y no habilitó los retiros de stake, que llegaron después con Shanghai/Capella. [1]

La lección de arquitectura es la que abre la serie: ejecución y consenso son capas distintas. El Merge pudo cambiar una sin tocar la otra porque la frontera entre ambas quedó definida por una interfaz. Los capítulos siguientes empiezan por la capa de ejecución, la que tu código toca directamente.