Resumo Técnico: BigDipper

Definição do Problema

Protocolos de Tolerância a Falhas Bizantinas (BFT) baseados em líder são dominantes em sistemas blockchain de produção devido à sua baixa latência e estruturas de comunicação simples. No entanto, eles concedem ao líder o controle de curto prazo sobre a inclusão de transações. Um líder malicioso pode manter o protocolo vivo (garantindo a liveness) enquanto atrasa ou exclui seletivamente transações sensíveis ao tempo, como lances de leilão, atualizações de oráculos, liquidações e mensagens de ponte (bridge). Este fenômeno, denominado censura de curto prazo, não é capturado pelas garantias padrão de liveness de BFT.

Soluções existentes frequentemente codificam mecanismos de anti-censura, ocultação ou ordenação diretamente no caminho do consenso. Embora eficazes para casos de uso específicos, essas abordagens forçam todas as transações a pagar o mesmo alto custo pela proteção, independentemente de uma transação específica exigir tal robustez. Este artigo defende um design mais modular que adere ao princípio de ponta a ponta (end-to-end principle): a camada de consenso deve expor primitivas mínimas para ordenação segura e disponibilidade de dados, deixando a escolha das estratégias de resistência à censura e seus custos para as aplicações de camadas superiores.

Metodologia

O BigDipper introduz uma camada de Disponibilidade de Dados com Resistência à Censura (DA-CR) posicionada entre a submissão de transações e o consenso BFT baseado em líder. O sistema é projetado em torno de três componentes principais:

1. Abstração DA-CR: Uma camada onde as réplicas contribuem com mini-blocos, e um mecanismo certifica quais dados estão disponíveis e devem ser capturados pelo líder. Esta camada é caracterizada por parâmetros $(t, \eta)$, onde $t$ representa a inclusão garantida de mini-blocos honestos e $\eta$ representa a capacidade residual do líder de capturar espaço (excluir dados).
2. Caminho Crítico de Consenso Fragmentado (Sharded): Ao contrário dos designs tradicionais onde os validadores devem baixar e executar o payload total do bloco, o BigDipper mantém os dados fragmentados no caminho crítico. Os validadores votam com base em compromissos compactos, evidências de disponibilidade e regras de inclusão DA-CR, em vez de reconstruir o payload total.
3. Submissão Ajustável pelo Cliente (Navigator): Um protocolo de disseminação de transações onde os clientes escolhem um parâmetro de "fanout" $x$, enviando transações para $x$ réplicas distintas. Isso permite que os clientes troquem o custo de comunicação pela probabilidade de inclusão imediata.

Construções Principais

O artigo apresenta construções concretas de DA-CR baseadas em codificação de apagamento Reed-Solomon (RS) e compromissos polinomiais lineares (KZG):

• Card-7: Um protocolo de prestação de contas (accountable) onde o líder deve fornecer atestações para os mini-blocos incluídos. Ele garante que $t = n - 2f$ mini-blocos honestos sejam incluídos e $\eta = 0$ (sem captura de espaço). Requer $n \ge 3f + 1$.
• Card-1/4: Uma variante não-accountable com menor overhead. Ela remove a exigência de atestações públicas, permitindo que o líder esconda quais réplicas foram incluídas. Alcança $t = n - 3f$ e $\eta = n - f - 1$, exigindo uma suposição mais forte de $n \ge 4f + 1$.
• Card-Lite: Uma otimização do Card-7 usando um esquema de compromisso duplamente homomórfico. Reduz o overhead por réplica para $O(\log n)$ através da amostragem de compromissos em vez da transmissão da lista completa, mantendo $t \approx n - 2f$.

Integração com HotStuff-2

O BigDipper é instanciado dentro do HotStuff-2. A integração é cirúrgica, introduzindo uma regra de Scooping como um predicado de validade. Uma proposta do líder é válida apenas se incorporar um output de DA-CR completo (um certificado provando a disponibilidade de dados e a inclusão dos mini-blocos exigidos). Isso não altera o núcleo de segurança do HotStuff-2, mas impede que os líderes progridam sem capturar os dados exigidos pelas réplicas.

Principais Contribuições

1. Abstração Modular para Resistência à Censura de Curto Prazo: A introdução da DA-CR, que desacopla o mecanismo de disponibilidade de dados da política específica de resistência à censura. Ela formaliza os trade-offs entre inclusão garantida ($t$) e influência do líder ($\eta$).
2. Caminho de Dados Fragmentado e Escalável: Um design onde os validadores comuns não precisam baixar o payload total do bloco para votar. Eles verificam compromissos e metadados, permitindo que a largura de banda da proposta agregada escale com a contribuição de dados do lado da réplica, em vez de ser limitada pela largura de banda de entrada de um único líder.
3. Resistência à Censura Ajustável pelo Cliente: O protocolo Navigator permite que os clientes ampliem a probabilidade de inclusão aumentando seu fanout. O artigo analisa o trade-off custo/segurança, provando via argumento de limite superior de união (union-bound) que a censura ampla torna-se exponencialmente improvável conforme o número de transações submetidas e de réplicas aumenta.
4. Integração e Análise Concreta: Uma instanciação completa do BigDipper dentro do HotStuff-2, demonstrando que a DA-CR pode ser precisamente conectada a protocolos BFT baseados em líder existentes sem comprometer a segurança ou a liveness.

Resultados e Análise

• Resistência à Censura: A análise mostra que, embora um líder malicioso possa censurar transações enviadas a um pequeno número de réplicas, censurar uma grande fração das transações torna-se exponencialmente difícil conforme o sistema escala. Especificamente, se $T$ clientes enviam $x$ cópias, a probabilidade de um adversário censurar uma fração $\alpha$ das transações diminui exponencialmente com $T$.
• Escalabilidade: Ao separar o consenso da execução de dados totais, o BigDipper permite que a camada de consenso escale linearmente com a largura de banda agregada das réplicas. A capacidade do sistema não é limitada pela necessidade de cada validador processar o payload completo.
• Performance: O protocolo Card-7 se ajusta ao cronograma de mensagens existente do HotStuff-2 (Propose, Vote, Prepare, Vote2) sem adicionar novas fases, aproveitando as mensagens DA-CR (Collection, Dispersal, Approval, Agreement) nas mensagens BFT padrão.

Significância

O artigo afirma que o BigDipper fornece um framework modular para resistência à censura de curto prazo que evita o imposto de "tamanho único" dos protocolos existentes. Ao seguir o argumento de ponta a ponta, ele permite que as aplicações escolham suas próprias estratégias de submissão (por exemplo, quantas réplicas contatar, se usam codificação de apagamento) com base em suas necessidades econômicas específicas de latência e garantias de inclusão.

A significância reside em transferir o ônus da resistência à censura de um custo fixo do protocolo para um parâmetro ajustável do lado do cliente, garantindo ao mesmo tempo que a camada de consenso permaneça eficiente e fragmentada. Demonstra que o BFT baseado em líder pode tornar-se resistente à censura sem sacrificar os benefícios de baixa latência do modelo baseado em líder, desde que a disponibilidade de dados seja certificada através de um mecanismo de compromisso e fragmentação, em vez de replicação total.