O que é um rollup e porque a Bitcoin precisava dele

O problema da escalabilidade da Bitcoin

A Bitcoin foi concebida para privilegiar a verificabilidade, a descentralização e a resiliência, e não para maximizar o número de transações por segundo. Cada nó completo valida as transações em conformidade com as regras do protocolo. Na camada de base, a capacidade é limitada e é frequentemente estimada, a título indicativo, em cerca de 7 transações por segundo, ainda que o valor efetivo dependa do tipo e da dimensão das transações.

Durante anos, o debate resumiu-se a uma questão: como aumentar a capacidade da Bitcoin sem comprometer aquilo que a torna singular?

Os caminhos já explorados

A primeira resposta foi a Lightning Network, operacional desde 2018: uma rede de canais de pagamento que permite efetuar pagamentos rápidos e geralmente de baixo custo, inclusive através de rotas compostas por vários canais. Está orientada sobretudo para pagamentos e não oferece um ambiente generalista de smart contracts. O seu funcionamento depende igualmente da liquidez disponível e da possibilidade de encontrar uma rota adequada.

A Stacks adotou uma abordagem diferente: uma rede de smart contracts ligada à Bitcoin pelo mecanismo PoX e dotada da sua própria linguagem, Clarity. O seu modelo de segurança e a sua finalidade diferem dos da Bitcoin e dependem também das regras próprias da rede Stacks.

A Rootstock (RSK) optou pela compatibilidade com a EVM e pelo merge-mining com a Bitcoin. A rede está operacional desde 2018 e utiliza um modelo de sidechain com pressupostos próprios de segurança e de bridge.

Porque um rollup é diferente

Um rollup não é uma sidechain. A distinção técnica é importante:

• - Uma sidechain mantém o seu próprio mecanismo de consenso ou de validação. A sua segurança depende principalmente desse sistema e do design da bridge que a liga à Bitcoin.
• - Na arquitetura descrita para Bitcoin Hyper, a execução ocorreria fora da Bitcoin e seriam publicados compromissos de estado na camada de base. A qualificação efetiva como rollup dependerá também da disponibilidade dos dados e do sistema de provas.

Segundo a arquitetura publicada pelo projeto, o processo previsto seria o seguinte:

1. Os utilizadores enviariam as suas transações ao sequencer
2. O sequencer ordená-las-ia e executá-las-ia por lotes
3. Periodicamente, um compromisso de estado (state commitment), descrito como uma raiz de Merkle do estado atualizado, seria publicado na Bitcoin através de OP_RETURN ou de Taproot
4. A possibilidade de verificar a transição dependeria da disponibilidade dos dados e do sistema de provas; o compromisso, por si só, não demonstra que a transição está correta

Uma vez confirmado na Bitcoin, um compromisso de estado beneficia da imutabilidade prática da transação que o contém. Isso torna mais difícil a modificação retrospetiva desse registo, mas não impede, por si só, a publicação de um compromisso incorreto e não garante a validade do estado, a disponibilidade dos dados nem a segurança da bridge.

A disponibilidade dos dados: uma questão ainda em aberto

O ponto crítico é o seguinte: onde residem realmente os dados das transações? Se apenas o compromisso for publicado na Bitcoin enquanto os dados completos permanecem nas mãos do sequencer, a arquitetura aproximar-se-ia mais de um modelo do tipo validium do que de um rollup com disponibilidade pública dos dados. Esta distinção não é meramente académica: se o sequencer desaparecesse com os dados, os utilizadores poderiam deixar de conseguir demonstrar o seu próprio saldo.

Segundo a documentação publicada pelo projeto, a solução definitiva relativa à disponibilidade dos dados permanece em estudo; uma atualização datada de 27 de março de 2026 indica-o explicitamente. Entre as opções exploradas figuram camadas externas de disponibilidade dos dados, como a Celestia, o erasure coding e o recurso a nós distribuídos.

Em resumo

Um rollup sobre a Bitcoin pode prosseguir vários objetivos de design: utilizar a Bitcoin para registar compromissos de estado; aumentar a capacidade através de uma execução fora da cadeia; oferecer um ambiente de smart contracts; e reduzir os custos para o utilizador. A medida em que estes objetivos poderão ser alcançados depende da implementação concreta, da disponibilidade dos dados, do sistema de provas e dos mecanismos de saída.

O custo desta abordagem reside numa complexidade arquitetónica acrescida e em várias opções de design ainda em aberto: o sequencer, a disponibilidade dos dados, a bridge e o sistema de provas. O projeto afirma que estes elementos poderão ser tratados progressivamente; trata-se de uma posição do próprio projeto, que permanece por verificar de forma independente.