---
title: "Optimistic rollups"
description: "Guia específico por implantação sobre recibos do sequenciador, dados de derivação em L1, heads unsafe/safe/finalized, jogos de fault proof, retiradas canônicas, governança e saídas 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
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Um optimistic rollup executa um fluxo ordenado de transações e publica dados de derivação e afirmações de estado definidos pelo protocolo, sem anexar uma prova de validade a cada lote. “Optimistic” significa que uma afirmação elegível pode avançar segundo as regras implantadas, a menos que uma disputa de fault proof bem-sucedida demonstre que ela está errada. Não significa que uma mensagem do sequenciador prove correção, nem que toda implementação tenha contestações sem permissão ou o mesmo prazo de retirada.
Os nós do rollup derivam blocos L2 de forma independente a partir de entradas L1 canônicas e da configuração exata do protocolo. Portanto, o caminho de segurança inclui disponibilidade de dados, derivação e execução corretas, um sistema de fault proof ativo e sólido, acesso e finalidade de L1, governança e contratos da ponte. Uma raiz de estado isolada não basta para reconstruir a cadeia ou contestar uma transição inválida.
## Como funciona
1. Fixe a implantação: IDs das cadeias L1 e L2, configuração e fork do rollup, contratos de inbox e ponte, formato do lote e modo de DA, contratos de afirmação de estado e jogo de disputa, versão do portal, administradores, guardiões e bloco de observação. A documentação de um stack não comprova que todo recurso esteja ativo em uma cadeia específica.
2. Classifique o estado observado. Um recibo do sequenciador ou bloco unsafe é um compromisso local e rápido de ordenação; um lote publicado em L1 pode sustentar um head derivado safe; a finalidade de L1 pode sustentar um head derivado finalized. Uma afirmação de estado ou output, uma disputa resolvida e uma retirada executável são objetos e relógios distintos.
3. Reconstrua o pipeline de derivação de L1 para L2. Verifique depósitos e entradas sequenciadas, canais e lotes, origens L1, alterações de configuração e transições de estado usando dados L1 canônicos. Para dados respaldados por blobs, diferencie disponibilidade durante a janela do protocolo de recuperação histórica posterior.
4. Mapeie vivacidade e controle. Separe sequenciador, batcher, proponente, contestador, relayer, guardião e autoridade de upgrade; verifique se há caminhos de inclusão forçada ou delayed inbox, seus atrasos e condições de pausa, e se usuários comuns dispõem de software funcional para acioná-los.
5. Verifique o caminho de fault proof implantado. Registre o tipo de jogo respeitado, permissões de proposta e contestação, bonds, pré-estado absoluto, programa de prova e VM, oráculo de preimagem, profundidade da afirmação, relógios e extensões, regras de resolução, poderes de blacklist ou pausa e atraso de upgrade. Não transplante a mecânica do OP Stack para Arbitrum ou outro rollup.
6. Rastreie retiradas e economia separadamente. Acompanhe iniciação em L2, prova em L1, dependência da afirmação ou do jogo, atrasos de maturidade e finalidade, nova prova, verificações do portal e execução em L1. Trate uma saída rápida como operação de liquidez ou crédito precificada e com contraparte própria, não como redução do relógio canônico de contestação.
7. Reconcilie continuamente. Compare hashes de blocos unsafe, safe e finalized, transações de lote em L1, afirmações de estado, resultados de jogos, mensagens da ponte, recibos, contratos de tokens e saldos finais. Reabra a análise após reorganização L1 ou L2, lote ausente, disputa, pausa, upgrade de contrato ou migração de DA.
## Exemplos resolvidos
- **Payload de derivação.** Um lote contém `10,000` transações, `1,200 KB` de entradas brutas do protocolo e `300 KB` após compressão. A razão é `1,200 / 300 = 4.0x`, a redução é `1 - 300 / 1,200 = 75%` e a média decimal é `300,000 / 10,000 = 30 bytes/tx`. Esses números descrevem apenas o payload codificado, não gas em L1, correção da execução, tamanho do estado ou garantias de arquivo.
- **Contribuição antes dos custos omitidos.** Usuários pagam `2.4 ETH`; a execução L2 medida custa `0.3 ETH`; a DA em L1 custa `1.2 ETH`. O residual é `2.4 - 0.3 - 1.2 = 0.9 ETH`, ou `0.9 / 10,000 = 0.00009 ETH/tx`. Não é lucro líquido porque omite infraestrutura do operador, execução L1, jogos de prova, reembolsos, capital, falhas e tributos.
- **Localização da disputa.** Uma trilha didática de execução tem `2^20 = 1,048,576` passos. Um estreitamento binário ideal exige `log2(2^20) = 20` escolhas para isolar um passo. Se cada rodada didática tivesse um máximo separado de `3-hour`, um limite serial ingênuo seria `20 * 3 = 60 hours`; protocolos reais usam seus próprios relógios de xadrez, concorrência, extensões e agenda de transações.
- **Relógios de retirada e liquidez rápida.** Um lote didático chega a L1 após `10 minutes`, uma afirmação reconhecida surge após mais `30 minutes`, um período hipotético de contestação dura `7 days` e o relay final leva `2 hours`. O tempo sequencial é `10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes`. Uma ponte de liquidez que antecipa `4.97 ETH` contra uma afirmação de `5 ETH` cobra `0.03 ETH`, ou `0.03 / 5 = 0.6%`, enquanto a afirmação canônica permanece sujeita aos relógios e riscos originais.
## Riscos
- L1, L2, IDs de cadeia, configuração ou contratos incorretos.
- Tratar um recibo unsafe do sequenciador como safe ou final.
- Equivocação, censura, reordenação ou indisponibilidade do sequenciador.
- Publicação do lote em L1 atrasada, ausente, malformada ou inválida.
- Dados de blob ou DA alternativa indisponíveis ou não arquivados.
- Divergência de cliente de derivação, configuração ou fork.
- Reorganização de L1 invalidando entradas antes consideradas safe.
- Indisponibilidade do batcher, proponente de estado ou participante da prova.
- Caminho de inclusão forçada ou delayed inbox ausente, pausado ou mal compreendido.
- Fault proofs não implantados, inativos ou associados ao tipo de jogo errado.
- Papéis de proponente ou contestador permissionados ou em allowlist.
- Contestador offline, censurado, subcapitalizado ou fora do prazo.
- Falha no programa de prova, VM, pré-estado absoluto, oráculo ou verificador.
- Erro de relógio, extensão, posição da afirmação, bond ou contabilidade da resolução.
- Intervenção de guardião, conselho de segurança, pausa ou blacklist.
- Upgrade imediato, timelock curto ou chaves administrativas comprometidas.
- Vulnerabilidade da ponte canônica, mensageiro, replay ou mapeamento de ativos.
- Falha na prova, maturidade, nova prova, finalização ou relay da retirada.
- Risco de liquidez, preço, roteamento, insolvência ou contraparte na saída rápida.
- Confundir finalidade de L1, finalidade L2 derivada, resolução da afirmação e recebimento do ativo.
## Equívocos comuns
- Optimistic significa que os usuários confiam incondicionalmente no resultado exibido pelo sequenciador.
- Publicar apenas uma raiz de estado fornece disponibilidade de dados e derivação independente.
- Todo optimistic rollup tem fault proofs sem permissão ativos e um relógio universal de sete dias.
- Um bloco L2 safe ou finalized significa que sua retirada de L2 para L1 já pode ser executada.
- Uma ponte rápida encurta o período canônico de contestação ou carrega apenas risco do rollup.
## Tópicos relacionados
- [Fault proofs](/pt-br/crypto/fraud-proof/)
- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Rollups](/pt-br/crypto/rollup/)
## Fontes
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (acessado em: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (acessado em: 2026-08-13)
Source: https://wiki.fcontext.com/pt-br/crypto/optimistic-rollup/index.mdx