将抗审查写进协议：谁来决定一笔以太坊交易能否上链？

In the world of blockchain, we often hear a term: "censorship resistance."

For many, the initial reaction might make it sound like a politically charged slogan, or even one with anarchist overtones. But for a settlement network open to global users like Ethereum, censorship resistance is first and foremost not a political stance, but a very specific technical capability.

Imagine you initiate a transaction in the imToken wallet.

The signature is correct, the account balance is sufficient, and the Gas fee isn't low either, yet the transaction is not being written into a block. The status in your wallet remains stuck at "Pending." Meanwhile, other transactions with similar or even lower fees are continuously being included in blocks.

At this point, the question becomes: who exactly has the right to decide whether a transaction can enter a block? After all, if Ethereum ultimately still requires a few centralized participants to decide which transactions can be included, then it's essentially no different from the traditional financial system.

Therefore, Ethereum has been exploring a series of anti-censorship mechanisms like FOCIL and FairFIL in recent years, attempting to answer a seemingly simple but critically important question: How can we ensure that any transaction complying with protocol rules has a fair chance to be included in a block?

1. Where Does "Censorship" Actually Come From?

To understand why Ethereum needs these mechanisms, we first need to clarify what exactly happens to a transaction after it's sent from a wallet.

When a user signs and sends a transaction in their wallet, it typically first enters Ethereum's public transaction pool, also known as the Mempool. It's more like a waiting area, holding a large number of transactions that haven't yet been written into a block.

But entering the waiting area doesn't mean the transaction is on-chain. Someone still needs to pick transactions from it, decide their order, assemble them into a complete block, and submit it to the network for confirmation.

The problem arises precisely at this stage.

After Ethereum upgraded to the PoS (Proof of Stake) mechanism, to prevent large staking pools from forming economic monopolies using MEV (Maximal Extractable Value), Ethereum introduced the PBS (Proposer-Builder Separation) system. Under this architecture, the processing flow of each Ethereum transaction is actually split between two roles:

• Builder: Responsible for collecting transactions, ordering them, finding arbitrage and liquidation opportunities, and constructing a block with the highest possible revenue;
• Proposer: Responsible for selecting one from the candidate blocks submitted by Builders and submitting it to the network;

This division of labor has very practical benefits.

As we all know, MEV strategies have become increasingly complex in recent years. If every ordinary validator were required to independently complete transaction ordering and block optimization, it would undoubtedly give an advantage to large nodes with more capital, data, and technical capabilities.

Therefore, by delegating the complex work of block construction to professional Builders, ordinary validator nodes can participate in block proposals and earn corresponding rewards even without advanced arbitrage capabilities, thereby mitigating the impact of MEV on staking decentralization.

However, it has also inadvertently brought another side effect: excessive concentration of block construction rights. For instance, currently over 90% of Ethereum blocks on the entire network are produced by just a few professional Builders. Moreover, since these Builders typically have clear corporate operational backgrounds, they are highly susceptible to external pressure from legal compliance in specific countries or regions (such as the OFAC sanctions list), which in reality constitutes a centralization risk.

It is precisely for this reason that if these few mainstream Builders selectively filter out transactions involving certain sensitive contracts (such as Tornado Cash) or specific addresses, those transactions will find themselves stuck in a predicament of not being packaged for extended periods, even facing the risk of being "silently blacklisted."

In summary, from an ordinary user's perspective, Ethereum appears to be an open network that anyone can connect to, transfer funds, and call smart contracts on. But from the perspective of protocol operation, sending a transaction is only the first step. Whether a transaction truly takes effect depends on whether it is selected, ordered, and written into a block by some block builder.

Therefore, the "censorship resistance" discussed in Ethereum is not just a grand concept related to politics, regulation, or sanctions. It is first and foremost a very specific technical question:

When a transaction satisfies the protocol rules, can the network guarantee it a chance to enter a block within a reasonable time?

2. From FOCIL to FairFIL: How Ethereum Is Restricting Block Builders

At this point, the problem is already quite clear. Builders can improve block construction efficiency, but if the power to include transactions is also concentrated in the hands of a few Builders over the long term, Ethereum will once again form a new centralized monopoly risk.

To this end, Ethereum researchers have proposed Inclusion Lists.

The name might sound somewhat abstract, but its core logic isn't complicated—Builders still produce blocks, but they cannot unilaterally decide the fate of all transactions. Validator nodes participating normally in Ethereum staking also need to retain some power, allowing them to list transactions that must be processed.

Using a bus station as an analogy, consider a block as a bus trip with limited seats.

The Builder decides how most passengers queue up and where they sit, increasing the entire trip's revenue through more efficient arrangements. But validator nodes can also submit a "must-board list." As long as the transactions on the list are still valid, willing to pay reasonable fees, and there's enough space in the block, the Builder cannot simply keep refusing them based on personal preference.

However, who exactly creates an inclusion list, and what to do if someone deliberately omits transactions, are still two issues that need further resolution.

FOCIL and FairFIL unfold precisely along these two directions.

1. FOCIL: No Longer Letting a Single Proposer Create the Inclusion List Alone

FOCIL (Fork-Choice Enforced Inclusion Lists) shifts the power to decide whether transactions must be included from a single proposer to a "validator committee" composed of multiple parties.

In each block production cycle, the network randomly selects a group of validators to form a temporary committee. Each member of the committee independently observes the network mempool and submits their own local inclusion list.

This means that even if 99% of Builders and proposers across the entire network attempt to censor a particular transaction, as long as one honest node on the committee places that transaction on the list, the transaction has a chance to be protected by protocol constraints. Censors who want to continue excluding it would no longer just be affecting one entity; they would need to bypass multiple independent participants simultaneously.

So its advantage lies in not needing to trust every member of the committee to remain neutral.

But having a list isn't enough. If Builders still choose not to execute it after receiving the list, the inclusion list would become a non-binding suggestion.

Therefore, FOCIL adds a second layer of design, introducing the Fork-Choice Rule for hard constraints. This ensures that validation nodes across the network strictly check the blocks submitted by Builders. Once they detect that a Builder has violated the committee's integrated inclusion list, the entire network will directly refuse to vote for that block.

This means a violating block would be instantly deemed invalid by the protocol, and the Builder would pay a huge price for the failed block production.

2. FairFIL: Not Just Plugging Leaks, But Making Omissions Verifiable

If FOCIL is about hard-prohibiting censorship through consensus rules, then FairFIL (Fair Forward Inclusion Lists) and accountability mechanisms aim to make censorship behavior extremely costly and unsustainable from an economic perspective.

Simply put, it raises further requirements. For instance, why a transaction didn't enter a block should leave a publicly inspectable record as much as possible.

In actual network operation, Builders might need an extremely short buffer period to optimize transaction ordering and MEV arbitrage. FairFIL allows Builders to make flexible adjustments under specific constraints. However, if a Builder attempts to extend certain censorship behavior to the next block, the protocol immediately triggers an accountability process.

Its general logic can be understood in three steps.

• First, the protocol establishes a set of public, verifiable reference rules to determine which transactions in the public mempool should normally qualify for inclusion in the current block. If certain transactions that were originally eligible under the reference rules end up not being processed, the Builder is required to publicly list them in FairFIL;
• Subsequently, validators check whether this list is complete. If a Builder omitted eligible transactions without listing them, such behavior could be detected and affect whether validator nodes support that block;
• Finally, valid transactions that enter FairFIL become priority tasks for subsequent blocks. The next Builder can still arrange their specific positions within the block, but cannot continue to pretend they don't exist;

If a transaction is continuously omitted, the related blocks may lose validator support, and the Builder could lose the entire block's revenue as a result.

In other words, the "accountability" emphasized by FairFIL actually works by introducing tiered economic penalties. Builders who persistently censor transactions face the risk of being deprived of entire block rewards, or even facing slashing of their staked deposits.

This is also the direction in which Ethereum's anti-censorship mechanisms are progressively deepening. The goal is to establish a more realistic set of constraints: even if a minority of participants have censorship intentions, it becomes difficult for them to control the transaction entry point over the long term; even if someone deliberately omits transactions, they must leave traces and pay increasingly higher costs for persistent censorship.

3. What Does This Mean for Ordinary Users?

For ordinary users who transfer funds, swap tokens, or use DeFi through their wallets every day, even if these underlying mechanisms are implemented in the future, they won't need to change their existing operational habits.

Users will still enter amounts in their wallets, confirm Gas, complete signatures, and then wait for transactions to be included on-chain. But beneath the surface where users can't see, the logic of whether transactions can enter blocks may undergo significant changes.

What it truly improves is the certainty of the transaction inclusion process.

• First, a transaction that complies with the rules will no longer entirely depend on a specific Builder's choice: Even if the current Builder is unwilling to process it, other validators can establish a protocol-level inclusion requirement for it through inclusion lists;
• Second, the power of transaction inclusion and transaction ordering may gradually separate: Builders can still use professional algorithms to arrange transaction order and increase block revenue, and can still compete around arbitrage and liquidations. However, their power to decide "who is eligible to enter the market" will be restricted;

Looking further ahead, Ethereum's credible neutrality may also gradually evolve from a value proposition that depends on participant commitments to protocol rules automatically enforced by clients.

Users don't need to know which Builder constructed the current block, nor do they need to trust each Builder to proactively remain neutral. Validator nodes will check blocks according to the same set of rules, making it difficult for blocks that violate inclusion obligations to gain network approval.

In the future, wallets and block explorers may even provide more detailed transaction statuses based on this.

A transaction would no longer merely show a generic "Pending" status. Instead, it might further inform users whether it has entered an inclusion list, whether it has obtained an inclusion obligation for subsequent blocks, and whether continued waiting is due to insufficient Gas, transaction expiration, or anomalies in the block construction process.

However, anti-censorship mechanisms do not mean every transaction will succeed immediately.

Transactions with insufficient balance, Nonce conflicts, excessively low Gas, or expired contract execution conditions may still fail to enter blocks. When the network is congested and block space is scarce, users will still need to compete through fees and wait for confirmation.

But what it primarily improves is that a valid transaction with reasonable fees that has already propagated to the public mempool should not be indefinitely delayed due to the subjective choices of a few block builders.

In terms of progress, as of August 2026, EIP-7805, corresponding to FOCIL, is still in Draft status. However, it has already been selected by Ethereum core developers as the consensus layer Headliner for the Hegotá upgrade and has entered the Scheduled for Inclusion stage, meaning client teams have agreed to move forward with implementation and devnet testing around it. However, the specific mainnet launch date has not yet been finalized.

FairFIL is even earlier in development. It is currently primarily a research proposal published in July 2026. Whether it will enter the Ethereum roadmap in the future still requires broader discussion, implementation, and security validation.

Final Thoughts

Objectively speaking, Ethereum cannot guarantee that every Builder, validator, and infrastructure operator will remain neutral forever.

Participants may face regulatory pressure, may pursue their own interests, and may accept external incentives. A truly resilient decentralized network cannot be built on the idealistic assumption that "everyone will do the right thing."

True censorship resistance means that even if some participants attempt to interfere with transactions, other participants still have the ability to break that control; even if someone chooses to deviate from the principle of neutrality, the protocol can make such behavior visible, costly, and unsustainable.

From the initial inclusion lists, to FOCIL which collectively constrains Builders through a distributed committee, to FairFIL which requires omissions to be publicly verifiable—from allowing anyone to send transactions, to ensuring anyone's transactions have a chance to be seen.

From this perspective, Ethereum is indeed attempting to write this commitment into the protocol itself, step by step, transforming it from a value declaration into code.

Something worth looking forward to.