a16z Crypto explores the fundamental tension between “censorship resistance” and “low latency” in blockchains
Odaily reported that a16z Crypto published an article exploring the fundamental contradiction between blockchain “censorship resistance” and “low latency,” pointing out that any Byzantine Fault Tolerant (BFT) blockchain protocol with censorship resistance, where more than one-fifth of validators could be malicious, requires at least 5 rounds of communication for its optimal good-case latency, whereas traditional BFT consensus only requires a minimum of 3 rounds.
The article notes that in traditional BFT protocols, the block proposer holds the power for both block construction and consensus progression, allowing them to censor by excluding specific transactions. This is also a major source of the MEV problem. To address this issue, Ethereum is researching FOCIL / EIP-7805, while Solana is exploring mechanisms like Constellation and MCP. The core idea behind these approaches is to have validators proactively collect "Inclusion Lists" of transactions that cannot be ignored before a block is formally proposed.
a16z Crypto states that achieving censorship resistance requires two additional rounds of communication: first, user transactions must be broadcast to all validators, and then the validators need to confirm and write these into an inclusion list before the consensus process can begin. Therefore, in a partially synchronous network environment, there is no protocol design that can achieve both BFT and censorship resistance in just 4 rounds; 5 rounds represent the mathematical lower limit.
The article emphasizes that while a censorship-resistant mechanism increases protocol latency, it can significantly reduce the "effective latency" users actually experience. In a system lacking censorship resistance, transactions may be indefinitely delayed due to validator censorship. Conversely, in a system with censorship resistance guarantees, transactions will be included in a block within a maximum of 5 rounds of communication, making transaction confirmation times more predictable.
