Written by: imToken

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

Many people's first reaction might think it sounds like a politicized slogan, even with some anarchist undertones, but for a settlement network like Ethereum that is open to users worldwide, anti-censorship is not primarily a political stance, but a very specific technical capability.

Imagine that you initiated a transaction in your imToken wallet.

The signature is correct, the account balance is sufficient, and the Gas fee is not low, yet the transaction has not been included in a block for a long time, and the state in the wallet remains "Pending," while other transactions with similar or even lower fees are continuously being added to the blockchain.

At this point, the question becomes, who has the authority to decide whether a transaction can enter a block? After all, if Ethereum ultimately requires a few centralized participants to decide which transactions can be included in the blockchain, then there is little fundamental difference between it and traditional financial systems.

Therefore, in recent years, Ethereum has been exploring a series of anti-censorship mechanisms like FOCIL and FairFIL, attempting to answer a seemingly simple yet crucial question: how to ensure that any transaction that meets the protocol's rules has a fair chance of entering a block?

1. Where does "censorship" come from?

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

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

However, entering the waiting area does not mean that the transaction is on the blockchain; someone still needs to select transactions from it, determine their order, assemble a complete block, and then submit it to the network for confirmation.

The problem arises at this stage.

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

• Builder: responsible for collecting transactions, arranging their order, searching for arbitrage and liquidation opportunities, and constructing a block that maximizes profit;
• Proposer: responsible for selecting a candidate block submitted by the Builder and submitting it to the network;

This division of labor has practical benefits.

It is well-known that MEV strategies have become increasingly complex in recent years. If every ordinary validator is required to independently complete transaction ordering and block optimization, it would undoubtedly give larger nodes with more funds, data, and technical capabilities an advantage.

Therefore, by delegating the complex task of building blocks to professional Builders, ordinary validating nodes, even without advanced arbitrage capabilities, can still participate in block proposals and earn corresponding rewards, thus alleviating the impact of MEV on the decentralization of staking.

However, it inadvertently brings another side effect, which is the excessive concentration of block construction rights. Currently, over 90% of Ethereum blocks are produced by only a handful of professional Builders, and since these Builders typically have a clear operational background, they can easily be subjected to external pressures related to legal compliance in specific countries or regions (for example, OFAC sanction lists), effectively creating a risk of centralization.

Because of this, once these mainstream Builders selectively filter out certain sensitive contracts (like Tornado Cash) or transactions from specific addresses, those transactions could be trapped in a long period of being unable to be packaged, even facing the risk of being "covertly banned."

In summary, for ordinary users, Ethereum appears to be an open network where anyone can connect, transfer, and call smart contracts, but from the perspective of protocol operation, sending a transaction is just the first step; whether the transaction can truly take effect also depends on whether it is selected, ordered, and written into a block by some block builder.

Thus, the "anti-censorship" that Ethereum discusses is not merely a grand concept related to politics, regulation, or sanctions; it is first and foremost a very specific technical problem:

When a transaction meets the protocol's rules, can the network guarantee that it has an opportunity to enter a block within a reasonable timeframe?

2. From FOCIL to FairFIL: How Ethereum Limits Block Builders

Actually, at this point, the issue is quite clear: Builders can improve block construction efficiency, but if the power to include transactions remains concentrated in the hands of few Builders, Ethereum could again form new monopolistic risks.

To this end, Ethereum researchers have proposed Inclusion Lists, commonly referred to as "inclusion lists."

This term sounds somewhat abstract, but its core logic is not complex—Builders remain responsible for creating blocks, but cannot unilaterally decide which transactions to include or exclude; regular validators participating in Ethereum staking need to retain some power to list transactions that must be processed.

Taking a bus station as an example, a block can be understood as a bus with limited seats.

Builders decide how most passengers line up and where they sit, thus improving the overall revenue of the trip through more efficient arrangements; but validators can also submit a "must-board list," and as long as the transactions on the list are still valid, willing to pay reasonable fees, and there is enough space in the block, Builders cannot reject them based solely on personal preference.

However, which party will create an inclusion list and what to do if someone intentionally leaves out transactions remains two problems that need to be further solved.

FOCIL and FairFIL are developed in these two directions.

1. FOCIL: No Longer Allowing a Single Proposer to Create Inclusion Lists

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

In each block interval, the network will randomly select a group of validators to form a temporary committee, and each member of the committee will independently observe the network's mempool and submit their own local inclusion lists.

This means that even if 99% of Builders and proposers in the network attempt to censor a certain transaction, as long as there is 1 honest node in the committee that includes the transaction in the list, that transaction has a chance to enter the protocol constraints, and if the censor wants to continue excluding it, they will need to bypass multiple independent participants, not just one.

Therefore, its advantage lies in not needing to trust that every person in the committee remains neutral.

However, having just the list is not enough; if Builders receive the list but still choose not to execute it, the inclusion list becomes a non-binding recommendation.

Therefore, FOCIL adds a second layer of design by introducing fork-choice rules to enforce strict constraints, requiring all network nodes responsible for validating and voting to carefully check the blocks submitted by Builders. Once a violation of the committee's integrated inclusion list is found, the entire network will directly refuse to vote for that block.

This means that the violating block will be instantly deemed invalid by the protocol, and Builders will bear significant costs for block production failure.

2. FairFIL: Not Only Filling Gaps but Making Omissions Verifiable

If FOCIL strictly prohibits censorship through consensus rules, FairFIL (Fair Forward Inclusion Lists) along with accountability mechanisms makes censorship actions extremely costly and unsustainable from an economic perspective.

In simple terms, it raises further requirements, such as providing public and verifiable records explaining why a transaction did not enter a block.

In real network operations, Builders may require a very short buffer period to optimize transaction ordering and MEV arbitrage. FairFIL allows Builders some flexibility in adjustments under certain constraints, but if a Builder tries to continue any sort of censorship into the next block, the protocol will immediately initiate an accountability process.

Its general logic can be understood in three steps.

• First, the protocol establishes a set of public, verifiable reference rules to judge which transactions in the public transaction pool qualify for entry into the current block under normal conditions. If certain transactions that are originally qualified according to the reference rules are ultimately not processed, the Builder must publicly list them in FairFIL;
• Next, validators will check if this list is complete. If a Builder clearly omitted qualifying transactions but did not include them in the list, that behavior may be detected and impact whether validating nodes support that block;
• Finally, valid transactions included in FairFIL will become priority tasks for subsequent blocks. The next Builder can still arrange their specific positions in the block but cannot continue to pretend they are not there;

If a transaction is consecutively omitted, the related block 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 means that by introducing a tiered economic penalty, Builders who continually censor transactions will face the risk of being stripped of the entire block reward and even losing their staked deposits.

This is also the direction of Ethereum's deeper anti-censorship mechanisms, aiming to establish a more realistic constraint; even if a few participants have intentions to censor, it is very difficult for them to control transaction entry in the long term; even if someone intentionally leaves out transactions, they must leave traces and pay increasingly high costs for continued censorship.

3. What Does This Mean for Ordinary Users?

For ordinary users who transfer, exchange, or use DeFi through wallets every day, even if these underlying mechanisms are implemented in the future, there will be no need to change existing operational habits.

Users will still fill in the amount in their wallets, confirm Gas, complete the signature, and then wait for the transaction to be added to the blockchain, but under the unseen underlying protocol, the logic determining whether the transaction can enter a block may undergo significant changes.

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

• First, a transaction that meets the rules will no longer completely rely on the choice of a specific Builder: even if the current Builder is unwilling to process it, other validators can still establish a protocol-level inclusion requirement through the inclusion list;
• 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 continue to compete around arbitrage and liquidation, but their power to decide "who is qualified to enter the market" will be limited;

Moreover, Ethereum's trusted neutrality may gradually shift from a value proposition relying on participants' commitments to a protocol rule automatically enforced by clients.

Users do not need to know which Builder produced the current block, nor do they need to trust that these Builders will actively remain neutral; validating nodes will check blocks according to the same rules, making it difficult for blocks that violate the inclusion obligation to gain network recognition.

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

A transaction will no longer just vaguely show "pending," but may further inform users whether it has entered the inclusion list, whether it has obtained the inclusion obligations of subsequent blocks, and whether the continued waiting is due to insufficient Gas, the transaction already being invalid, or anomalies in the block construction process.

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

Transactions with insufficient balances, nonce conflicts, low gas prices, or execution conditions that have already become invalid may still fail to enter a block. When the network is congested and block space is limited, users will still need to wait for confirmation through fee competition.

But mainly, it improves the situation where a valid transaction, reasonably priced and already propagated to the public transaction pool, should not be indefinitely delayed due to the subjective choices of a few block builders.

In terms of progress, as of August 2026, the EIP-7805 corresponding to FOCIL is still in Draft status, but it has already been chosen by Ethereum core developers as a consensus layer Headliner for the Hegotá upgrade and has entered the Scheduled for Inclusion phase, meaning the client team has agreed to push forward implementation and develop network testing around it, although the exact mainnet launch time has not yet been finalized.

FairFIL is even earlier; currently, it is mainly a research proposal released in July 2026, and whether it will enter Ethereum's roadmap will require broader discussions, implementations, and security validations.

Final Thoughts

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

Participants may be subject to regulatory pressures, pursue their own interests, or accept external incentives—a truly resilient decentralized network cannot be built on the ideal assumption that "everyone will do the right thing."

True anti-censorship means that even if some participants attempt to interfere with transactions, other participants still have the capability to break through that control; even if someone chooses to deviate from the principle of neutrality, the protocol can make this behavior visible, costly, and difficult to sustain.

From the initial inclusion list, to the FOCIL that constrains Builders through a distributed committee, and to FairFIL, which requires omitted behaviors to be publicly verifiable, from allowing anyone to send transactions to ensuring everyone’s transactions have a chance to be seen.

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

It is worth looking forward to.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。