O que é um rollup e por que o Bitcoin precisava dele?

O problema da escalabilidade no Bitcoin

O Bitcoin foi projetado desde o início para a verificabilidade, a descentralização e a resistência, e não para maximizar o número de transações por segundo. Cada nó completo valida as transações segundo as regras do protocolo. A capacidade da camada base é limitada e costuma ser estimada em cerca de 7 transações por segundo, sendo o número real dependente do tipo e do tamanho das transações.

Durante anos, a disputa se reduziu, no essencial, a uma única pergunta: como aumentar a capacidade do Bitcoin sem tocar justamente naquilo que o torna valioso?

As abordagens até agora

A primeira resposta foi a Lightning Network, em funcionamento desde 2018 — uma rede de canais de pagamento que permite pagamentos rápidos e, em geral, baratos, inclusive em rotas que atravessam vários canais. Foi pensada em primeiro lugar para pagamentos e não oferece um ambiente generalista para contratos inteligentes. O seu funcionamento depende da liquidez disponível e da possibilidade de encontrar uma rota adequada.

A Stacks seguiu outro caminho: uma rede de contratos inteligentes ligada ao Bitcoin pelo mecanismo PoX, com linguagem própria — Clarity. O seu modelo de segurança e a sua finalidade diferem dos do Bitcoin e dependem, além disso, das regras específicas da rede Stacks.

A Rootstock (RSK) apostou na compatibilidade com a EVM e no merge-mining com o Bitcoin. A rede funciona desde 2018 e se baseia em um modelo de sidechain, com premissas próprias quanto à segurança e ao bridge.

Por que um rollup é outra coisa

Um rollup não é um sidechain. A distinção técnica importa:

• - Um sidechain mantém o seu próprio mecanismo de consenso ou de validação. A sua segurança depende em primeiro lugar desse sistema e da construção do bridge que o liga ao Bitcoin.
• - Na arquitetura descrita para o Bitcoin Hyper, a execução das transações aconteceria fora do Bitcoin, e os state commitments seriam publicados na camada base. Se a solução merece ou não o nome de rollup depende, porém, também da disponibilidade dos dados e do sistema de provas.

Segundo a arquitetura publicada pelo projeto, o fluxo previsto teria esta forma:

1. Os usuários enviariam as suas transações ao sequencer
2. O sequencer as ordenaria e as executaria em lotes
3. Em intervalos regulares, um state commitment — a raiz Merkle do estado atualizado — seria publicado no Bitcoin via OP_RETURN ou Taproot
4. A possibilidade de verificar a transição dependeria da disponibilidade dos dados e do sistema de provas; o commitment em si não demonstra a correção da transição

Uma vez confirmado no Bitcoin, o state commitment se beneficia da imutabilidade prática da transação em que está incluído. O registro passa a ser difícil de alterar posteriormente, mas isso não impede a publicação de um commitment errôneo e não garante a correção do estado, a disponibilidade dos dados ou a segurança do bridge.

A disponibilidade dos dados: uma pergunta ainda em aberto

A pergunta essencial é onde estão, de fato, os dados das transações. Se no Bitcoin for publicado apenas o commitment e os dados completos permanecerem com o sequencer, a arquitetura estaria mais próxima de um modelo do tipo Validium do que de um rollup com disponibilidade pública dos dados. A distinção não é puramente acadêmica: se o sequencer desaparecesse junto com os dados, os usuários poderiam ficar sem a possibilidade de verificar o próprio saldo.

Conforme a documentação publicada pelo projeto, a solução final para a disponibilidade dos dados ainda está em análise — a atualização de 27 de março de 2026 confirma isso explicitamente. Entre as opções consideradas estão camadas externas de disponibilidade de dados (por exemplo, a Celestia), erasure coding e o recurso a nós distribuídos.

Conclusões

Um rollup sobre o Bitcoin pode perseguir vários objetivos de projeto: usar o Bitcoin para ancorar os state commitments, aumentar a capacidade por meio da execução off-chain, disponibilizar um ambiente para contratos inteligentes e reduzir os custos para os usuários. A medida em que esses objetivos são alcançados depende da implementação concreta, da disponibilidade dos dados, do sistema de provas e dos mecanismos de saída.

O preço dessa abordagem é uma arquitetura mais complexa e algumas decisões de projeto que continuam em aberto: o sequencer, a disponibilidade dos dados, o bridge e o sistema de provas. O projeto sustenta que esses elementos podem ser tratados gradualmente — é, porém, a posição do próprio projeto, que ainda precisa ser verificada de forma independente.