
a16z: “Strong Chain Quality” Grants Each Staker Dedicated Space Within a Block
TechFlow Selected TechFlow Selected

a16z: “Strong Chain Quality” Grants Each Staker Dedicated Space Within a Block
From Chain Quality to Strong Chain Quality: How to Truly Achieve “My Transaction, My Control” in the High-Throughput Era
Authors: @ittaia, @PGarimidi, and @jneu_net
Translation: AididiaoJP, Foresight News
Chain Quality (CQ) is a core property of blockchains. Informally, it means:
If you hold 3% of the total staked stake, then over time on average, you control 3% of the block space.
For early low-throughput blockchains, chain quality suffices. However, modern blockchains offer significantly higher bandwidth—each block can contain a large number of transactions.
This gives rise to a stronger, more fine-grained concept—not only concerned with the average proportion of block space over time, but also with how block space is allocated *within each individual block*. We call this “Strong Chain Quality” (SCQ):
If you hold 3% of the total staked stake, then in *every* block, you control 3% of the block space.
Essentially, this property grants stakeholders “virtual lanes” within a high-throughput blockchain, ensuring their transactions are included.
Chain Quality in Blockchains
One of Bitcoin’s key innovations—now present in nearly every blockchain—is the introduction, within the protocol itself, of a reward mechanism for block proposers: parties who successfully append a block to the state machine receive newly minted tokens and transaction fees. These rewards are specified by the state transition function and ultimately reflected in the system state.
In traditional distributed computing models, participants are divided into honest and malicious parties. There is no need to reward honest behavior, as honesty is assumed by default in the model.
In cryptoeconomic models, participants are viewed as rational agents whose utility functions may be unknown. The goal is to design incentives such that, in pursuing their own profit maximization, these participants naturally align with the successful operation of the protocol. Combined with the protocol’s internal reward mechanism, we arrive at the following idealized definition of chain quality:
Chain Quality (CQ): A coalition holding X% of the total staked stake has an X% probability of being the proposer of each block added to the chain after Global Stabilization Time (GST).
If a chain deviates from CQ requirements, certain coalitions may earn disproportionately large shares of rewards, thereby weakening the incentive for honest behavior and threatening protocol security.
Many blockchains satisfy—or strive to satisfy—this property via “stake-weighted randomized leader rotation.” Typical challenges include Bitcoin’s “selfish mining” problem; Monad’s tail-fork resistance issue; and problems in Ethereum’s LMD GHOST protocol.
The Origin of Strong Chain Quality
When block space is sufficiently abundant, there is no need to grant exclusive control over an entire block’s contents to a single proposer. Instead, block space within the same block can be jointly allocated among multiple participants. Strong Chain Quality—a cryptoeconomic definition—encapsulates precisely this idea:
Strong Chain Quality (SCQ): A coalition holding X% of the total staked stake controls X% of the block space in *every* block after Global Stabilization Time (GST).
This idealized property implicitly introduces the abstraction of “virtual lanes”: i.e., coalitions effectively control a dedicated, proportional share of block space in every block.
Economically, owning a virtual lane is equivalent to holding a productive, revenue-generating asset—revenues may come from transaction fees or MEV (Maximal Extractable Value). External entities compete for staked stake to obtain and retain access to these lanes, creating sustained demand for the underlying L1 token. The greater the economic value a lane can generate, the stronger the incentive to stake—and the higher the value accumulated by the L1 staking rights governing access to that block space. Through this abstraction, stronger censorship resistance translates into the protocol-level effectiveness of SCQ.
Strong Chain Quality and Censorship Resistance
Recent research highlights the importance of censorship-resistant protocols. Such protocols must not only guarantee that honest parties’ inputs are eventually included—but also that they are included *immediately*. Strong Chain Quality (SCQ) can be viewed as an extension of this property under finite block capacity.
In practice, if the volume of pending transactions exceeds available block space, no protocol can satisfy ideal censorship resistance. SCQ addresses this limitation pragmatically: rather than requiring all honest transactions to always be included, it allocates each staking node a “budget,” ensuring inclusion of its transactions up to that budget.
The MCP protocol was proposed as a component layered atop existing practical Byzantine Fault Tolerance (PBFT)-style consensus protocols, aiming to endow them with censorship resistance. This protocol simultaneously satisfies SCQ—allocating block space to proposers proportionally to their staked stake. Existing DAG-based BFT protocols provide a way to implement multi-writer mempools and also exhibit some degree of censorship resistance.
Standard implementations of such protocols typically fail to strictly satisfy SCQ because they allow leaders to selectively delay subsets of transactions. However, minor modifications could restore SCQ compliance. A related direction is “forced transaction inclusion,” designed to reduce censorship.
MCP further demonstrates how to realize a stronger hidden property: stakeholders can create virtual private lanes whose contents remain concealed until the full block is publicly revealed. We will elaborate on this in a follow-up article.
How to Achieve Strong Chain Quality
To achieve Strong Chain Quality after Global Stabilization Time (GST), the key is ensuring proposers cannot arbitrarily censor stakeholders’ inputs. This can be achieved via a two-round protocol. Starting from virtually any view-based BFT protocol, only two small modifications are required:
- Round 1: Each participant broadcasts its authenticated input to all other participants.
- Round 2: Each participant adds participant i to its inclusion list if it receives i’s authenticated input. It then sends its inclusion list to the leader—effectively committing to accept only blocks containing *all* inputs on that list.
- BFT Proposal: Upon receiving these messages, the leader includes the union of all received inclusion lists in the block.
- BFT Voting: A participant votes “yes” only if the block contains *all* inputs on its own inclusion list.
It is straightforward to see that this protocol sketch can be extended into a complete protocol satisfying Strong Chain Quality after GST, providing censorship resistance while maintaining liveness when the leader is honest. To achieve SCQ *before* GST, one must wait for a quorum (sufficient number) of values or lists in each round. We will detail this protocol and its extensions in a follow-up article.
Recent research shows achieving Strong Chain Quality and censorship resistance requires adding two extra rounds atop standard BFT voting rounds—as illustrated in the protocol sketch above. We will explain this result in detail in a follow-up article.
While Strong Chain Quality (SCQ) specifies the *proportion* of block space a coalition controls, it does not fully constrain *how transactions are ordered* within that space. SCQ can thus be understood as reserving space for each staking node—but making no guarantees about the ordering of transactions within that reserved space.
This opens rich avenues for research into transaction ordering mechanisms. A well-designed ordering mechanism could further enhance fairness and efficiency across the blockchain ecosystem. One promising direction is ordering transactions by priority fee.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














