---
title: "ZK rollups"
description: "Guia de verificação de lotes, provas de validade, disponibilidade de dados, estados de liquidação, taxas, saques e riscos específicos de cada implantação ZK rollup."
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.
# ZK rollups
> Somente para fins educacionais; não constitui orientação de investimento, bridge ou segurança. Um ZK rollup é tão confiável quanto seu programa provado, entradas públicas, caminho de disponibilidade de dados, contratos, operadores, governança e cadeia de liquidação.
## Resposta direta
Um ZK rollup, mais precisamente um rollup de validade, executa transações fora de uma cadeia de liquidação, agrupa-as em lotes e envia compromissos de dados, alegações de estado e provas de validade aos contratos dessa cadeia. O verificador confere as regras de transição codificadas sem reexecutar cada transação. Assim, os custos de publicação e verificação são distribuídos entre muitas transações.
A garantia é específica, não absoluta. Uma prova verificada sustenta apenas a alegação codificada pelo programa implantado e vinculada às entradas públicas. Sozinha, não prova que os dados são recuperáveis, o sequenciador está ativo ou é justo, o bloco está finalizado, a bridge é correta ou um upgrade é seguro. “ZK” também não significa privacidade: muitos rollups publicam transações ou diferenças de estado.
## Como funciona
1. Fixe a implantação: IDs das cadeias L1 e L2, contratos do rollup e da bridge, verificador e versão da chave, programa ou circuitos provados, formato do lote, modo DA, sequenciador, provador, administradores, poderes de pausa e bloco observado. O nome da stack não garante todas as implantações.
2. Separe ordenação e prova. O sequenciador pode emitir recibo rápido e blocos L2 antes que compromisso ou prova chegue à L1. Registre o lote exato e diferencie ordenado, comprometido, provado, aceito, seguro na liquidação, finalizado e saque concluído.
3. Reconstrua o lote. Obtenha transações, diferenças de estado, blob sidecars ou outra carga exigida; confira ordem e compromissos; derive raízes anterior e posterior, raiz de saques ou mensagens e demais entradas públicas. Prova vinculada à cadeia, lote ou raiz errada prova outra alegação.
4. Verifique o caminho da prova. Confirme que a transação chamou o verificador previsto com prova, chave e entradas esperadas, teve sucesso, emitiu o evento correto e atualizou o slot certo. Quando possível, reproduza verificação e execução com software independente.
5. Audite a disponibilidade separadamente. Blobs do Ethereum oferecem disponibilidade na janela do protocolo e compromissos, não recuperação permanente. Comitê externo ou camada DA alternativa adiciona hipóteses próprias. Prova válida não restaura dados ausentes necessários para reconstruir o estado ou sair.
6. Rastreie depósitos e saques ponta a ponta. Concilie token e mensageiro canônicos, valor, destino, nonce, raiz de inclusão, prova, regra de finalidade e saldo executado. Uma bridge rápida antecipa liquidez com preço, rota e risco de contraparte próprios; não encurta o relógio canônico.
7. Monitore atividade e controle. Meça filas de lotes e provas, inclusão forçada e rotas de saída, diversidade de provadores, upgrades, timelocks, guardiões e modos de emergência. Repita após mudanças de contrato, circuito, chave, modo DA ou protocolo.
## Exemplos calculados
- **Compressão.** Um lote didático contém `10,000 transactions`; `1,200 KB` de entrada bruta viram `300 KB`. 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/transaction`. Isso não mede solidez, crescimento de estado nem arquivamento.
- **Alocação de custos.** Usuários pagam `3.0 ETH`; dados L1 custam `1.4 ETH`, verificação `0.4 ETH` e execução L2 `0.2 ETH`. O resíduo é `3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH` e a média `3.0 / 10,000 = 0.0003 ETH/transaction`. Não é lucro líquido: exclui provas, hardware, falhas, bridges, capital e tributos.
- **Ciclo de vida.** Recibo em `minute 0`, compromisso L1 em `minute 12`, prova aceita em `minute 50`, política de finalidade atendida em `minute 64` e saque canônico em `minute 70`. Tempo sequencial: `12 + 38 + 14 + 6 = 70 minutes`. Nenhum instante anterior equivale ao saque concluído.
## Riscos
- Cadeia, implantação, contrato, lote, raiz, verificador, chave ou circuito errados.
- Programa provado incompleto ou incorreto, fielmente provado por sistema sólido.
- Entradas públicas, separadores de domínio, mensagens ou parâmetros ausentes ou mal codificados.
- Falhas no verificador, pré-compilado, bridge, mensageiro ou contrato de estado.
- Material de configuração comprometido ou hipóteses criptográficas quebradas.
- Censura, reordenação, equívoco, queda ou publicação tardia do sequenciador.
- Queda, centralização, censura, falta de capacidade ou fila crescente do provador.
- Transações, diferenças de estado ou blob sidecars indisponíveis, malformados ou sem arquivo.
- Confundir compromisso ou assinatura de comitê com recuperação atual.
- Reorganização L1 ou confiança prematura em liquidação insegura.
- Upgrades privilegiados, timelocks curtos, troca, pausas ou desvio de emergência.
- Inclusão forçada, recuperação ou saída ausentes, desativadas ou inutilizáveis.
- Bugs da bridge canônica, token errado, replay, mensagem ou prova de saque falha.
- Riscos de liquidez, preço, rota, insolvência e contraparte de bridges rápidas.
- Estimativas sem dados L1, provas, bridge, congestionamento ou falhas.
- Aplicar a um rollup compatibilidade EVM, finalidade, privacidade ou segurança de outro.
## Erros comuns
- Todo ZK rollup oculta valores, endereços e atividade dos aplicativos.
- Prova válida garante dados disponíveis e reconstrução do estado.
- Recibo do sequenciador equivale a prova aceita na L1 ou saque finalizado.
- Provas eliminam riscos de sequenciador, provador, governança, upgrade e bridge.
- O sistema mais barato ou rápido produz automaticamente o resultado mais seguro.
## Tópicos relacionados
- [Prova de validade](/pt-br/crypto/validity-proof/)
- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Camada 2](/pt-br/crypto/layer2/)
- [Rollup](/pt-br/crypto/rollup/)
- [Prova de conhecimento zero](/pt-br/crypto/zero-knowledge-proof/)
## Fontes
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (acessado: 2026-08-22)
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org (acessado: 2026-08-22)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (acessado: 2026-08-22)
- [Rollup Process](https://docs.scroll.io/en/technology/chain/rollup/) - Scroll Documentation (acessado: 2026-08-22)
- [Data availability](https://docs.starknet.io/learn/protocol/data-availability) - Starknet Documentation (acessado: 2026-08-22)
Source: https://wiki.fcontext.com/pt-br/crypto/zk-rollup/index.mdx