Rollups desde cero: ejecutar fuera, resolver dentro

Si alguna vez optimizaste una base de datos, conoces el truco: en vez de mil INSERT sueltos, haces uno con mil filas. Pagas una vez el coste fijo de la operación y repartes el resto. Un rollup aplica esa idea a Ethereum, con una condición extra muy exigente: Ethereum tiene que poder comprobar, o al menos castigar, cualquier lote que mienta sobre el resultado.

Este capítulo construye el modelo desde cero. Una L2 (capa 2) es un sistema que procesa transacciones fuera de la red principal de Ethereum, llamada L1, y obtiene su seguridad de ella. Los rollups son la familia de L2 que publica en L1 los datos de sus transacciones y una afirmación verificable sobre el estado resultante. [1]

Preguntas guía

• ¿Por qué Ethereum no sube simplemente su capacidad de ejecución?
• ¿Qué publica un rollup en L1 y por qué no basta con publicar solo el resultado?
• ¿Qué diferencia a un rollup de una sidechain o de un validium?
• Si el secuenciador desaparece o te censura, ¿cómo recuperas tus fondos?

Conexiones dentro de la serie

• Antes: Transacciones, gas y receipts explica qué cuesta publicar bytes en L1; The Merge cierra el bloque de consenso.
• Después: Optimistic rollups y ZK rollups desarrollan las dos formas de verificar; EIP-4844 y blobs explica dónde se publican hoy los datos; Bridges amplía el riesgo de mover valor entre cadenas.
• Investigación relacionada: privacidad y zero-knowledge en consenso introduce las pruebas que usan los ZK rollups.

Cuello de botella: por qué L1 no ejecuta más

En Ethereum cada nodo completo descarga y ejecuta cada transacción para comprobar por sí mismo que el bloque es correcto. Eso es lo que permite "no confiar, verificar". El precio es que la capacidad total está limitada por lo que un nodo modesto puede procesar. Si se sube el límite de gas sin más, el hardware necesario crece y menos personas pueden operar nodos. ethereum.org lo plantea como el objetivo central del escalado: más velocidad y capacidad sin sacrificar descentralización ni seguridad. [1]

Un rollup ataca el problema separando dos trabajos que en L1 van juntos: ejecutar y verificar. La ejecución pasa a una máquina fuera de L1. A L1 solo le quedan tareas baratas por transacción: guardar datos comprimidos, guardar una raíz de estado y, cuando hace falta, resolver una disputa o verificar una prueba.

Historia: del sharding a una hoja de ruta centrada en rollups

Durante años, el plan para escalar Ethereum era el sharding de ejecución: dividir la cadena en fragmentos validados por subconjuntos de validadores. ethereum.org explica que ese plan se abandonó porque los rollups avanzaron rápido y porque danksharding, una forma de añadir a los bloques datos baratos para rollups, permitía escalar con una lógica de consenso más simple. [1]

La motivación de EIP-4844 lo dice de forma directa: a corto y medio plazo, y quizá a largo plazo, los rollups son la única solución de escalado sin confianza para Ethereum. Esa EIP, activada en marzo de 2024, creó los blobs, un espacio de datos separado y temporal pensado para ellos. [2]

Traza de ejecución de un lote: qué sale de L2 y qué entra en L1

Sigue una transferencia en un rollup. El usuario firma una transacción de L2 y la envía al secuenciador, el nodo que ordena y ejecuta. El secuenciador acumula muchas transacciones, las ejecuta sobre el estado de L2 y obtiene una nueva raíz de estado: un hash de 32 bytes que resume todas las cuentas y saldos (una raíz de árbol de Merkle). Luego publica en L1 dos cosas: los datos comprimidos del lote y la nueva raíz. [3]

Figura 1

Anatomía de un rollup: ejecución fuera, datos y verificación dentro

Fuentes:

[3][4]

Cómo leer esta figura

Diagrama en dos bandas. Arriba, L2 fuera de Ethereum: los usuarios firman transacciones de L2 y las envían al secuenciador, que las ordena y ejecuta y produce un nuevo estado con raíz r sub n más 1. Abajo, L1 Ethereum: el secuenciador publica un lote comprimido como datos en calldata o blob, y una raíz propuesta llega al contrato del rollup, que guarda la raíz anterior y la nueva. Una flecha discontinua indica que con los datos del lote se puede reconstruir el estado. El contrato pasa la raíz a verificación, que puede ser por fraude con ventana o por prueba de validez, y entrega la raíz aceptada al puente, que paga retiros con prueba Merkle. A la izquierda, una flecha discontinua ocre va de los usuarios a una cola en L1 de depósitos y transacciones: es la inclusión forzada si hay censura.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El ahorro viene de amortizar. Una transacción de L1 tiene un coste base de 21000 gas, y cada byte de calldata distinto de cero cuesta 16 gas desde EIP-2028. Si un lote empaqueta N transacciones, ese coste base y la verificación se dividen entre N, y la compresión reduce los bytes de cada una. ethereum.org señala ejemplos concretos, como sustituir direcciones de 20 bytes por índices de cuenta. Desde Pectra, EIP-7623 añade un precio mínimo: una transacción dominada por datos paga al menos 10 gas por "token" de calldata, donde un byte distinto de cero cuenta como cuatro tokens. [8] [5] [4]

// Ilustrativo: coste de L1 por transacción de L2 en un lote.
// Los valores reales dependen del precio del gas o del blob en cada momento.
function l1CostPerTx({ fixedGas, verifyGas, bytesPerTx, gasPerByte, txsInBatch }) {
  const batchGas = fixedGas + verifyGas + bytesPerTx * gasPerByte * txsInBatch;
  return batchGas / txsInBatch; // gas de L1 atribuible a cada transacción
}

Invariante de seguridad: datos disponibles y una regla de validez

Un rollup es seguro si se cumplen dos condiciones a la vez. La primera es la disponibilidad de datos: cualquiera debe poder descargar lo necesario para reconstruir el estado de L2. La segunda es una regla de validez que L1 hace cumplir: o bien una prueba de fraude permite impugnar una raíz falsa durante una ventana, o bien una prueba de validez demuestra que la raíz es correcta antes de aceptarla. [6]

Las dos condiciones se necesitan entre sí. Sin datos, nadie puede construir una prueba de fraude, y los usuarios no pueden demostrar qué les pertenece para salir. Con datos pero sin regla de validez, L1 guardaría raíces que nadie puede discutir. ethereum.org insiste en que, para los optimistic rollups, la disponibilidad es crítica precisamente porque sin acceso a los datos los retadores no pueden construir pruebas de fraude. [3]

Riesgo operativo: sigue la salida de emergencia

Para evaluar un rollup, empieza por una pregunta incómoda: si el secuenciador desaparece hoy, ¿qué mecanismo te permite recuperar fondos? En la mayoría de los rollups hay un único secuenciador, y ethereum.org reconoce que puede censurar transacciones o dejar de producir lotes. La defensa es la inclusión forzada: el usuario envía su transacción directamente a un contrato en L1, y el rollup queda obligado a procesarla dentro de un plazo. [3] [4]

El segundo punto a revisar es quién puede cambiar los contratos de L1. Un puente que custodia fondos es código; si alguien puede actualizarlo o pausarlo, esa persona forma parte del modelo de confianza. La especificación de OP Stack, por ejemplo, define un rol Guardian capaz de pausar el portal de retiros y descartar juegos de disputa. Eso no es necesariamente malo, pero debe aparecer en tu análisis de riesgo como lo que es. [7]

Laboratorio mínimo: reconstruir el estado a partir de lotes

Un ejercicio local ayuda a interiorizar el invariante. Escribe un "rollup de juguete" en el lenguaje que prefieras: una lista de saldos, una función que aplica transferencias y una función que calcula un hash del estado. Publica cada lote en un archivo (tu "L1") junto con la raíz resultante. Luego borra el estado y reconstrúyelo leyendo solo los lotes.

La validación observable es que la raíz reconstruida coincide con la publicada. Después introduce una raíz falsa en un lote y escribe un verificador que la detecte reejecutando ese lote: acabas de construir, en miniatura, la idea de la prueba de fraude. Si en lugar de reejecutar exigieras una prueba criptográfica, estarías en el terreno de los ZK rollups.

Quédate con esta frase: un rollup traslada la ejecución, no la confianza. La confianza sigue en L1 mientras los datos estén disponibles y exista una regla de validez que nadie pueda saltarse.