Ethereum: mapa de lectura antes de tocar Solidity

Imagina este ticket: "el explorador muestra la transferencia, pero el backend dice que todavía no está confirmada". Para responderlo hay que saber qué parte de Ethereum ejecutó la transacción, qué parte decidió el orden de los bloques y cuándo ese orden deja de poder cambiar. Esta serie existe para que puedas contestar ese tipo de preguntas sin adivinar.

Ethereum tiene documentación oficial amplia y bien mantenida. El problema no es la falta de material, sino el orden: si empiezas por Solidity, aprendes sintaxis antes de saber qué máquina la ejecuta y quién garantiza el resultado. [1]

Preguntas guía

Lee el mapa con estas preguntas abiertas. Si al final de la serie puedes responderlas con una fuente en la mano, la ruta funcionó:

• ¿Qué diferencia hay entre que una transacción esté incluida en un bloque y que ese bloque esté finalizado?
• ¿Qué software corre un nodo de Ethereum hoy y cómo se comunican sus piezas?
• ¿Por qué una regla actual (por ejemplo, el precio de leer storage) tiene la forma que tiene?
• ¿Qué capítulos necesitas antes de tocar un contrato que custodia dinero real?

Conexiones dentro de la serie

• Antes: este es el punto de entrada; no necesitas capítulos previos.
• Después: Antes de Ethereum: Bitcoin, scripts y la máquina mundial explica qué problema intentaba resolver el whitepaper.
• Atajos útiles: Una transacción Ethereum por dentro para backend, Reentrancy: la llamada externa que muerde de vuelta para seguridad y Gasper: Casper FFG + LMD-GHOST en una sola cabeza para sistemas distribuidos.

Historia como herramienta: por qué la serie empieza en 2013

Pregunta concreta: ¿por qué leer storage cuesta distinto la primera vez que la segunda dentro de la misma transacción? La respuesta no está en Solidity. Está en una secuencia de cambios de protocolo, cada uno aplicado en una altura de bloque concreta y documentado en una propuesta pública.

Ethereum no cambia con versiones de software que cada nodo instala cuando quiere. Cambia con hard forks: actualizaciones coordinadas en las que todos los clientes empiezan a aplicar reglas nuevas desde un mismo bloque o una misma época. Un nodo que no actualiza queda en otra cadena. El registro oficial de ethereum.org lista cada fork con su fecha, su bloque de activación y las propuestas que incluyó. [2]

Por eso los cinco primeros capítulos recorren la historia. Cada fork resolvió un problema real: ataques de denegación de servicio, contratos con fondos drenados, precios de gas desalineados con el costo de los nodos. Si conoces el problema, la regla deja de parecer arbitraria y puedes predecir qué se rompe cuando cambie otra vez.

La historia también explica el vocabulario. Durante años se habló de "Eth1" y "Eth2" como si fueran dos redes. A finales de 2021 los desarrolladores dejaron esos nombres y pasaron a hablar de capa de ejecución (donde corren transacciones y contratos) y capa de consenso (donde validadores acuerdan el orden de los bloques). Esta serie usa siempre los nombres nuevos. [3]

Traza de ejecución: una transacción cruza dos capas

Volvamos al ticket. Un usuario firma una transacción con su clave privada: un mensaje que dice "transfiere este valor" o "llama a esta función de este contrato con estos datos". Esos datos de entrada se llaman calldata. La transacción viaja por la red hasta que alguien la incluye en un bloque.

Desde septiembre de 2022, ese "alguien" es un validador de proof-of-stake. Un nodo completo corre dos programas: un cliente de ejecución, que mantiene el estado y ejecuta la EVM, y un cliente de consenso, que sigue a los validadores. Los dos se hablan por una interfaz local llamada Engine API, autenticada con un secreto JWT compartido. [4]

Figura 1

Una transacción atraviesa las capas que estudia la serie

Fuentes:

[4]

Cómo leer esta figura

Diagrama de cinco cajas. A la izquierda, bajo el título historia, la caja usuario firma una transacción, con la nota por qué cada regla existe hoy. Una flecha etiquetada calldata lleva a la caja capa de ejecución, que contiene EVM, cuentas, gas, receipts y logs. Una flecha etiquetada payload lleva a la caja capa de consenso, con validadores, votos y finalidad. Debajo de la capa de ejecución, una flecha etiquetada estado lleva a la caja aplicación con contratos, estándares e indexadores, anotada Solidity, seguridad y DeFi. Debajo de la capa de consenso, una flecha etiquetada datos y pruebas lleva a la caja escala con rollups, blobs y cuentas inteligentes, anotada L2 y account abstraction.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La capa de consenso divide el tiempo en slots de 12 segundos y épocas de 32 slots. Un bloque se considera finalizado cuando validadores que suman al menos dos tercios del ETH en stake votan un par de checkpoints que lo incluyen; revertirlo exigiría que una gran cantidad de stake fuera penalizada. [5]

Ahí está la respuesta al ticket. El explorador muestra el bloque más reciente; el backend probablemente espera al bloque finalizado. La API JSON-RPC de los nodos expone ambas vistas con las etiquetas latest, safe y finalized. [6]

# Ejemplo ilustrativo: necesitas un endpoint RPC propio en la variable RPC_URL.
# Compara el número del último bloque con el del último bloque finalizado.
for tag in latest finalized; do
  curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
    --data "{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockByNumber\",\"params\":[\"$tag\",false],\"id\":1}" \
    | python3 -c "import sys,json; print('$tag', int(json.load(sys.stdin)['result']['number'],16))"
done

La diferencia entre los dos números es la ventana en la que el orden todavía puede cambiar. El arco de consenso de la serie explica de dónde sale esa ventana; el de operación explica cómo un indexador debe tratarla.

Riesgo operativo: elegir la ruta según el problema que traes

La serie está pensada para leerse en orden, pero un equipo con experiencia en Rust, Node, Java o Terraform suele llegar con una pregunta concreta. La matriz siguiente propone atajos. Cada atajo tiene un costo: lo que te saltas aparecerá después como un supuesto que no sabes verificar.

El riesgo de los atajos es concreto. Un backend que trata latest como definitivo puede acreditar un depósito que luego desaparece en una reorganización. Un auditor que no entiende el layout de storage puede aprobar un proxy que sobrescribe variables. Un arquitecto que no distingue ejecución de consenso puede prometer que el Merge abarató el gas, cosa que la documentación oficial descarta explícitamente. [4]

Una regla práctica para saltar capítulos: puedes avanzar cuando sabes nombrar el estado que cambia, la evidencia que lo prueba y el riesgo que queda fuera. Si falta una de las tres, vuelve un capítulo.

Evidencia: cómo usar las fuentes de cada capítulo

Cada afirmación técnica de la serie lleva una marca numerada que apunta a su fuente. Las fuentes preferidas son, en este orden: las propuestas de mejora de Ethereum (EIPs, documentos públicos que especifican cada cambio de protocolo), las especificaciones formales, la documentación oficial y los anuncios de la Ethereum Foundation.

Cuando leas un EIP, empieza por cuatro secciones: Motivation (qué problema resuelve), Specification (la regla exacta), Backwards Compatibility (qué rompe) y Security Considerations (qué riesgos abre). Las fechas y bloques de activación salen del registro de forks, no del EIP individual.

Las afirmaciones sobre el roadmap futuro se tratan distinto: se fechan, porque cambian. Si un capítulo dice "hoy", la fecha de referencia es la de su última revisión.