Rollups: como ampliam a capacidade das redes

Se você leu Layer 1 e layer 2: como as blockchains escalam, já sabe o essencial: um rollup executa transações fora da rede principal, agrupa-as em lotes e publica o resultado nela. Este texto abre a caixa. Mostra quem faz cada etapa, onde os dados ficam, como as provas funcionam e por que o saque pode levar uma semana.

O foco é o Ethereum, onde os rollups são o caminho principal de escalabilidade. As informações foram conferidas em 8 de outubro de 2026.

O caminho de uma transação dentro de um rollup

Pense em uma transferência feita numa rede de camada 2. Ela passa por quatro etapas.

1. Ordenação. A transação chega ao sequenciador, o operador que decide a ordem das transações e monta os lotes. Em muitos rollups há um único sequenciador (ethereum.org, rollups otimistas).
2. Execução. O sequenciador executa as transações e calcula o novo estado da rede: saldos, contratos, tudo. Esse estado é resumido em uma raiz de estado, um código curto que muda se qualquer detalhe mudar.
3. Publicação. O lote, comprimido, vai para o Ethereum. Junto vão a raiz de estado antiga e a nova, registradas em um contrato do rollup na camada 1 (ethereum.org, rollups otimistas).
4. Verificação. Um sistema de provas garante que a nova raiz é correta. Aqui os rollups se dividem em otimistas e de conhecimento zero, como você verá adiante.

Na leitura da redação, o ponto prático é este: a confirmação rápida que a carteira mostra vem do sequenciador. A garantia do Ethereum só existe depois que o lote está na camada 1 e, nos rollups otimistas, depois que o prazo de contestação termina.

O sequenciador: rapidez com um ponto de controle

Um sequenciador único é simples e rápido, mas concentra poder. Segundo a ethereum.org, operadores centralizados podem influenciar a ordem das transações e podem censurar usuários ficando fora do ar ou recusando transações (ethereum.org, rollups otimistas).

O que limita esse poder é a saída forçada. Em vários rollups, você pode enviar sua transação diretamente ao contrato do rollup no Ethereum. Se o sequenciador não a incluir dentro do prazo máximo definido, ela entra mesmo assim. Em alguns desenhos, todo bloco precisa incluir as mensagens enviadas pela camada 1, e o sequenciador não consegue atrasá-las (ethereum.org, rollups otimistas). Nos rollups de conhecimento zero existe mecanismo semelhante para forçar a saída sem permissão do operador (ethereum.org, ZK-rollups).

O detalhe que muda tudo: esse recurso varia de rede para rede. Um rollup sem saída forçada funcional depende da boa vontade de quem opera o sequenciador.

Disponibilidade de dados: por que o rollup publica tudo

Disponibilidade de dados é a confiança de que os dados necessários para verificar um bloco estão de fato acessíveis a quem quiser conferir (ethereum.org, disponibilidade de dados).

Para um rollup, isso é vital. Sem os dados das transações, ninguém consegue checar se a raiz de estado publicada está certa. Num rollup otimista, ninguém consegue montar uma prova de fraude. Num rollup de conhecimento zero, a prova continua garantindo que o estado é válido, mas, se o operador esconder os dados, você não consegue nem saber seu saldo nem movimentá-lo (ethereum.org, disponibilidade de dados).

É por isso que um rollup publica os dados no próprio Ethereum. Redes que guardam os dados fora dele, como os validiums, dependem de um comitê de disponibilidade de dados, um grupo que guarda as informações e atesta que elas existem. A garantia passa a ser a honestidade desse grupo, não a do Ethereum.

De calldata a blobs

Até 2024, os rollups publicavam seus dados como calldata, um campo das transações comuns, caro porque disputa espaço com todas as outras operações da rede.

A EIP-4844 criou os blobs, pacotes de dados anexados aos blocos. Os números da proposta: cada blob tem cerca de 128 KB, e a meta original era de 3 blobs por bloco, com máximo de 6. Os blobs têm um mercado de taxas próprio, independente do gás comum, e os nós só precisam guardá-los por 4.096 épocas, cerca de 18 dias (EIP-4844). A mudança entrou no ar em março de 2024, com a atualização Dencun (ethereum.org, danksharding).

Os 18 dias não são um descuido. Os dados precisam existir apenas pelo tempo necessário para que participantes honestos reconstruam o estado e contestem erros. Depois disso, guardar o histórico passa a ser tarefa de outros participantes do ecossistema (ethereum.org, disponibilidade de dados).

PeerDAS: mais blobs sem exigir mais de cada nó

Aumentar o número de blobs esbarra no mesmo limite de sempre: cada nó teria de baixar mais dados. A EIP-7594, chamada PeerDAS, resolve isso com amostragem de disponibilidade de dados. Os dados dos blobs são ampliados com códigos de correção de erros e divididos em colunas. Cada nó guarda só algumas colunas e confere amostras com os vizinhos; com metade das colunas, é possível reconstruir tudo (EIP-7594).

Segundo a proposta, cada nó baixa hoje uma fração fixa de 1/8 dos dados de blobs, o que permite ampliar a capacidade sem aumentar a exigência de banda e armazenamento (EIP-7594). O PeerDAS chegou com a atualização Fusaka, em dezembro de 2025 (ethereum.org, camada 2). O passo seguinte do roteiro, o danksharding completo, prevê até 64 blobs por bloco e é descrito pela ethereum.org como algo ainda a “vários anos” de distância (ethereum.org, danksharding).

Provas: como o Ethereum sabe que o lote está certo

Prova de fraude, rodada por rodada

Nos rollups otimistas, o lote é aceito de saída e pode ser contestado. As primeiras versões reexecutavam a transação disputada inteira no Ethereum. Os desenhos atuais usam provas interativas em várias rodadas: quem publicou o lote e quem contesta dividem a execução ao meio, repetidas vezes, até isolar um único passo em disputa. Só esse passo é executado na camada 1 (ethereum.org, rollups otimistas).

O incentivo vem das garantias (bonds), valores depositados por quem publica lotes. Se a contestação vencer, parte da garantia vai para quem contestou e o resto é destruído, o que desestimula combinações entre as partes. O contrato também pode apagar raízes de estado inválidas e devolver o rollup ao estado correto (ethereum.org, rollups otimistas).

Prova de validade

Nos rollups de conhecimento zero, cada lote chega com uma prova criptográfica. Um contrato verificador no Ethereum confere a prova, a raiz anterior e a nova antes de aceitar o lote (ethereum.org, ZK-rollups).

Há duas famílias de prova. Os SNARKs geram provas pequenas e baratas de verificar, mas dependem de uma configuração inicial confiável. Os STARKs dispensam essa configuração e são considerados resistentes à computação quântica, mas produzem provas maiores, que custam mais para verificar. Verificar uma prova no Ethereum custa cerca de 500 mil unidades de gás, e gerá-la exige processamento pesado, às vezes hardware especializado, o que pode concentrar a operação (ethereum.org, ZK-rollups).

Prazos de saque: onde a diferença aparece para você

Trazer ativos de volta ao Ethereum mostra, na prática, como cada rollup se protege.

• Rollup otimista. O pedido de saque entra no próximo lote e precisa esperar o fim do prazo de contestação, de cerca de sete dias (ethereum.org, rollups otimistas).
• Saque rápido. Um provedor de liquidez assume seu saque pendente e paga você no Ethereum na hora, cobrando uma taxa. Ele pode conferir o saque rodando a rede por conta própria antes de pagar (ethereum.org, rollups otimistas). Você troca espera por um intermediário.
• ZK-rollup. O saque é executado assim que o contrato verifica a prova de validade, sem prazo de contestação (ethereum.org, ZK-rollups).

Mover ativos entre redes por outros caminhos envolve pontes, com riscos próprios. O assunto tem texto dedicado em Pontes entre blockchains.

Estágios: quanto um rollup ainda depende de pessoas

Muitos rollups começaram com “rodinhas”: administradores capazes de atualizar contratos, pausar o sistema ou corrigir erros. Para medir o quanto cada rede já se livrou disso, o site independente L2BEAT usa uma classificação em três estágios (L2BEAT, estágios). Ela não é norma oficial do Ethereum, mas virou referência de mercado.

• Estágio 0. O sistema de provas precisa existir e funcionar: nos ZK-rollups, aceitar a raiz de estado proposta; nos otimistas, permitir rejeitar raízes inválidas.
• Estágio 1. Bloquear ou forjar mensagens de saque exige comprometer pelo menos 75% do conselho de segurança, o grupo com poderes de emergência. Atualizações feitas por outras partes precisam dar ao menos 7 dias para os usuários saírem.
• Estágio 2. Qualquer pessoa pode enviar provas de fraude, os usuários têm pelo menos 30 dias para sair diante de uma atualização indesejada e o conselho só pode agir em falhas comprováveis na própria blockchain.

A ethereum.org vai na mesma linha ao dizer que a segurança de uma camada 2 depende da tecnologia, da segurança dos contratos e da maturidade da rede, e recomenda começar com valores pequenos (ethereum.org, camada 2).

Perguntas para fazer antes de usar um rollup

• Os dados das transações vão para o Ethereum ou ficam com um comitê externo?
• O sistema de provas está ativo, e quem pode enviar provas?
• Existe saída forçada pela camada 1 se o sequenciador travar ou censurar?
• Quem pode atualizar os contratos, e com quantos dias de aviso?
• Qual é o prazo de saque pela via oficial?

Nenhuma resposta elimina riscos de bugs, de contratos mal escritos ou de perda de valor dos tokens. As transações em geral não têm estorno. Se a rede for usada em aplicações financeiras, vale rever também DeFi: o que são finanças descentralizadas.

O que levar deste texto

• O rollup ganha capacidade porque executa fora do Ethereum e publica ali só dados comprimidos e raízes de estado; a segurança vem de os dados estarem disponíveis e de haver prova.
• Blobs (EIP-4844) e PeerDAS (EIP-7594) baratearam e ampliaram o espaço para esses dados, com retenção de cerca de 18 dias.
• Sequenciador único, ausência de saída forçada, contratos atualizáveis sem aviso e provas restritas a poucos participantes são os sinais de que um rollup ainda depende de confiança em pessoas.