---
title: "Optimistic rollups"
description: "Guía específica por despliegue sobre recibos del secuenciador, datos de derivación en L1, cabeceras unsafe/safe/finalized, juegos de fault proofs, retiros canónicos, gobernanza y salidas rápidas."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Optimistic rollups

> Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

<a id="answer"></a>

## Respuesta directa

Un optimistic rollup ejecuta un flujo ordenado de transacciones y publica datos de derivación y afirmaciones de estado definidos por el protocolo, sin adjuntar una prueba de validez a cada lote. «Optimistic» significa que una afirmación admisible puede avanzar conforme a las reglas desplegadas, salvo que una disputa de fault proof resuelta con éxito demuestre que es errónea. No significa que un mensaje del secuenciador pruebe la corrección, ni que toda implementación admita impugnaciones sin permiso o tenga el mismo plazo de retiro.

Los nodos del rollup derivan de forma independiente los bloques L2 a partir de entradas L1 canónicas y de la configuración exacta del protocolo. Por tanto, la ruta de seguridad comprende disponibilidad de datos, derivación y ejecución correctas, un sistema de fault proofs activo y sólido, acceso y finalidad de L1, gobernanza y contratos del puente. Una raíz de estado por sí sola no basta para reconstruir la cadena ni impugnar una transición inválida.

<a id="mechanism"></a>

## Cómo funciona

1. Fije el despliegue: identificadores de cadena L1 y L2, configuración y fork del rollup, contratos de inbox y puente, formato de lote y modo de DA, contratos de afirmación de estado y juego de disputa, versión del portal, administradores, guardianes y bloque de observación. La documentación de un stack no demuestra que cada función esté activa en una cadena concreta.
2. Clasifique el estado observado. Un recibo del secuenciador o bloque unsafe es un compromiso local y rápido de ordenación; un lote publicado en L1 puede sustentar una cabecera derivada safe; la finalidad de L1 puede sustentar una cabecera derivada finalized. Una afirmación de estado o de salida, una disputa resuelta y un retiro ejecutable son objetos y relojes distintos.
3. Reconstruya el proceso de derivación de L1 a L2. Verifique depósitos y entradas secuenciadas, canales y lotes, orígenes L1, cambios de configuración y transiciones de estado a partir de datos L1 canónicos. Para datos respaldados por blobs, distinga la disponibilidad durante la ventana del protocolo de la recuperación archivística posterior.
4. Trace la vivacidad y el control. Separe secuenciador, batcher, proponente, impugnador, relayer, guardián y autoridad de actualización; compruebe si existen rutas de inclusión forzada o delayed inbox, sus demoras y condiciones de pausa, y si los usuarios ordinarios disponen de software operativo para invocarlas.
5. Verifique la ruta de fault proofs desplegada. Registre el tipo de juego reconocido, permisos de propuesta e impugnación, bonds, preestado absoluto, programa de prueba y VM, oráculo de preimágenes, profundidad de la afirmación, relojes y extensiones, reglas de resolución, facultades de blacklist o pausa y demora de actualización. No trasplante la mecánica de OP Stack a Arbitrum ni a otro rollup.
6. Siga por separado los retiros y su economía. Recorra iniciación en L2, prueba en L1, dependencia de afirmación o juego, demora de madurez y finalidad, repetición de la prueba, controles del portal y ejecución en L1. Trate una salida rápida como una operación de liquidez o crédito con precio y contraparte propia, no como un acortamiento del reloj canónico de impugnación.
7. Concilie continuamente. Compare hashes de bloques unsafe, safe y finalized, transacciones de lote en L1, afirmaciones de estado, resultados de juegos, mensajes de puente, recibos, contratos de tokens y saldos finales. Reabra el análisis tras una reorganización L1 o L2, lote ausente, disputa, pausa, actualización contractual o migración de DA.

<a id="example"></a>

## Ejemplos resueltos

- **Payload de derivación.** Un lote contiene `10,000` transacciones, `1,200 KB` de entradas de protocolo sin comprimir y `300 KB` tras la compresión. La razón es `1,200 / 300 = 4.0x`, la reducción es `1 - 300 / 1,200 = 75%` y el promedio decimal es `300,000 / 10,000 = 30 bytes/tx`. Estas cifras solo describen el payload de entrada codificado, no el gas L1, la corrección de la ejecución, el tamaño del estado ni las garantías de archivo.
- **Contribución antes de costes omitidos.** Los usuarios pagan `2.4 ETH`; la ejecución L2 medida cuesta `0.3 ETH`; la DA en L1 cuesta `1.2 ETH`. El residual es `2.4 - 0.3 - 1.2 = 0.9 ETH`, o `0.9 / 10,000 = 0.00009 ETH/tx`. No es beneficio neto porque excluye infraestructura del operador, ejecución L1, juegos de prueba, reembolsos, capital, fallos e impuestos.
- **Localización de una disputa.** Una traza didáctica de ejecución tiene `2^20 = 1,048,576` pasos. Un estrechamiento binario ideal requiere `log2(2^20) = 20` elecciones para aislar un paso. Si cada ronda didáctica tuviera un máximo independiente de `3-hour`, un límite serial ingenuo sería `20 * 3 = 60 hours`; los protocolos reales aplican sus propios relojes de ajedrez, concurrencia, extensiones y calendario de transacciones.
- **Relojes de retiro y liquidez rápida.** Un lote didáctico llega a L1 después de `10 minutes`, aparece una afirmación reconocida tras otros `30 minutes`, un período hipotético de impugnación dura `7 days` y el relay final tarda `2 hours`. El tiempo secuencial es `10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes`. Un puente de liquidez que anticipa `4.97 ETH` contra una afirmación de `5 ETH` cobra `0.03 ETH`, es decir, `0.03 / 5 = 0.6%`, mientras la afirmación canónica sigue sujeta a sus relojes y riesgos originales.

<a id="risks"></a>

## Riesgos

- L1, L2, identificadores de cadena, configuración o contratos equivocados.
- Tratar un recibo unsafe del secuenciador como safe o final.
- Equivocación, censura, reordenación o caída del secuenciador.
- Publicación L1 del lote demorada, ausente, malformada o inválida.
- Datos de blobs o DA alternativa no disponibles o no archivados.
- Incompatibilidad del cliente de derivación, configuración o fork.
- Reorganización L1 que invalida entradas antes consideradas safe.
- Caída del batcher, proponente de estado o participante de pruebas.
- Ruta de inclusión forzada o delayed inbox ausente, pausada o mal entendida.
- Fault proofs no desplegados, inactivos o vinculados al tipo de juego incorrecto.
- Funciones de proponente o impugnador con permiso o allowlist.
- Impugnador desconectado, censurado, sin fondos o fuera de plazo.
- Error en programa de prueba, VM, preestado absoluto, oráculo o verificador.
- Error de reloj, extensión, posición de afirmación, bond o contabilidad de resolución.
- Intervención de guardián, consejo de seguridad, pausa o blacklist.
- Actualización inmediata, timelock corto o claves administrativas comprometidas.
- Vulnerabilidad del puente canónico, mensajero, replay o mapeo de activos.
- Fallo de prueba, madurez, nueva prueba, finalización o relay del retiro.
- Riesgo de liquidez, precio, ruta, insolvencia o contraparte en la salida rápida.
- Confundir finalidad L1, finalidad L2 derivada, resolución de la afirmación y recepción del activo.

<a id="misconceptions"></a>

## Errores comunes

- Optimistic significa que los usuarios confían incondicionalmente en el resultado mostrado por el secuenciador.
- Publicar solo una raíz de estado aporta disponibilidad de datos y derivación independiente.
- Todo optimistic rollup tiene fault proofs sin permiso activos y un reloj universal de siete días.
- Un bloque L2 safe o finalized implica que su retiro de L2 a L1 ya puede ejecutarse.
- Un puente rápido acorta el período canónico de impugnación o solo soporta riesgo del rollup.

<a id="related"></a>

## Temas relacionados

- [Fault proofs](/es/crypto/fraud-proof/)
- [Disponibilidad de datos](/es/crypto/data-availability/)
- [Rollups](/es/crypto/rollup/)

<a id="sources"></a>

## Fuentes

- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultado: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (consultado: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consultado: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consultado: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (consultado: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (consultado: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultado: 2026-08-13)

Source: https://wiki.fcontext.com/es/crypto/optimistic-rollup/index.mdx