Antes de Ethereum: Bitcoin, scripts y la máquina mundial

Piensa en un contrato de cobertura: A y B depositan el equivalente a 1000 dólares en BTC, y a los 30 días un programa debe enviar 1000 dólares en BTC a A y el resto a B. El whitepaper de Ethereum usa exactamente este ejemplo para mostrar algo que el script de Bitcoin no podía expresar bien. [1]

Este capítulo reconstruye ese argumento. Al final deberías poder explicar a un compañero por qué Ethereum eligió cuentas en lugar de UTXO, por qué cada transacción declara un límite de gas y qué significa que todos los nodos ejecuten el mismo código.

Preguntas guía

• ¿Qué cuatro limitaciones del script de Bitcoin enumera el whitepaper y cuál de ellas resuelve cada pieza de Ethereum?
• ¿Por qué una transacción paga gas por adelantado y recibe la diferencia al final?
• Si un contrato se queda sin gas a mitad de ejecución, ¿qué cambios sobreviven y cuáles no?
• ¿Qué partes del diseño de 2013 siguen vigentes y cuáles cambiaron después?

Conexiones dentro de la serie

• Antes: Ethereum: mapa de lectura antes de tocar Solidity para ubicar este capítulo.
• Después: Frontier, Homestead y The DAO: la red aprendió con golpes muestra qué pasó cuando el diseño llegó a producción.
• Profundización: Cuentas, claves y direcciones sin humo y EVM: stack, memory, storage y calldata detallan cuentas y EVM tal como funcionan hoy. Para el problema que Bitcoin ya resolvía, lee el ataque del doble gasto.

Historia del diseño: cuatro límites del script de Bitcoin

Bitcoin ya permitía programar condiciones de gasto. Cada moneda no gastada (un UTXO, unspent transaction output) lleva un pequeño script que dice quién puede gastarla. El whitepaper reconoce ese poder y enumera cuatro límites concretos. [1]

Sin Turing-completitud. El script de Bitcoin no tiene bucles, para evitar ejecuciones infinitas durante la verificación. Se pueden simular repitiendo código, pero el script crece mucho.

Ciego al valor. Un UTXO se gasta entero o no se gasta; el script no puede decidir montos finos. El contrato de cobertura de la introducción necesitaría fragmentar los fondos en muchos UTXO de distintas denominaciones.

Sin estado. Un UTXO está gastado o no; no hay forma de guardar un estado intermedio. Eso dificulta contratos de varias etapas, como una oferta en un exchange descentralizado.

Ciego a la cadena. El script no ve datos del bloque como el timestamp o el hash anterior, lo que limita, por ejemplo, aplicaciones que necesitan una fuente de aleatoriedad.

El whitepaper también revisa las alternativas de la época: construir una cadena propia, como hizo Namecoin, o montar un protocolo encima de Bitcoin, como los colored coins o las metacoins. La primera exige crear una red desde cero para cada aplicación. La segunda hereda los límites del script. La propuesta de Ethereum es una tercera vía: una sola cadena con un lenguaje de programación completo, donde cualquiera puede desplegar su lógica.

Traza de ejecución: APPLY(S, TX) paso a paso

El whitepaper define Ethereum como una función de transición de estado: dado un estado S y una transacción TX, produce un estado nuevo S' o un error. El estado es un conjunto de cuentas, cada una con una dirección de 20 bytes y cuatro campos: nonce, saldo de ether, código del contrato (si lo tiene) y storage, un almacenamiento clave-valor que empieza vacío.

Hay dos tipos de cuentas. Las cuentas externas se controlan con una clave privada y no tienen código. Las cuentas de contrato se controlan con su código, que se ejecuta cada vez que reciben un mensaje. Un contrato no es un "acuerdo" en sentido legal; el whitepaper lo describe como un agente autónomo que siempre ejecuta el mismo código cuando alguien lo invoca.

Figura 1

La función de transición de estado del whitepaper

Fuentes:

[1]

Cómo leer esta figura

Diagrama de flujo. A la izquierda, la caja estado S con cuentas y storage recibe una transacción TX. El paso 1, validar formato, firma y nonce, tiene una salida roja etiquetada inválida hacia la caja ERROR, estado sin cambio. El paso 2, cobrar por adelantado STARTGAS por GASPRICE e incrementar el nonce, lleva al paso 3, transferir el valor y, si el destino es un contrato, correr su código. Del paso 3 salen dos caminos: falla o se acaba el gas, donde se revierte todo salvo la fee y el minero cobra la fee; y éxito, donde el gas sobrante vuelve al emisor y el resultado es el estado S prima.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El whitepaper trae un ejemplo numérico con precios inventados para ilustrar. Un contrato de registro recibe una transacción con 10 ether de valor, 2000 de gas, un precio de 0,001 ether por unidad de gas y 64 bytes de datos. El nodo verifica que el emisor tenga 2000 × 0,001 = 2 ether y los descuenta. Cobra 850 de gas por los bytes de la transacción y quedan 1150. Transfiere los 10 ether y ejecuta el código, que consume 187. Sobran 963 de gas, así que devuelve 0,963 ether al emisor.

El orden importa. La fee se cobra antes de ejecutar, para que un atacante no pueda hacer trabajar a la red gratis. Si la ejecución falla o se queda sin gas, todos los cambios se revierten salvo el pago de la fee, que se queda el minero. Así, un bucle infinito siempre termina: se acaba el gas y alguien pagó por cada paso.

El código del ejemplo del whitepaper está escrito en Serpent, un lenguaje de la época. Esta es una traducción a Solidity moderno, solo para leer la lógica:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
 
/// Ilustrativo: equivalente en Solidity del registro de nombres que el
/// whitepaper escribe en Serpent. Quien registra una clave primero se la queda.
contract FirstComeRegistry {
    mapping(bytes32 => bytes32) public records;
 
    function register(bytes32 key, bytes32 value) external {
        if (records[key] == bytes32(0)) {
            records[key] = value;
        }
    }
}

Invariante: todos los nodos calculan el mismo S'

La regla central del diseño es simple de decir: cualquier nodo que parta del mismo estado y aplique las mismas transacciones en el mismo orden debe obtener exactamente el mismo resultado. Si dos nodos obtienen resultados distintos, la red se parte en dos.

Esa invariante explica decisiones que de otro modo parecen raras. La EVM no tiene acceso a la red ni al reloj del sistema. Las llamadas entre contratos tampoco escapan del límite: si A envía 1000 de gas a B y B gasta 600 antes de llamar a C, que gasta 300, a B le quedan 100. El gas acota la transacción completa, con todas sus subllamadas.

El whitepaper también reconoce que la EVM es Turing-completa: con JUMP y JUMPI se pueden escribir bucles infinitos. El problema de la parada (saber de antemano si un programa termina) no se resuelve; se esquiva. Cada paso cuesta gas, el gas tiene un límite y el emisor paga por adelantado.

Unos meses después, el Yellow Paper formalizó esta idea con precisión matemática: el protocolo como una máquina de estado transaccional, con cada operación y su costo definidos. Hoy sigue siendo la referencia formal de la capa de ejecución. [3]

Riesgo operativo: qué cambió desde 2013

La propia página del whitepaper en ethereum.org advierte que Ethereum evolucionó desde su concepción y remite a guías actualizadas. Leerlo como manual vigente es un error frecuente.

Tres cambios importan para el resto de la serie. Primero, los nombres: STARTGAS y GASPRICE hoy se llaman límite de gas y, desde London, el precio se divide en base fee y propina. Segundo, los números: una transferencia simple de ETH cuesta hoy 21,000 de gas antes de ejecutar cualquier código. [4] Tercero, el consenso: el whitepaper describe minería con proof-of-work, que Ethereum abandonó en septiembre de 2022.

Lo que no cambió es la estructura: cuentas con nonce, saldo, código y storage; transacciones firmadas que pagan gas; y una función de transición determinista. Si entiendes APPLY(S, TX), los capítulos de transacciones y EVM se leen como detalles de una idea que ya conoces.