O que é um ZK rollup? Um guia completo sobre zero-knowledge e rollups-as-a-service (RaaS)

Durante boa parte da última década, a resposta honesta para "vale a pena construir em um ZK rollup?" era "ainda não". Gerar uma prova de validade levava minutos e custava dinheiro de verdade, e rodar bytecode EVM comum através de um sistema de provas estava mais para projeto de pesquisa do que para alvo de deploy.

Isso mudou rápido. Em aproximadamente um ano, a latência de prova para blocos da Ethereum caiu de 16 minutos para 16 segundos e os custos de prova despencaram 45 vezes, segundo o roteiro de segurança do zkEVM da Ethereum Foundation. ZK rollups substituem confiança por prova. O que resta decidir não é se a tecnologia funciona, mas se rodar sua própria chain compensa a superfície operacional que ela traz.

O que é um ZK rollup?

Um zero-knowledge rollup é um design de escalabilidade que executa transações fora da chain principal e depois publica uma prova de validade criptográfica na camada base mostrando que o estado resultante está correto. A camada base nunca reexecuta essas transações. Ela verifica a prova.

Pense nisso como entregar uma prova de matemática em que o corretor confere um certificado curto em vez de refazer cada questão. O certificado é pequeno, verificá-lo é rápido, e uma resposta errada não consegue produzir um certificado válido. Essa assimetria é todo o mecanismo. Verificar uma prova custa muito menos do que executar as transações por trás dela, então um rollup consegue processar muito mais throughput usando a mesma capacidade da camada base.

"Zero-knowledge" é um nome enganoso. Ele descreve o sistema de provas, não as propriedades de privacidade da chain. Transações em um ZK rollup são públicas por padrão, da mesma forma que na Ethereum. As provas estabelecem que a transição de estado é válida sem que o verificador precise reexecutá-la, o que é uma propriedade de sucinção, não de confidencialidade. Privacidade de verdade exige trabalho extra deliberado, geralmente criptografia ou uma camada de privacidade dedicada construída por cima.

Então trate um ZK rollup como uma decisão de escalabilidade e finalidade. Se você precisa de confidencialidade, isso é um problema de design separado que você ainda precisa resolver.

Como funcionam os ZK rollups?

Quatro componentes fazem o trabalho, e eles se passam a bola em sequência.

• O sequencer recebe transações dos usuários, as ordena e as agrupa em um batch. É isso que dá aos usuários a confirmação rápida, bem antes de qualquer coisa chegar à camada base.
• O prover pega o batch e gera uma prova de validade, geralmente um SNARK ou um STARK, atestando que executar essas transações contra o estado anterior produz o novo estado.
• O contrato verificador vive na camada base. Ele verifica a prova e, se ela for válida, aceita a nova raiz de estado como canônica.
• A camada de disponibilidade de dados armazena dados de transação suficientes para que qualquer pessoa possa reconstruir de forma independente o estado do rollup e verificar que o operador não está escondendo nada.

O próprio estado é rastreado em uma Merkle tree, onde um único hash raiz compromete todo saldo de conta e slot de contrato. Cada batch aceito avança essa raiz, então a camada base guarda um pequeno compromisso em vez do estado completo do rollup.

Esse último componente, disponibilidade de dados, é onde a economia mudou mais. Rollups costumavam pagar por calldata na camada base para publicar dados de batch, o que era caro e ficava onchain permanentemente. O upgrade Dencun da Ethereum introduziu blobs em março de 2024, uma faixa de dados separada, precificada de forma independente e dimensionada exatamente para esse trabalho. Dados de blob são descartados após aproximadamente 18 dias em vez de mantidos para sempre, o que é deliberado. Dados de rollup não precisam persistir indefinidamente; eles só precisam estar disponíveis por tempo suficiente para que qualquer pessoa possa baixá-los e reconstruir o estado da chain. O PeerDAS, o upgrade de amostragem de disponibilidade de dados lançado com o Fusaka em dezembro de 2025, tornou seguro rodar contagens maiores de blobs. Os próprios aumentos de capacidade vieram de pequenos forks subsequentes que alteraram apenas parâmetros de blob.

A disponibilidade de dados não é mais o item de custo dominante que já foi. Para um time calculando o custo de um rollup hoje, geração de prova e operações de sequencer são os custos que importam, e qualquer modelo de custo baseado nas antigas premissas de calldata estará errado por uma ordem de magnitude.

Por que os ZK rollups importam para builders?

As taxas caem porque o custo de publicar e verificar um batch é amortizado entre todas as transações dentro dele. O throughput sobe pelo mesmo motivo, já que a capacidade da camada base limita a verificação de provas, não a execução de transações.

Saques são liquidados sem janela de contestação. Um optimistic rollup assume que os batches são válidos a menos que alguém os conteste, então ele retém os saques por um período de disputa, convencionalmente sete dias. Uma prova de validade já estabelece a correção no momento em que é verificada, então não há nada a esperar. Para qualquer coisa envolvendo mover valor entre camadas, essa diferença é a que os usuários realmente sentem.

A verificabilidade vem do requisito de disponibilidade de dados. Como os dados do batch são publicados, qualquer pessoa pode reconstruir o estado do rollup de forma independente, então um operador não pode nem confirmar um estado falso nem reter os dados necessários para verificá-lo. O que isso não dá é resistência à censura. Um sequencer ainda pode simplesmente recusar incluir sua transação, e nenhuma quantidade de dados publicados revela uma transação que nunca foi sequenciada. Essa proteção vem de um caminho de inclusão forçada, onde um usuário submete uma transação diretamente ao contrato da camada base e o rollup é obrigado a incluí-la. Ao avaliar uma chain, confirme que essa via de escape existe e que funciona sem a cooperação do operador.

Juntos, esses fatores fazem dos ZK rollups uma escolha padrão razoável para aplicações em que velocidade de liquidação e custo por transação são características do produto, não detalhes de implementação. Pagamentos, exchanges e jogos sentem a diferença imediatamente. Uma aplicação de baixa frequência provavelmente não sente.

Como os ZK rollups suportam integração com smart contracts?

Provar execução arbitrária de smart contracts é muito mais difícil do que provar transferências simples, e é por isso que os primeiros ZK rollups suportavam apenas pagamentos e swaps. Provar bytecode EVM significa expressar cada opcode como restrições dentro de um sistema de provas, e a EVM não foi projetada com isso em mente.

Um zkEVM é a resposta, e as implementações diferem em quão próximas ficam da Ethereum. Algumas provam diretamente a camada de execução da Ethereum, o que maximiza a compatibilidade ao custo do desempenho de prova. Outras ajustam o bytecode ou a árvore de estado para tornar a prova mais barata, o que significa que alguns contratos e ferramentas precisam de ajustes antes de funcionar. Verifique qualquer zkEVM contra suas dependências reais, não contra o rótulo de compatibilidade.

A diferença de desempenho que tornava isso um problema de pesquisa foi, em grande parte, fechada. Os provers agora lidam com 99% dos blocos da Ethereum em menos de 10 segundos em hardware alvo, segundo a Ethereum Foundation, o que é uma medida de prova por bloco, não a cifra de latência ponta a ponta citada acima. O foco atual mudou de velocidade para segurança. O roteiro publicado define segurança prova­vel de 128 bits e tamanhos de prova abaixo de 300 KiB como meta para o fim de 2026, junto com verificação formal da arquitetura de recursão.

A velocidade de prova não é mais o que separa você de um zkEVM em produção. Pergunte a um time, em vez disso, o quão avançadas estão as provas de segurança deles.

Como os ZK rollups se comparam aos optimistic rollups?

Ambos publicam dados de transação em uma camada base e ambos herdam sua segurança. Eles diferem no que pedem para a camada base acreditar.

Optimistic rollups são mais baratos de operar e tiveram uma vantagem inicial na compatibilidade com a EVM, por isso as maiores L2s de propósito geral em atividade ainda são optimistic. ZK rollups pagam pela prova e ganham liquidação mais rápida e um modelo de confiança criptográfico em vez de econômico em troca.

Nenhum dos dois lados vence de forma clara em cargas de trabalho de propósito geral hoje. Escolha ZK quando liquidação rápida e trust-minimized vale pagar o custo de prova, e escolha optimistic quando custo operacional bruto e compatibilidade máxima com a EVM importam mais.

O que é rollups-as-a-service (RaaS)?

Lançar um rollup costumava significar montar um sequencer, um prover, um contrato de bridge e um caminho de disponibilidade de dados você mesmo, e depois manter esses quatro rodando indefinidamente. Isso é um time de chain, não uma feature.

Rollups-as-a-service transforma essa stack em algo que um provedor opera para você. Você escolhe um framework, define seus parâmetros, e o provedor opera o sequencer, o prover, a bridge e a infraestrutura de nós por trás. O que você mantém é a chain em si, incluindo seu token de taxa, política de gas, regras de ordenação de transação e qualquer lógica de compliance que uma chain compartilhada nunca aplicaria em seu nome.

A parte do discurso inicial de RaaS que envelheceu mal é a sugestão de que isso é uma operação de cinco minutos, do tipo "configure e esqueça". É dramaticamente mais rápido do que construir do zero, e remove o peso do plantão. Não remove as decisões de arquitetura. Você ainda escolhe em qual camada base liquidar, qual é seu trade-off de disponibilidade de dados, como a descentralização do sequencer evolui e como upgrades na stack subjacente chegam à sua chain sem quebrá-la.

Trate RaaS como terceirização das operações, não do design. Para um olhar mais aprofundado sobre o modelo em si, cobrimos isso em rollups-as-a-service e RaaS and appchains.

Quando faz sentido lançar seu próprio ZK rollup?

Um rollup dedicado justifica sua complexidade em algumas situações específicas.

• Volume de transações alto e previsível. Assim que você estiver pagando consistentemente por muito blockspace, capacidade dedicada começa a ter um preço melhor do que competir por capacidade compartilhada.
• Um requisito de compliance que uma chain compartilhada não consegue atender. Participantes em allowlist, política em nível de transação, ou restrições jurisdicionais são aplicáveis em uma chain que você controla e em nenhum outro lugar.
• Uma experiência de produto que depende de blockspace dedicado. Se seus tempos de confirmação não podem degradar porque um mint não relacionado está congestionando a rede, compartilhar blockspace é um passivo.

É a decisão errada quando o volume é especulativo. Um provedor gerenciado absorve a carga operacional, mas você ainda herda a segurança da bridge, a liveness do sequencer e uma cadência de upgrades que precisa acompanhar. Essa superfície vale a pena assumir contra demanda real, não demanda projetada. O business model of rollups vale a leitura antes de você se comprometer, já que uma chain precisa justificar seu custo operacional.

A maioria dos times é melhor atendida lançando primeiro em uma chain estabelecida através de RPC access padrão, e revisitando a decisão depois que os padrões de uso justificarem o caso. Adiar a decisão custa muito pouco. Desfazer uma chain que você não deveria ter lançado custa muito.

Perguntas frequentes sobre zero-knowledge rollups

O que é um ZK rollup?

Um ZK rollup é uma solução de escalabilidade de Layer 2 que executa transações offchain em batches e publica uma prova de validade criptográfica na camada base provando que o estado resultante está correto. A camada base verifica a prova em vez de reexecutar as transações, o que reduz o custo e aumenta o throughput enquanto herda a segurança da camada base.

Como funcionam os ZK rollups?

Um sequencer agrupa transações em batches, um prover gera uma prova de validade como um SNARK ou STARK, e um contrato verificador na camada base checa essa prova antes de aceitar a nova raiz de estado. Os dados de transação são publicados para que qualquer pessoa possa reconstruir o estado do rollup de forma independente. Rollups da Ethereum agora publicam esses dados em blobs em vez de calldata.

ZK rollups são privados?

Não, não por padrão. "Zero-knowledge" descreve o sistema de provas, que permite a um verificador confirmar que uma transição de estado é válida sem reexecutá-la. Transações em um ZK rollup são visíveis publicamente, assim como na Ethereum. Confidencialidade exige uma camada de privacidade adicional construída deliberadamente por cima.

Em que os ZK rollups diferem dos optimistic rollups?

ZK rollups provam que cada batch é válido, então os saques são liquidados assim que a prova é verificada. Optimistic rollups assumem que os batches são válidos a menos que sejam contestados, e é por isso que os saques esperam uma janela de disputa, convencionalmente sete dias. ZK rollups dependem de garantias criptográficas; optimistic rollups dependem de incentivos econômicos e de pelo menos um contestador honesto.

Quais são alguns projetos de ZK rollup em destaque?

ZKsync Era, Starknet, Scroll e Linea são os ZK rollups de propósito geral que a maioria dos times avalia, com Scroll e Linea buscando equivalência próxima com a EVM. O Starknet atualmente tem a classificação Stage 1 do L2Beat, embora se espere um rebaixamento para Stage 0 conforme regras mais rígidas entrem em vigor; Scroll, ZKsync Era e Linea estão todos em Stage 0. O sequencer da Mainnet Beta do Polygon zkEVM foi desativado em 1º de julho de 2026, com a Polygon redirecionando esforços para Polygon PoS e Agglayer.

Smart contracts podem rodar em ZK rollups?

Sim, através de implementações de zkEVM que provam a execução da EVM. A compatibilidade varia. Alguns zkEVMs provam diretamente a camada de execução da Ethereum para máxima compatibilidade, enquanto outros modificam o bytecode ou a estrutura de estado para tornar a prova mais barata, o que pode exigir ajustes em contratos ou ferramentas. Verifique a compatibilidade contra suas dependências reais, não contra uma afirmação genérica.

O que significa rollups-as-a-service (RaaS)?

Rollups-as-a-service significa que um provedor opera o sequencer, o prover, a bridge e a infraestrutura de nós de um rollup que você configura e possui. Isso remove o peso operacional de rodar uma chain. Não remove as decisões de arquitetura, incluindo a escolha da camada base, os trade-offs de disponibilidade de dados, a descentralização do sequencer e como upgrades da stack chegam à sua chain.

O que torna os ZK rollups seguros?

ZK rollups herdam segurança da camada base. Os fundos ficam em contratos na camada base, e uma nova raiz de estado só é aceita quando uma prova válida é verificada onchain, então um operador não consegue confirmar um estado inválido. Publicar os dados do batch separadamente garante que qualquer pessoa possa reconstruir esse estado de forma independente e detectar um operador retendo os dados. Resistir à censura de transações individuais é uma garantia separada, que depende de um caminho de inclusão forçada até a camada base.