"Ethereum 2" ya no es el nombre: execution y consensus layer

Un compañero te escribe: "¿tenemos que migrar nuestros contratos a Ethereum 2?". La respuesta corta es no. No hay una segunda red a la que mudarse ni un token ETH2 que comprar. Lo que hubo fue un cambio de motor de consenso dentro de la misma red, y un cambio de nombres para dejar de sugerir lo contrario.

En enero de 2022 la Ethereum Foundation explicó que los términos Eth1 y Eth2 se retiraban: Eth1 pasó a llamarse capa de ejecución (execution layer), Eth2 pasó a llamarse capa de consenso (consensus layer), y Ethereum es la suma de ambas. [1] Este capítulo cuenta por qué el nombre viejo tenía sentido en su momento, por qué dejó de tenerlo y qué significa la división en dos capas para quien opera un nodo o depura una dapp.

Preguntas guía

• ¿Qué parte del nodo ejecuta tu transacción y qué parte decide en qué bloque queda?
• ¿Por qué un nodo con JSON-RPC respondiendo puede estar, aun así, fuera de sincronía?
• ¿Qué evidencia pedirías para saber cuál de las dos capas está fallando?
• ¿Por qué un cambio de nombre se consideró también una medida contra estafas?

Conexiones dentro de la serie

• Antes: Por qué Ethereum necesitaba The Merge da el contexto del cambio a prueba de participación.
• Base técnica: JSON-RPC: hablar con Ethereum sin magia explica la interfaz que sigue expuesta por la capa de ejecución.
• Después: Beacon Chain desde cero abre la capa de consenso por dentro.
• Operación: Clientes y nodos: diversidad antes que monocultivo retoma la elección de clientes para producción.

Historia del nombre: un plan por fases que cambió

El nombre "Ethereum 2.0" nació de un plan concreto. La idea era construir una cadena nueva de prueba de participación, con sharding, mientras la cadena original de prueba de trabajo (Eth1) se iba abandonando con la difficulty bomb, un mecanismo que hace cada vez más difícil minar. Los usuarios y las aplicaciones migrarían a la cadena nueva, Eth2. [1]

Ese plan se encontró con dos cosas. Primero, al empezar a construir la Beacon Chain quedó claro que la hoja de ruta por fases tardaría años. Segundo, apareció la propuesta de "Early Merge": conectar la cadena EVM existente al sistema nuevo, de modo que el paso a prueba de participación no exigiera ninguna migración a las aplicaciones. [1]

Además, el trabajo sobre rollups mostró una vía de escalado más cercana que el sharding de ejecución. El resultado fue reutilizar los clientes existentes, probados durante años en mainnet, como mitad de ejecución del sistema final. [1]

Con ese giro, "1" y "2" dejaron de describir la realidad. No había una cadena primera que desaparecía y una segunda que la sustituía; había dos componentes que trabajarían juntos. A finales de 2021 los desarrolladores del núcleo ya hablaban de capa de ejecución y capa de consenso, y en enero de 2022 ethereum.org hizo el mismo cambio. [1]

Qué rompía el nombre viejo: modelo mental, estafas y tickers

El artículo de la renombrada da tres motivos. El primero es el modelo mental: "Eth2" sugiere que Eth1 va primero y deja de existir después, y ninguna de las dos cosas es cierta. [1]

El segundo es la prevención de estafas. Hubo actores que pedían a los usuarios "cambiar" su ETH por tokens ETH2 o "migrarlo" antes de la actualización. El tercero es la claridad del staking: algunos operadores mostraban el ETH depositado en la Beacon Chain con un ticker ETH2, cuando no existe ningún token ETH2. [1]

ethereum.org lo repite para The Merge: quien tiene ETH no tenía que hacer nada; no hay "ETH viejo" ni "ETH nuevo", y quien diga lo contrario probablemente intenta estafar. [2] Para un equipo de producto esto es una regla de soporte: cualquier flujo que pida al usuario "migrar a ETH2" es una señal de fraude, no una funcionalidad.

El cambio de nombre no cambió la hoja de ruta. La Ethereum Foundation insistió en que era solo un cambio de terminología y que las funcionalidades planeadas seguían igual. [1]

Anatomía de un nodo actual: dos clientes y un canal autenticado

Ahora la parte que importa a quien opera. ethereum.org define un nodo como una instancia de software cliente conectada a otros, y añade que un nodo tiene que correr dos clientes. [3] El cliente de ejecución, antes llamado cliente Eth1, escucha transacciones, las ejecuta en la EVM y guarda el estado. El cliente de consenso, antes llamado cliente Eth2 o beacon node, implementa el algoritmo de prueba de participación. [3]

Hay una tercera pieza opcional: el cliente validador, que se añade al de consenso para firmar bloques y votos. Sin él, el nodo verifica la cadena pero no participa en producirla. [3] Correr un nodo no exige depositar ETH; solo validar lo exige. [2]

Los dos clientes se comunican mediante la Engine API. [4] Ese canal va autenticado: la especificación fija el puerto 8551 por defecto, tokens JWT firmados con HS256 y un secreto compartido de 256 bits que ambos clientes leen de un archivo. [5] Si el secreto no coincide, ethereum.org advierte que el nodo aparece "offline" hasta que las dos capas estén sincronizadas y autenticadas. [2]

Figura 1

Un nodo después de The Merge: dos clientes, dos redes p2p y un canal autenticado

Fuentes:

[3][5]

Cómo leer esta figura

Diagrama con dos columnas. A la izquierda, de arriba abajo: Red p2p de ejecución con transacciones pendientes, Cliente de ejecución con EVM, estado, mempool y receipts, y Wallet, dapp o indexador conectado por JSON-RPC. A la derecha, de arriba abajo: Red p2p de consenso con bloques y attestations, Cliente de consenso con slots, fork choice y finalidad, y Cliente validador opcional con claves de firma conectado por Beacon API. Una flecha doble horizontal une ambos clientes con la etiqueta Engine API, JWT compartido, puerto 8551. Una nota abajo dice: un nodo completo igual a dos clientes.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Riesgo operativo: diagnosticar qué capa está enferma

La división en capas tiene una consecuencia práctica: "el nodo responde" ya no basta como señal de salud. La capa de ejecución puede seguir contestando JSON-RPC mientras la de consenso está atrasada, y al revés. Hay que preguntar a cada una por separado.

# Ilustrativo: los puertos dependen del cliente y de su configuración.
# Capa de ejecución (JSON-RPC estándar):
curl -s -X POST http://localhost:8545 -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_syncing","params":[]}'
 
# Capa de consenso (Beacon API estándar):
curl -s http://localhost:5052/eth/v1/node/syncing

La respuesta de la Beacon API trae cinco campos: head_slot, sync_distance (slots que faltan, 0 si está al día), is_syncing, is_optimistic y el_offline, que vale true cuando el cliente de ejecución está caído. [6] Ese último campo es el puente entre las dos capas: el cliente de consenso te dice si ve a su compañero. El campo is_optimistic indica sincronización optimista: el cliente de consenso importa bloques beacon sin haber verificado todavía sus payloads de ejecución, porque el cliente de ejecución aún se está poniendo al día. [7]

Una regla para recordar: cuando un incidente diga "Ethereum 2", tradúcelo antes de actuar. Si habla de bloques, votos o finalidad, mira la capa de consenso. Si habla de transacciones, gas o estado de contratos, mira la de ejecución. Si habla de que los dos no se ven, mira la Engine API.