Censorship Resistance Versus Throughput in Multi-Proposer BFT

1. Institutional Framing

Multi-proposer Byzantine fault tolerant consensus is usually introduced as a way to reduce single-leader censorship power. That framing is directionally correct but incomplete. The operational question is not whether more proposers improve inclusion probability in isolation. The hard question is how much duplicated proposal traffic, blockspace waste, relay pressure, and verification load the protocol can absorb before censorship resistance is purchased by degrading the execution path that must remain live.

This paper is relevant to institutional blockchain protocol engineering because it treats censorship resistance and throughput as coupled properties rather than independent objectives. In a production validator network, that coupling becomes an implementation and operations problem: client fanout, proposer assignment, mempool policy, duplicate suppression, and inclusion verification all affect whether the chain preserves deterministic state transition testing, consensus edge-case analysis, and validator operations hardening under adversarial ordering pressure.

Institutional domain mapping:

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: it exposes the protocol-level cost of stronger anti-censorship guarantees and forces operators to specify measurable inclusion, duplication, and throughput budgets instead of relying on generic decentralization claims.

Traceability Note

Paper: Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols. Authors: Fatima Elsheimy, Ioannis Kaklamanis, Sarisht Wadhwa, Charalampos Papamanthou, Fan Zhang. Source: IACR Cryptology ePrint 2026/126; listed by author publication pages as ACM CCS 2026. Link: https://eprint.iacr.org/2026/126.

Source Claim Baseline

Source-bounded claims are: the paper studies multi-proposer BFT protocols; it analyzes the tradeoff between censorship resistance and throughput; it considers adversarial behavior in proposer or validator participation; it focuses on the tension created when stronger transaction dissemination or proposer assignment improves inclusion protection while increasing duplicated data or blockspace pressure; and it presents protocol assignment approaches intended to let designers select different points on that tradeoff curve. No empirical production benchmark, deployment incident, or enterprise case study is assumed here.

2. Technical Deconstruction

The central engineering lesson is that censorship resistance is not a Boolean consensus property. It is a costed service-level property. A transaction may be censorship-resistant within a time window only if enough independent honest paths can carry it into the ordered log before adversarial proposers can exclude it. Those paths consume bandwidth, verification cycles, mempool capacity, and proposal bytes. Multi-proposer designs therefore move the problem from single-leader discretion into a resource allocation problem across replicas.

For protocol engineering, the first invariant is inclusion under bounded adversarial proposer control:

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

In equation (1), $h(tx,\Delta)$ is the number of honest proposer or relay paths that receive transaction $tx$ inside window $\Delta$ , $q_{\mathrm{incl}}$ is the minimum independent-path threshold, and $d(tx,\Delta)$ is duplicated payload volume. The operational decision is explicit: increasing $q_{\mathrm{incl}}$ raises inclusion assurance, but allowing $d(tx,\Delta)$ to exceed $d_{\max}$ threatens throughput and propagation stability.

The second invariant is deterministic state safety under concurrent proposal contribution. Multiple proposers may contribute data, but the committed sequence must remain uniquely derivable from the protocol transcript.

\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}

Equation (2) is the deterministic state transition testing boundary. If duplicate suppression, proposer assignment, or inclusion-list reconciliation is implementation-defined rather than specified, two correct replicas can accept locally valid transcripts that diverge in execution order. Throughput optimization must not be allowed to create non-deterministic ordering.

The practical design consequence is that the consensus specification needs first-class fields for proposer identity, transaction contribution provenance, duplicate handling, and inclusion eligibility. Treating these as mempool implementation details collapses a consensus property into local policy.

3. Hidden Assumptions

The first hidden assumption is that transaction duplication is benign. It is not. Duplicate traffic consumes scarce proposal capacity and can become an adversarial lever. A rational or Byzantine participant can amplify low-value transactions, increase relay pressure, and force high-value transactions into a congested inclusion path.

The second hidden assumption is that honest proposer diversity is available exactly when needed. In an eventually synchronous network, a transaction may reach many nodes but still fail to reach the subset that matters for the next decision window. Geographic concentration, correlated infrastructure providers, client-side relay defaults, and validator peering topology can reduce effective diversity below the theoretical validator count.

The third hidden assumption is that censorship resistance can be evaluated independently of economic incentives. In proof-of-stake systems, proposer behavior is shaped by fees, MEV, slashing exposure, relay relationships, and jurisdictional constraints. A protocol that assumes arbitrary Byzantine faults but ignores rational omission incentives may pass a safety proof while failing under market pressure.

An operational exposure model is:

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

Here $A_{\mathrm{prop}}$ is adversarial or censoring proposer control during the relevant window, $H_{\mathrm{path}}(tx)$ is the event that at least one effective honest inclusion path exists, and $V(tx)$ is transaction value or time sensitivity. Equation (3) links protocol configuration to risk classification: liquidation, bridge, governance, and settlement transactions require different fanout and inclusion budgets than ordinary transfers.

4. Adversarial Stress Test

The adversary should be modeled as more than a faulty leader. In a multi-proposer BFT design, the attacker can manipulate the relation between dissemination cost and inclusion probability.

Adversary class one is a selective proposer coalition that omits specific transactions while accepting enough unrelated traffic to preserve liveness optics. This attack is difficult to detect if monitoring only tracks block production and aggregate throughput.

Adversary class two is a duplication amplifier that floods multiple proposers with overlapping transactions to consume blockspace and force honest nodes to spend cycles on deduplication and validation.

Adversary class three is a topology adversary that exploits relay concentration or network partitioning to make client fanout appear large while honest effective reach remains small.

Adversary class four is a rational ordering adversary that censors or delays transactions when private ordering profit exceeds protocol penalty.

The stress condition should be tested as:

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

Equation (4) gives a release threshold. $B_{\mathrm{dup}}$ is duplicate honest payload, $B_{\mathrm{adv}}$ is adversarial payload, and $B_{\mathrm{slot}}$ is available slot capacity. A protocol implementation that improves inclusion only while $\rho$ remains small is not production-ready until overload behavior is specified.

5. Operationalization

A production implementation needs explicit admission, assignment, and observability controls. The protocol should not leave inclusion guarantees to informal wallet or RPC behavior.

The validator client should expose metrics for per-slot duplicate ratio, effective proposer reach, inclusion latency by transaction class, proposer omission rate, relay concentration, and post-deduplication block utilization. These metrics must be tagged by transaction class because average inclusion latency hides targeted censorship.

The transaction dissemination layer should support policy-selected fanout. High-value transactions can pay higher bandwidth cost for stronger short-window inclusion probability. Low-value transactions can accept lower fanout. That choice must be authenticated and measurable, otherwise clients cannot reason about the risk they bought.

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
}

The fanout decision can be represented as:

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

Equation (5) turns censorship resistance into a client-facing control. $p_h$ is effective honest reach per contacted path, $f^\star$ is required fanout, and $\epsilon_{\mathrm{cens}}$ is the tolerated miss probability for the transaction class.

6. Enterprise Impact

The enterprise impact is governance of ordering guarantees. Systems that settle financial obligations, bridge assets, run auctions, or trigger liquidations cannot treat censorship resistance as a chain-level slogan. They need a measurable inclusion service with failure budgets and monitoring.

For protocol teams, this affects specification work. Deduplication, assignment, and proposer contribution rules must be consensus-visible and testable. For validator operations, it affects infrastructure placement, relay diversity, mempool observability, and incident response. For risk teams, it affects whether critical workflows can rely on base-layer inclusion during adversarial windows.

The relevant service-level objective is not raw throughput. It is throughput after paying for the selected inclusion guarantee:

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

Equation (6) prevents a common reporting failure. If stronger censorship resistance increases duplicate ratio $\delta_{\mathrm{dup}}$ and verification overhead $\delta_{\mathrm{verify}}$ , the advertised raw throughput is not the throughput available to applications.

7. What STIGNING Would Do Differently

Specify duplicate handling as part of consensus validity, including canonical transaction identity, deterministic first-seen rules, and transcript commitments.
Require transaction-class-aware fanout policy with explicit risk budgets for settlement, bridge, liquidation, governance, and ordinary transfers.
Add adversarial load tests that combine selective omission, duplicate amplification, partial partitions, and relay concentration.
Publish validator-client metrics for effective honest reach, not only peer count or aggregate mempool size.
Treat proposer assignment as a security parameter and regression-test it against targeted censorship windows.
Enforce maximum duplicate payload ratios at proposal admission so anti-censorship machinery cannot silently consume execution capacity.
Build deterministic state transition testing around malformed duplicate sets, conflicting proposer contributions, and reorg-adjacent inclusion lists.

The admission invariant should be:

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

Equation (7) is implementable as validator-client consensus validation. If a proposal cannot prove deterministic deduplication and valid proposer assignment under the duplicate budget, it should not be admitted.

8. Strategic Outlook

Multi-proposer BFT is strategically important because it reduces dependence on a privileged leader, but it does not eliminate ordering power. It redistributes ordering power into assignment rules, dissemination economics, and duplicate management. That redistribution must be specified, measured, and tested.

The long-term direction should be layered. The base protocol should provide deterministic inclusion mechanics and accountable proposer contribution. The transaction layer should expose tunable fanout and class-specific risk budgets. The operations layer should continuously measure whether effective honest reach matches the assumptions used by the protocol designers.

The strategic success condition is:

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

Equation (8) captures the central tradeoff. A protocol is acceptable only if it meets the inclusion probability required by each transaction class while preserving usable throughput above the operational minimum.

References

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/

Conclusion

The paper is valuable because it formalizes a tension that production blockchain systems cannot avoid: stronger short-window censorship resistance consumes resources that also determine throughput and liveness. The correct engineering response is not to choose one property rhetorically. It is to specify inclusion budgets, duplicate limits, deterministic proposal rules, and validator telemetry so the tradeoff becomes explicit and enforceable under adversarial conditions.

STIGNING Academic Deconstruction Series Engineering Under Adversarial Conditions