Ya sabéis cómo funciona Ethereum por dentro: una única EVM compartida, cada nodo reejecutando cada transacción, todo ello asegurado por prueba de participación. Esa redundancia es la fuente de la seguridad de Ethereum, y también su cuello de botella. Como todos rehacen todo, la capa 1 (L1) de Ethereum solo puede procesar en torno a 15 transacciones por segundo. Cuando la red se satura, el espacio de bloque escasea, estalla una subasta de comisiones y un simple intercambio de tokens puede costar más de lo que vale el propio intercambio.
El arreglo predominante no es «hacer Ethereum más grande». Son los rollups de capa 2: cadenas separadas y más rápidas que hacen el trabajo pesado en otro sitio y luego comprueban sus deberes de vuelta en Ethereum. Esta lección trata de cómo funciona ese truco, y de por qué resulta más barato sin ser menos seguro.
El problema de la escalabilidad
De la lección sobre la EVM: ¿por qué no puede la L1 de Ethereum procesar miles de transacciones por segundo como hace un servidor web normal?
Pongámosle nombre a la cosa. El rendimiento (throughput) es cuántas transacciones puede liquidar una cadena por unidad de tiempo, medido normalmente en transacciones por segundo (TPS). La L1 de Ethereum ronda los 15 TPS. Visa, en comparación, gestiona miles. La brecha no se debe a que los ingenieros de Ethereum olvidaran teclear rápido: es una consecuencia deliberada del diseño que ya aprendisteis: miles de nodos reejecutan cada transacción para que no haya que confiar en nadie. Por tanto el espacio de bloque es escaso, y las cosas escasas se subastan, que es por lo que las comisiones de gas se disparan justo cuando más queréis transaccionar.
Esta tensión tiene un nombre: el trilema de la escalabilidad. Una cadena de bloques quiere tres cosas a la vez —seguridad (difícil de atacar), descentralización (cualquiera puede correr un nodo con hardware modesto) y escalabilidad (rendimiento alto)—, pero es brutalmente difícil maximizar las tres juntas. Disparad la escalabilidad exigiendo nodos potentes y caros, y sacrificáis en silencio la descentralización. La L1 de Ethereum elige deliberadamente seguridad y descentralización, y acepta un rendimiento base bajo. Los rollups son la forma ingeniosa de recomprar escalabilidad sin pagar con las otras dos.
Rellena los huecos sobre el problema de la escalabilidad.
Pick the right option for each blank, then check.
El rendimiento de la L1 de Ethereum, medido en , es bajo porque cada nodo debe . El dice que es difícil tener seguridad, descentralización y escalabilidad todas a la vez.
Qué hace un rollup
Es hora de las dos capas. La capa 1 (L1) es la cadena base —Ethereum en sí, con toda su seguridad y descentralización—. Una capa 2 (L2) es un sistema separado construido encima de la L1 que gestiona transacciones por ella y luego se apoya en la L1 para las garantías que no puede dar por sí mismo.
Un rollup (literalmente, «enrollado») es el tipo de L2 dominante. La receta tiene dos mitades:
- Ejecución fuera de la cadena. El rollup corre las transacciones en su propia cadena más rápida, una cadena que no necesita miles de nodos independientes reejecutando todo, así que puede ser barata y veloz.
- Datos y liquidación en la cadena. Periódicamente publica los datos comprimidos de las transacciones (y/o una prueba) de vuelta en la L1 de Ethereum. Un lote (batch) es ese paquete: muchas transacciones de L2 enrolladas en un único envío a L1 (de ahí el nombre «rollup»). Como los datos aterrizan en la L1, cualquiera puede reconstruir el estado de la L2 solo a partir de Ethereum —esa propiedad se llama disponibilidad de los datos (data availability)— y la L1 sigue siendo el tribunal final de la liquidación (settlement) y la seguridad.
La analogía: imaginad un restaurante a reventar. Si cada comensal entrara en la cocina y recitara su pedido individualmente, la cocina colapsaría: eso es la L1 intentando hacerlo todo. En su lugar, el camarero de cada mesa toma los pedidos en la sala (rápido, a un lado) y luego lleva un único comando consolidado a la cocina. La cocina (L1) sigue cocinando la comida canónica y es la única fuente de verdad sobre lo que se pidió, pero solo tuvo que leer un comando en vez de cien pedidos a gritos. El servicio ocurre fuera de la cadena; el registro autoritativo aterriza en la cadena.
La genialidad está en que conserváis el modelo de confianza de Ethereum. No tenéis que fiaros de la palabra del operador del rollup sobre vuestro saldo, porque los datos subyacentes se publican en la L1, donde se pueden comprobar.
En un rollup, ¿dónde ocurre la ejecución de las transacciones y dónde viven la liquidación final y la disponibilidad de los datos?
Por qué es más barato: repartir el coste de la L1
Aquí está la pregunta del millón, literalmente. Publicar un lote en Ethereum cuesta gas, un coste fijo que existe sin importar cuántas transacciones haya dentro del lote. El truco es que ese único coste se reparte entre todos los del lote. Meted más transacciones en un solo lote y el coste por usuario cae, porque la misma factura de L1 se divide entre más. Este reparto de un coste fijo se llama amortizarlo.
Subid el tamaño del lote abajo y observad cómo el coste por usuario se desploma mientras el coste total de L1 apenas se mueve. Cambiad el interruptor optimista/ZK para ver cómo cambia la lectura de finalidad: explicaremos esa diferencia en la siguiente sección.
- Coste en L1 de todo el lote
- 0.0225 ETH
- Coste por usuario
- 0.00045 ETH
- frente a ir directo a L1
- ≈ 8.9× cheaper
Fraud proof: the batch is assumed valid and anyone can challenge it within the window.
Un único lote de L1 transporta muchas transacciones de L2. El coste fijo de publicarlo se reparte entre todos los que van dentro, así que el coste por usuario cae en picado a medida que crece el lote: eso es amortización. Cambia entre optimista y ZK para ver cómo liquida cada uno.
Un ejemplo resuelto en números llanos. Supongamos que publicar un lote en la L1 cuesta unos 0,02 ETH en gas, y que 200 transacciones viajan en ese lote. La parte de cada usuario del coste de L1 es 0,02 / 200 = 0,0001 ETH, una centésima de uno por ciento de un ETH. Comparadlo con enviar una transacción de L1 independiente completa, que paga la tasa base entera ella sola. Cuantos más pasajeros compartan la factura fija del lote, más barato cada asiento. Duplicad el lote a 400 transacciones y la parte por usuario se reduce a la mitad de nuevo, a 0,00005 ETH. (Son cifras redondas ilustrativas, no una cotización en vivo.)
Una palanca más lo abarató drásticamente: EIP-4844, la actualización de los «blobs». Un blob es un trozo de espacio de datos barato y temporal en la L1, hecho a medida para los rollups: es mucho más barato que el almacenamiento de transacciones permanente y normal (calldata) y se borra automáticamente al cabo de unas semanas, lo cual está bien porque los rollups solo necesitan que los datos estén disponibles el tiempo suficiente para que cualquiera verifique el lote. Los blobs recortaron la factura de publicar datos, que es el coste dominante de un rollup, así que las comisiones por usuario cayeron en un orden de magnitud.
Empareja cada bloque de construcción de un rollup con lo que realmente es.
Pick a term, then click its definition.
Una definición rápida que acabáis de conocer: el secuenciador (sequencer) es el componente que recibe las transacciones entrantes de L2, decide su orden y las empaqueta en lotes. Hoy suele ser un único operador —cómodo y rápido, pero un punto de centralización que revisaremos en la sección de riesgos—.
Dos sabores: optimista frente a ZK
Todos los rollups publican datos en la L1. Difieren en cómo la L1 se convence de que el lote es realmente correcto, y esa única elección lo determina todo lo demás.
Rollups optimistas
Un rollup optimista (optimistic rollup) hace lo que dice el nombre: da por buenos todos los lotes y los publica sin prueba. La verificación es «inocente hasta que se demuestre lo contrario». Después de publicar un lote, hay una ventana de impugnación (challenge window) —típicamente de unos 7 días— durante la cual cualquiera que esté vigilando puede presentar una prueba de fraude (fraud proof): una demostración compacta, en la cadena, de que un lote concreto contenía una transición de estado inválida. Si aterriza una prueba de fraude válida, el lote malo se revierte y el tramposo pierde su fianza. Si nadie impugna con éxito dentro de la ventana, el lote queda firme.
- A favor: baratísimo de operar — sin criptografía cara por lote, solo publicar y esperar.
- En contra: finalidad de retirada lenta. Mover fondos de vuelta a la L1 implica aguardar toda la ventana de impugnación (los ~7 días), porque hasta entonces una prueba de fraude aún podría revocarlo todo.
Rollups ZK
Un rollup ZK (zero-knowledge rollup, de conocimiento cero) invierte la suposición a «culpable hasta que se demuestre la inocencia». A cada lote le adjunta una prueba de validez (validity proof, una prueba ZK): una pieza sucinta de criptografía que demuestra matemáticamente que la transición de estado del lote se computó correctamente, sin reejecutar todas las transacciones. La L1 verifica esa pequeña prueba al instante. Si cuadra, el lote es correcto: no hay nada que disputar ni ventana de espera.
- A favor: finalidad rápida. Una vez verificada la prueba de validez en la L1, el lote queda liquidado de inmediato, así que las retiradas no necesitan una espera de varios días.
- En contra: más pesado de producir. Generar esas pruebas criptográficas es caro en cómputo y, históricamente, más difícil de diseñar para una EVM totalmente general.
Cambiad el interruptor en la isla de arriba para ver cómo la lectura de finalidad alterna entre la espera de la ventana de impugnación optimista y la liquidación casi instantánea de ZK.
| Rasgo | Rollup optimista | Rollup ZK |
|---|---|---|
| Cómo se asegura la corrección | Se da por válido; cualquiera puede presentar una prueba de fraude para disputarlo | Una prueba de validez demuestra la corrección por adelantado |
| Finalidad de retirada | Lenta — aguardar la ventana de impugnación de ~7 días | Rápida — liquida en cuanto la prueba se verifica en la L1 |
| Coste de cómputo | Barato de operar (sin prueba por lote) | Pesado — generar pruebas de validez es caro |
| Redes de ejemplo | Optimism, Arbitrum | zkSync, Starknet |
Clasifica cada rasgo en la familia de rollup que describe.
Place each item in the right group.
- Adjunta una prueba de validez verificada en la L1 de inmediato
- Se apoya en pruebas de fraude para pillar los lotes malos
- Ofrece finalidad rápida a costa de un cómputo más pesado
- Barato de operar porque se salta la criptografía por lote
- Da por válidos los lotes salvo que se impugnen
- Tiene una ventana de impugnación de varios días antes de que finalicen las retiradas
Porque «demostrarlo criptográficamente» solía ser la parte difícil. Generar pruebas de validez para una EVM totalmente general es pesado en cómputo y fue, durante años, difícil de diseñar bien, así que los rollups optimistas salieron primero, maduraron primero y construyeron los ecosistemas y el utillaje más profundos. También son más simples y baratos de operar, ya que se saltan por completo la generación de pruebas por lote. El trato que aceptáis es la ventana de retirada lenta. La tecnología ZK avanza deprisa y puede que acabe ganando por méritos propios, pero la madurez del ecosistema, la simplicidad y la inercia mantienen hoy a los rollups optimistas muy en el juego.
Compromisos y riesgos
Los rollups son una victoria genuina, pero «hereda la seguridad de la L1» merece un asterisco. Un rollup hereda las garantías de Ethereum para la disponibilidad de los datos y la liquidación —los datos están en la L1, y la L1 es el tribunal final—. Pero los rollups añaden su propia superficie de riesgo encima:
- Secuenciadores centralizados. La mayoría de los rollups hoy corren un único secuenciador. No puede robaros los fondos (los datos y las pruebas lo mantienen honesto), pero sí puede censurar o retrasar vuestras transacciones, o caerse. Descentralizar los secuenciadores es un trabajo activo y sin terminar.
- Claves de actualización. Muchos rollups están gobernados por claves de administración/multifirma que pueden actualizar los contratos. Una clave maliciosa o comprometida es un riesgo real, mitigado por timelocks y multifirmas pero no nulo.
- Retraso en las retiradas (optimista). Esa ventana de impugnación de ~7 días significa que vuestros fondos no son instantáneamente portables de vuelta a la L1 —molesto, y un motivo por el que existen los «puentes rápidos» (que os adelantan el dinero por una comisión)—.
- Riesgo de puente (bridge). Mover activos entre L1 y L2 pasa por contratos de puente, que históricamente han sido jugosos objetivos de hackeo. El puente es tan seguro como su código.
Y un primo importante que conviene distinguir: una sidechain (cadena lateral) no es un rollup. Una sidechain corre su propio consenso independiente y aporta su propia seguridad: no publica sus datos en Ethereum, así que no hereda las garantías de la L1. Si los validadores de una sidechain conspiran, Ethereum no puede salvaros. La seguridad de un rollup está anclada a la L1; la de una sidechain está anclada solo a sí misma.
¿Qué afirmación captura con más precisión lo que un rollup hereda —y no hereda— de la L1 de Ethereum?
La imagen global
Big picture
Los rollups de capa 2 de un vistazo
- Rollups de capa 2
- Problema de escalabilidad
- Cada nodo reejecuta todo
- TPS bajo, espacio de bloque escaso
- Trilema de la escalabilidad
- Qué hace un rollup
- Ejecución fuera de la cadena en la L2
- Publica datos + pruebas en la L1
- La L1 conserva disponibilidad de datos y liquidación
- Más barato al amortizar
- Coste fijo del lote de L1 compartido por todos
- El coste por usuario cae al crecer el lote
- Los blobs abaratan los datos
- Optimista frente a ZK
- Optimista: dar por válido, pruebas de fraude
- ZK: prueba de validez, finalidad rápida
- Compromisos
- Secuenciador centralizado
- Retraso en las retiradas (optimista)
- Riesgo de puente y de clave de actualización
- Problema de escalabilidad
Un lote cuesta 0,05 ETH publicarlo en la L1 y transporta 500 transacciones. ¿Cuál es la parte amortizada del coste de L1 de cada usuario?
Comprueba tu respuesta para continuar.
Ideas clave
Qué recordar
- El problema: la L1 de Ethereum reejecuta todo en cada nodo, topando el rendimiento en unos 15 TPS y haciendo el espacio de bloque escaso y caro — el trilema de la escalabilidad en acción.
- El arreglo: un rollup de capa 2 ejecuta las transacciones fuera de la cadena en una L2 veloz y luego publica el lote comprimido de datos (y/o pruebas) de vuelta en la L1, que conserva la disponibilidad de los datos y la liquidación. Heredáis la seguridad de Ethereum sin fiaros del operador.
- Por qué es barato: el coste fijo de publicar un lote se amortiza entre todos los que van en él, así que el coste por usuario cae a medida que crece el lote — y los blobs (EIP-4844) abarataron drásticamente esos datos.
- Dos sabores: los rollups optimistas dan por válido y se apoyan en pruebas de fraude dentro de una ventana de impugnación de ~7 días (baratos, retiradas lentas); los rollups ZK adjuntan una prueba de validez verificada en la L1 de inmediato (finalidad rápida, más pesados de producir).
- Cuidado con: los secuenciadores centralizados, las claves de actualización, el retraso de retirada optimista y el riesgo de puente. Y una sidechain no es un rollup — se asegura a sí misma, no vía la L1.
Ese es el arco completo. Habéis ido desde «¿qué es Ethereum?» pasando por la EVM, las cuentas, el gas, los contratos y la prueba de participación, y ahora subiendo la escalera de la escalabilidad hasta los rollups de capa 2 — el diseño sobre el que el ecosistema está construyendo de verdad. Entendéis Ethereum de principio a fin. Queda una cosa: demostrarlo. Id al examen final de este tema y juntadlo todo.