Ordenar as transações é uma forma de poder

Qualquer rollup precisa de alguém — ou de algo — que decida a ordem pela qual as transações são processadas. É essa a função do sequencer.

A ordenação não é neutra. Quem controla o sequencer pode: extrair MEV (Maximal Extractable Value) inserindo ou reordenando transações em proveito próprio; censurar transações, ignorando aquelas que não pretende processar; e praticar front-running, antecipando-se às transações de outros utilizadores.

Num sistema descentralizado, nenhum interveniente concentra sozinho este poder. Num sistema dotado de um sequencer centralizado, esse poder cabe à equipa que o opera. Os riscos associados a esta concentração incluem a censura de transações, os atrasos, a indisponibilidade do serviço, o controlo da ordenação, a extração de MEV e a existência de um ponto único de falha.

Porque é que muitos rollups começam com um sequencer centralizado

A resposta mais direta é que esta arquitetura é mais simples no plano operacional. Durante uma fase inicial, um operador único poderia simplificar a coordenação, as atualizações e o diagnóstico de incidentes. Concentraria, no entanto, também o poder e as dependências nas mãos de um só interveniente.

Um sequencer descentralizado exige um protocolo de consenso entre vários sequencers, mecanismos contra o conluio, sistemas de eleição ou de rotação do líder, bem como incentivos económicos robustos e difíceis de atacar.

Construir todos estes mecanismos antes do lançamento pode exigir um período de desenvolvimento adicional considerável. O Arbitrum, o Optimism e a Base — três rollups importantes da Ethereum — foram lançados com um sequencer centralizado e prosseguem ainda, vários anos depois, o seu processo de descentralização. Esta comparação é meramente contextual: não implica qualquer equivalência arquitetural ou de segurança com a arquitetura descrita para o Bitcoin Hyper.

Segundo a documentação do projeto analisada no capítulo 34.2 do livro, no lançamento da mainnet o sequencer seria centralizado e operado pela equipa. À data de referência, o Bitcoin Hyper encontrava-se ainda numa fase anterior à mainnet: o sequencer único faz parte do modelo de lançamento previsto e não de um componente operacional já verificado. O roadmap prevê uma descentralização progressiva ao longo de um período de dois a quatro anos, através de mecanismos de rotação, de leilões e de eleição do líder. Trata-se de uma intenção declarada e não de uma funcionalidade concluída.

Como seria atenuado o risco de censura?

O principal mecanismo arquitetural previsto é a inclusão forçada (forced inclusion): uma transação poderia ser «forçada» no rollup através da camada de base da Bitcoin, sem passar pelo sequencer. Se o sequencer censurasse uma transação, o utilizador poderia fazê-la processar pagando diretamente as taxas na Bitcoin. Um sequencer único introduz um ponto central de controlo operacional; a inclusão forçada constitui o mecanismo de segurança previsto para que esse controlo não se torne absoluto. Deve ser considerada uma funcionalidade documentada que resta verificar, e não uma garantia já disponível.

A reserva essencial é que a inclusão forçada permanece em desenvolvimento no Bitcoin Hyper (situação a 28 de abril de 2026). Não estava disponível na devnet. Enquanto não for publicada e submetida a testes, a proteção que é suposto oferecer permanecerá por verificar. Esta informação reporta-se à documentação disponível nessa data.

Sinais a vigiar

Antes de ponderar qualquer exposição ao Bitcoin Hyper, eis os sinais que indicariam uma progressão real da descentralização do sequencer. À data de referência, não foi identificada qualquer especificação pública suficientemente detalhada do mecanismo definitivo:

Especificações técnicas públicas do mecanismo de descentralização adotado
Uma inclusão forçada operacional em testnet ou em mainnet
Um roadmap com marcos verificáveis (e não simplesmente «nos próximos anos»)
Uma auditoria ao código do sequencer realizada por sociedades independentes reconhecidas
Um calendário credível com dependências explícitas

Conclusão

Um sequencer centralizado no lançamento pode constituir uma opção pragmática e compreensível, sem ser necessariamente um sinal de alarme. Não implica, por si só, uma perda de fundos, mas poderia afetar a disponibilidade do serviço, a ordenação das transações e a resistência à censura. Torna-se problemático na ausência de um roadmap concreto rumo à descentralização, se a inclusão forçada nunca for implementada ou se o operador do sequencer utilizar a sua posição para extrair MEV de forma opaca.

O projeto afirma que a sequenciação será descentralizada numa fase posterior. À data de redação, essa transição continua a ser um objetivo do roadmap, e uma promessa genérica de descentralização não constitui um roadmap verificável. O sequencer, a bridge, a disponibilidade dos dados e o sistema de provas representam níveis distintos: descentralizar o sequencer não eliminaria automaticamente os riscos ligados à bridge nem os associados à disponibilidade dos dados. A inclusão forçada, a saída forçada e o escape hatch devem ser considerados funcionalidades documentadas ou que restam verificar. Um sequencer único pode constituir um ponto de partida pragmático, mas não deve ser apresentado como um ponto de chegada: a avaliação dependerá dos limites publicados, dos controlos existentes e dos procedimentos alternativos. A credibilidade da descentralização dependerá de marcos verificáveis e não de meras declarações de intenção.

Um sequencer único no lançamento: risco ou pragmatismo?