Frontier, Homestead y The DAO: la red aprendió con golpes

El 17 de junio de 2016, la Ethereum Foundation publicó una alerta: un atacante estaba drenando el ether de The DAO, un contrato de inversión colectiva, hacia un contrato hijo. El protocolo funcionaba bien; el fallo estaba en el contrato. Aun así, la respuesta terminó en un hard fork y en dos cadenas que siguen existiendo hoy. Este capítulo explica cómo se llegó ahí.

Antes hay que ver la red que recibió el golpe. El registro oficial de forks ubica cada paso con fecha y bloque, y es la fuente de las alturas que aparecen aquí. [1]

Preguntas guía

• ¿Qué cambió Homestead en la creación de contratos y en las firmas de transacciones?
• ¿Por qué un contrato que envía ether antes de actualizar su contabilidad puede ser vaciado?
• ¿En qué se diferencia el DAO fork de un fork que cambia reglas del protocolo?
• Después de un fork contencioso, ¿por qué una transacción firmada para una cadena puede ejecutarse en la otra?

Conexiones dentro de la serie

• Antes: Antes de Ethereum: Bitcoin, scripts y la máquina mundial explica el modelo de cuentas y gas que aquí se pone a prueba.
• Después: Metropolis a Istanbul: Ethereum madura antes del Merge sigue con los forks de 2017 a 2020.
• Profundización: Reentrancy: la llamada externa que muerde de vuelta desarrolla el patrón de ataque con un lab; Access control: owner, roles, multisig y timelocks trata cómo limitar el daño de un contrato con fallas.

Historia de Frontier y Homestead: una red para desarrolladores

Frontier arrancó el 30 de julio de 2015. ethereum.org la describe como una implementación funcional pero mínima, pensada para usuarios técnicos. Durante las primeras semanas cada bloque tenía un límite de 5,000 de gas, menos que los 21,000 que cuesta una transferencia simple: los mineros podían arrancar, pero nadie podía mover ether todavía. El fork "Frontier thawing" del bloque 200,000 levantó ese límite.

Homestead se activó en el bloque 1,150,000, el 14 de marzo de 2016. Su especificación agrupa tres propuestas: EIP-2, EIP-7 y EIP-8. [2]

EIP-2 es la que más afecta a un desarrollador. Crear un contrato con una transacción pasa a costar 53,000 de gas de base en lugar de 21,000. Si la creación no tiene gas suficiente para guardar el código, falla por completo en lugar de dejar un contrato vacío. Y las firmas con un valor s mayor que la mitad del orden de la curva secp256k1 pasan a ser inválidas, lo que elimina la maleabilidad: antes cualquiera podía invertir s y v y obtener otra firma válida de la misma transacción sin conocer la clave. [3]

EIP-7 añadió el opcode DELEGATECALL: ejecutar el código de otro contrato en el contexto propio (el mismo storage), conservando el emisor y el valor de la llamada original. Es la pieza sobre la que, años después, se construyeron los contratos actualizables mediante proxy. [10]

Traza de ejecución del ataque: llamar antes de actualizar

The DAO custodiaba ether de sus participantes y les permitía "dividirse" (split): salir hacia un contrato hijo, un DAO nuevo, con sus fondos. La alerta de la fundación describe el fallo como una vulnerabilidad de llamada recursiva en la función de división. El atacante hacía que el contrato le enviara ether y, antes de que el contrato registrara el retiro, volvía a pedir. [4]

El patrón se entiende mejor con un contrato mínimo. Este código no es el de The DAO; es una versión reducida del mismo error:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
 
/// Ilustrativo y vulnerable. NO es el código de The DAO: reproduce el patrón
/// "enviar ether antes de actualizar el saldo".
contract VulnerableVault {
    mapping(address => uint256) public balances;
 
    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }
 
    function withdraw() external {
        uint256 amount = balances[msg.sender];
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "transfer failed");
        // Demasiado tarde: durante la llamada anterior el receptor pudo
        // invocar withdraw() otra vez y leer el mismo saldo.
        balances[msg.sender] = 0;
    }
}

La traza es esta. El atacante deposita desde un contrato propio y llama a withdraw. La bóveda envía ether, y eso ejecuta el código del atacante, que vuelve a llamar a withdraw. Como el saldo todavía no se puso a cero, la bóveda paga otra vez. El ciclo se repite hasta agotar el gas o los fondos. La corrección es mover balances[msg.sender] = 0 antes de la llamada externa.

En The DAO había un detalle que dio margen: el ether drenado quedó en un DAO hijo, y la alerta explicaba que el atacante no podría retirarlo durante al menos unos 27 días, el período de creación del hijo. Ese plazo abrió el debate sobre qué hacer.

Invariante rota: un cambio de estado irregular en el bloque 1,920,000

La invariante de la que hablaba el capítulo anterior es que todos los nodos aplican las mismas reglas a las mismas transacciones. El DAO fork no cambió ninguna regla. Según su especificación, opcodes, formato de transacciones y estructura de bloques quedaron iguales. Lo que hizo fue un cambio de estado irregular: una modificación de saldos que no proviene de ninguna transacción. [5]

La mecánica es precisa. En el bloque 1,880,000 se fijó una lista L de cuentas: The DAO, su cuenta extraBalance y todos los DAO hijos con las suyas. Al comienzo del bloque 1,920,000, todo el ether de esas cuentas se transfirió a un contrato de reembolso, WithdrawDAO, en 0xbf4ed7b27f1d666546e30d74d50d173d20bca754. Ese contrato tiene una sola función útil: withdraw, que devuelve 1 ETH por cada 100 tokens DAO.

Figura 1

El DAO fork: una historia común y dos estados distintos

Fuentes:

[5]

Cómo leer esta figura

Línea de tiempo horizontal de bloques con una marca vertical en el bloque 1,920,000. A la izquierda, la caja historia común hasta el bloque 1,919,999. De ella salen dos flechas: una verde hacia la caja cadena con el fork, ETH, donde un cambio de estado irregular mueve el ether de las cuentas de la lista L a WithdrawDAO; y una ocre hacia la caja cadena sin el fork, ETC, con las mismas reglas y ningún saldo movido. Debajo, una nota explica que la misma clave y el mismo formato de transacción en ambas cadenas permiten que una firma válida en una también sea válida en la otra, lo que se llama replay. A la derecha, una caja azul: EIP-155, noviembre de 2016, la firma incluye CHAIN_ID.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La decisión no la tomó un administrador. Los clientes publicaron versiones con el fork activado o desactivado, y cada operador eligió. ethereum.org registra que la opción se votó con transacciones en una plataforma abierta a cualquier poseedor de ETH y superó el 85 % de los votos. Algunos mineros rechazaron el fork con el argumento de que el fallo no estaba en el protocolo, y esa cadena siguió como Ethereum Classic.

El día del fork, la fundación informó que el bloque 1,920,000 movió unos 12 millones de ETH desde los contratos del atacante y de un grupo de rescate al contrato de reembolso. [6]

Riesgo operativo: dos cadenas, una misma firma

Ese mismo anuncio advertía a quien siguiera la cadena sin fork que tuviera cuidado con los ataques de replay. Ambas cadenas compartían claves, direcciones y formato de transacción. Una transferencia firmada para una red era válida en la otra, y cualquiera podía retransmitirla.

La solución llegó con Spurious Dragon, en el bloque 2,675,000. Su especificación incluye EIP-155, EIP-160, EIP-161 y EIP-170. [7] EIP-155 hace que la firma cubra también un identificador de cadena (CHAIN_ID, que vale 1 en la red principal). Una transacción firmada así solo es válida en la cadena para la que se firmó. [8]

Entre el DAO fork y Spurious Dragon hubo otro incidente: ataques de denegación de servicio en septiembre y octubre de 2016 que abusaban de opcodes demasiado baratos para el trabajo que imponían a los nodos. Tangerine Whistle, en el bloque 2,463,000, subió esos precios con EIP-150: SLOAD pasó de 50 a 200 de gas, BALANCE de 20 a 400 y CALL y EXTCODESIZE a 700. También introdujo la regla de "todo menos 1/64": una llamada solo puede reenviar como máximo 63/64 del gas que queda. [9]

La lección operativa para un equipo de hoy tiene tres partes. Un contrato con fondos ajenos es un sistema de producción: la regla de "actualizar estado antes de llamar afuera" no es estilo, es seguridad. Un hard fork es una decisión de cada operador de nodo, y tu infraestructura debe saber qué versión corre. Y cualquier sistema que firme transacciones debe fijar el chainId correcto; las librerías actuales lo hacen por defecto, pero conviene verificarlo en las pruebas.