Resistência à Censura Versus Throughput em BFT Multi-Proposer

1. Enquadramento Institucional

BFT multi-proposer costuma ser apresentado como mecanismo para reduzir o poder de censura de um líder único. Essa leitura é correta, mas incompleta. A questão operacional não é apenas se mais proponentes aumentam a probabilidade de inclusão. A questão crítica é quanto tráfego duplicado, desperdício de espaço de bloco, pressão sobre relays e carga de verificação o protocolo suporta antes que a resistência à censura seja comprada pela degradação do caminho de execução que precisa permanecer vivo.

O artigo é relevante para engenharia institucional de protocolos blockchain porque trata resistência à censura e throughput como propriedades acopladas. Em uma rede de validadores em produção, esse acoplamento vira problema de implementação e operação: fanout de clientes, atribuição de proponentes, política de mempool, supressão de duplicatas e verificação de inclusão determinam se a cadeia preserva Deterministic state transition testing, Consensus edge-case analysis e Validator operations hardening sob pressão adversária de ordenação.

Mapeamento institucional:

selected_domain: Blockchain Protocol Engineering
selected_capability_lines: Consensus edge-case analysis; Validator operations hardening; Deterministic state transition testing
why this paper supports enterprise engineering decisions: o artigo torna explícito o custo protocolar de garantias anti-censura mais fortes e força operadores a definir orçamentos mensuráveis de inclusão, duplicação e throughput, em vez de depender de alegações genéricas de descentralização.

Nota de Rastreabilidade

Artigo: Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols. Autores: Fatima Elsheimy, Ioannis Kaklamanis, Sarisht Wadhwa, Charalampos Papamanthou, Fan Zhang. Fonte: IACR Cryptology ePrint 2026/126; listado em páginas dos autores como ACM CCS 2026. Link: https://eprint.iacr.org/2026/126.

Linha Base de Reivindicações da Fonte

Reivindicações limitadas à fonte: o artigo estuda protocolos BFT multi-proposer; analisa o tradeoff entre resistência à censura e throughput; considera comportamento adversário na participação de proponentes ou validadores; foca na tensão criada quando disseminação mais forte ou atribuição de proponentes melhora proteção de inclusão enquanto aumenta dados duplicados ou pressão sobre espaço de bloco; e apresenta abordagens de atribuição protocolar destinadas a permitir que projetistas escolham pontos diferentes nessa curva de tradeoff. Nenhum benchmark empírico de produção, incidente de implantação ou estudo de caso empresarial é assumido aqui.

2. Deconstrução Técnica

A lição central é que resistência à censura não é uma propriedade booleana de consenso. É uma propriedade de serviço com custo. Uma transação pode ser resistente à censura dentro de uma janela somente se caminhos honestos independentes suficientes conseguirem carregá-la até o log ordenado antes que proponentes adversários a excluam. Esses caminhos consomem largura de banda, ciclos de verificação, capacidade de mempool e bytes de proposta. Designs multi-proposer, portanto, deslocam o problema da discricionariedade de um líder único para alocação de recursos entre réplicas.

O primeiro invariante é inclusão sob controle adversário limitado de proponentes:

\mathsf{Incl}(tx,\Delta)=1 \Leftarrow h(tx,\Delta) \ge q_{\mathrm{incl}} \land d(tx,\Delta) \le d_{\max} \tag{1}

Em (1), $h(tx,\Delta)$ é o número de caminhos honestos de proponente ou relay que recebem $tx$ na janela $\Delta$ , $q_{\mathrm{incl}}$ é o limiar mínimo de caminhos independentes e $d(tx,\Delta)$ é o volume duplicado. A decisão operacional é explícita: aumentar $q_{\mathrm{incl}}$ eleva a garantia de inclusão, mas permitir $d(tx,\Delta)>d_{\max}$ ameaça throughput e estabilidade de propagação.

O segundo invariante é segurança determinística de estado sob contribuição concorrente de propostas:

\forall r_i,r_j:\ \mathsf{ValidTranscript}(r_i)=1 \land \mathsf{ValidTranscript}(r_j)=1 \Rightarrow S_i^{k}=S_j^{k} \tag{2}

A equação (2) é a fronteira de Deterministic state transition testing. Se supressão de duplicatas, atribuição de proponentes ou reconciliação de listas de inclusão forem políticas locais em vez de especificação, réplicas corretas podem aceitar transcritos localmente válidos que divergem na ordem de execução.

3. Suposições Ocultas

A primeira suposição oculta é que duplicação de transações é benigna. Não é. Tráfego duplicado consome capacidade escassa de proposta e pode se tornar alavanca adversária. Um participante racional ou bizantino pode amplificar transações de baixo valor, aumentar pressão sobre relays e empurrar transações críticas para um caminho congestionado.

A segunda suposição é que diversidade honesta de proponentes estará disponível exatamente quando necessário. Em uma rede eventualmente síncrona, uma transação pode alcançar muitos nós e ainda assim não alcançar o subconjunto relevante para a próxima janela de decisão. Concentração geográfica, provedores de infraestrutura correlacionados, padrões de relay de clientes e topologia de peering reduzem diversidade efetiva.

A terceira suposição é que resistência à censura pode ser avaliada sem incentivos econômicos. Em proof-of-stake, comportamento de proponentes é moldado por taxas, MEV, exposição a slashing, relações com relays e restrições jurisdicionais.

Um modelo operacional de exposição é:

E_{\mathrm{cens}}(tx)=\Pr[A_{\mathrm{prop}}] \times \Pr[\neg H_{\mathrm{path}}(tx)] \times V(tx) \tag{3}

Aqui $A_{\mathrm{prop}}$ representa controle adversário ou censor durante a janela relevante, $H_{\mathrm{path}}(tx)$ é a existência de ao menos um caminho honesto efetivo, e $V(tx)$ é valor ou sensibilidade temporal. A equação (3) conecta configuração protocolar à classificação de risco.

4. Stress Test Adversário

O adversário deve ser modelado como mais que um líder faltoso. Em BFT multi-proposer, ele pode manipular a relação entre custo de disseminação e probabilidade de inclusão.

Classe um: coalizão de proponentes seletivos que omite transações específicas enquanto aceita tráfego suficiente para preservar aparência de liveness.

Classe dois: amplificador de duplicação que envia transações sobrepostas a múltiplos proponentes para consumir espaço de bloco e ciclos de deduplicação.

Classe três: adversário de topologia que explora concentração de relays ou partições para fazer o fanout parecer amplo enquanto o alcance honesto efetivo permanece pequeno.

Classe quatro: adversário racional de ordenação que censura ou atrasa transações quando o lucro privado de ordenação excede a penalidade protocolar.

A condição de stress deve ser:

\rho=\frac{B_{\mathrm{dup}} + B_{\mathrm{adv}}}{B_{\mathrm{slot}}},\quad \mathsf{HaltRisk}=1\ \text{if}\ \rho>\rho_{\max} \tag{4}

A equação (4) fornece um limiar de release. $B_{\mathrm{dup}}$ é payload honesto duplicado, $B_{\mathrm{adv}}$ é payload adversário e $B_{\mathrm{slot}}$ é a capacidade do slot. Se a inclusão melhora apenas enquanto $\rho$ é pequeno, o comportamento em sobrecarga ainda não foi especificado.

5. Operacionalização

Uma implementação de produção precisa de controles explícitos de admissão, atribuição e observabilidade. O protocolo não deve deixar garantias de inclusão para comportamento informal de wallet ou RPC.

O cliente validador deve expor métricas de razão de duplicatas por slot, alcance efetivo de proponentes, latência de inclusão por classe de transação, taxa de omissão por proponente, concentração de relays e utilização de bloco após deduplicação. Essas métricas devem ser rotuladas por classe, pois médias escondem censura direcionada.

type TxClass int

const (
    Ordinary TxClass = iota
    SettlementCritical
    BridgeCritical
    LiquidationCritical
)

func RequiredFanout(class TxClass, censorBudget float64, honestReach float64) int {
    for fanout := 1; fanout <= 64; fanout++ {
        miss := pow(1.0-honestReach, fanout)
        if miss <= censorBudget {
            return fanout
        }
    }
    return 64
}

func AdmitProposal(slot Slot, policy Policy) error {
    if slot.DuplicateBytes/slot.CapacityBytes > policy.MaxDuplicateRatio {
        return ErrDuplicateBudgetExceeded
    }
    if !VerifyDeterministicDedup(slot.Transcript) {
        return ErrNonDeterministicTranscript
    }
    return nil
}

A decisão de fanout pode ser representada por:

f^\star=\min f\ \text{such that}\ (1-p_h)^f \le \epsilon_{\mathrm{cens}} \tag{5}

A equação (5) transforma resistência à censura em controle explícito. $p_h$ é o alcance honesto efetivo por caminho, $f^\star$ é o fanout requerido e $\epsilon_{\mathrm{cens}}$ é a probabilidade de falha tolerada.

6. Impacto Empresarial

O impacto empresarial é governança de garantias de ordenação. Sistemas que liquidam obrigações financeiras, fazem bridges, executam leilões ou acionam liquidações não podem tratar resistência à censura como slogan de camada base. Eles precisam de um serviço de inclusão mensurável com orçamentos de falha.

Para equipes de protocolo, isso altera a especificação. Deduplicação, atribuição e regras de contribuição de proponentes precisam ser visíveis ao consenso e testáveis. Para operações de validadores, altera posicionamento de infraestrutura, diversidade de relays, observabilidade de mempool e resposta a incidentes.

O SLO relevante não é throughput bruto. É throughput depois de pagar pela garantia de inclusão selecionada:

T_{\mathrm{usable}}=T_{\mathrm{raw}} \times (1-\delta_{\mathrm{dup}}) \times (1-\delta_{\mathrm{verify}}) \tag{6}

A equação (6) evita erro comum de reporte. Se maior resistência à censura eleva $\delta_{\mathrm{dup}}$ e $\delta_{\mathrm{verify}}$ , o throughput bruto anunciado não é o throughput disponível para aplicações.

7. O Que a STIGNING Faria de Forma Diferente

Especificar tratamento de duplicatas como validade de consenso, incluindo identidade canônica de transação, regras determinísticas e compromissos de transcrito.
Exigir política de fanout por classe de transação, com orçamentos explícitos para settlement, bridge, liquidação, governança e transferências ordinárias.
Adicionar testes adversários combinando omissão seletiva, amplificação de duplicatas, partições parciais e concentração de relays.
Publicar métricas de cliente validador para alcance honesto efetivo, não apenas contagem de peers ou tamanho agregado de mempool.
Tratar atribuição de proponentes como parâmetro de segurança e testá-la contra janelas de censura direcionada.
Impor razão máxima de payload duplicado na admissão de propostas.
Construir testes determinísticos de transição de estado sobre conjuntos duplicados malformados e contribuições conflitantes.

O invariante de admissão deve ser:

\mathsf{Admit}(P)=1 \Rightarrow \mathsf{DetDedup}(P)=1 \land \rho(P)\le\rho_{\max} \land \mathsf{AssignValid}(P)=1 \tag{7}

A equação (7) é implementável no cliente validador. Se uma proposta não prova deduplicação determinística e atribuição válida dentro do orçamento de duplicatas, ela não deve ser admitida.

8. Perspectiva Estratégica

BFT multi-proposer é estrategicamente importante porque reduz dependência de um líder privilegiado, mas não elimina poder de ordenação. Ele redistribui esse poder para regras de atribuição, economia de disseminação e gestão de duplicatas. Essa redistribuição precisa ser especificada, medida e testada.

A direção de longo prazo deve ser em camadas. O protocolo base fornece mecânica determinística de inclusão e contribuição responsabilizável de proponentes. A camada transacional expõe fanout ajustável e orçamentos de risco por classe. A camada operacional mede continuamente se o alcance honesto efetivo corresponde às premissas do design.

O critério estratégico é:

\Pr[\mathsf{Include}(tx,\Delta)\mid \mathsf{Class}(tx)=c] \ge 1-\epsilon_c\ \land\ T_{\mathrm{usable}}\ge T_{\min} \tag{8}

A equação (8) captura o tradeoff central: o protocolo só é aceitável se atender à probabilidade de inclusão exigida por classe mantendo throughput utilizável acima do mínimo operacional.

Referências

Fatima Elsheimy, Ioannis Kaklamanis, Sarisht Wadhwa, Charalampos Papamanthou, Fan Zhang. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols. IACR Cryptology ePrint 2026/126. https://eprint.iacr.org/2026/126
Fan Zhang publication list. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols, ACM CCS 2026 listing. https://fanzhang.me/publications/
Sarisht Wadhwa publication list. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols, Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2026. https://sarisht.github.io/

Conclusão

O artigo é valioso porque formaliza uma tensão inevitável em blockchain de produção: resistência mais forte à censura em janelas curtas consome recursos que também determinam throughput e liveness. A resposta correta é especificar orçamentos de inclusão, limites de duplicação, regras determinísticas de proposta e telemetria de validadores para tornar o tradeoff explícito e executável sob condições adversárias.

STIGNING Academic Deconstruction Series Engineering Under Adversarial Conditions