In the world of blockchain, we often hear a term: 'censorship resistance'.
Many people's first reaction might make it sound like a political, or even somewhat anarchistic, slogan. But for a global settlement network like Ethereum open to users worldwide, censorship resistance is not primarily a political stance, but a very specific technical capability.
Imagine you initiate a transaction in your imToken wallet.
The signature is correct, the account balance is sufficient, the Gas fee is not low, but the transaction remains unwritten into a block. The wallet status stays 'Pending', while other transactions with similar or even lower fees keep getting on-chain.
At this point, the question becomes: Who actually has the authority to decide if a transaction can enter a block? After all, if Ethereum ultimately still relies on a few centralized participants to decide which transactions can be on-chained, then there is no fundamental difference between it and the traditional financial system.
Therefore, Ethereum has been exploring a series of anti-censorship mechanisms like FOCIL and FairFIL in recent years, trying to answer a seemingly simple but actually crucial question: How can we ensure any transaction that conforms to the protocol rules has a fair chance to enter a block?
1. Where Does 'Censorship' Actually Come From?
To understand why Ethereum needs these mechanisms, we first need to clarify what happens to a transaction after it is sent from a wallet.
When a user signs and sends a transaction in a wallet, it usually first enters Ethereum's public transaction pool, known as the Mempool, which acts more like a waiting area holding numerous transactions not yet written into blocks.
But entering the waiting area doesn't mean the transaction is on-chain. Someone still needs to select transactions from it, decide their order, assemble them into a complete block, and then submit it for network confirmation.
This is precisely where the problem arises.
After Ethereum upgraded to the PoS (Proof of Stake) mechanism, to prevent large staking pools from forming an economic monopoly using MEV (Maximal Extractable Value), Ethereum introduced the PBS (Proposer-Builder Separation) framework. Under this architecture, the processing flow for each Ethereum transaction is essentially split between two roles:
- Builder: Responsible for collecting transactions, ordering them, searching for 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 proposing it to the network.
This division of labor has very practical benefits.
As is well known, MEV strategies have become increasingly complex in recent years. If every ordinary validator were required to independently handle transaction ordering and block optimization, it would undoubtedly give an advantage to larger nodes with more capital, data, and technical capabilities.
Therefore, by outsourcing the complex block-building work to professional Builders, ordinary validating nodes, even without advanced arbitrage capabilities, can participate in block proposal and receive corresponding rewards, thereby mitigating the impact of MEV on staking decentralization.
However, it inadvertently brought another side effect: excessive centralization of block-building power. For instance, currently over 90% of Ethereum blocks are produced by only a handful of professional Builders. Moreover, since these Builders often have clear real-world operational backgrounds, they are highly susceptible to external pressure from specific national or regional legal compliance requirements (e.g., OFAC sanction lists), thus constituting a real centralization risk.
For this reason, if these few mainstream Builders selectively filter out transactions from certain sensitive contracts (like Tornado Cash) or specific addresses, these transactions can become stuck, facing prolonged difficulty getting packaged, or even risk 'implicit banning'.
In summary, from an ordinary user's perspective, Ethereum is an open network that anyone can connect to, transfer assets on, and call smart contracts. But from the perspective of protocol operation, sending a transaction is only the first step. Whether the transaction truly takes effect depends on whether it is selected, ordered, and written into a block by a block Builder.
Therefore, the 'censorship resistance' discussed by Ethereum is not just a grand concept related to politics, regulation, or sanctions; it is first and foremost a very specific technical problem:
When a transaction satisfies the protocol rules, can the network guarantee it has an opportunity to enter a block within a reasonable time frame?
2. From FOCIL to FairFIL: How Ethereum Aims to Constrain Block Builders
Actually, at this point, the problem is quite clear. Builders can improve block construction efficiency, but if the power over transaction inclusion remains concentrated in the hands of a few Builders long-term, Ethereum risks forming new centralization and monopoly.
To address this, Ethereum researchers proposed Inclusion Lists.
The name sounds a bit abstract, but its core logic is not complex – Builders are still responsible for producing blocks, but they cannot solely decide the fate of all transactions. Validating nodes participating normally in Ethereum staking also retain a portion of power, allowing them to list some transactions that must be processed.
Using a bus station as an analogy, a block can be understood as a bus with limited seats.
The Builder decides how most passengers line up and where they sit, thereby increasing the overall revenue of the bus trip through more efficient arrangements. However, validating nodes can also submit a 'Must-Board List'. As long as the transactions on this list are still valid, willing to pay a reasonable fee, and the block has sufficient space, the Builder cannot keep them out solely based on its own preference.
However, who exactly creates an inclusion list, and what happens if someone deliberately omits a transaction, are two problems that still need solving.
FOCIL and FairFIL are explorations in 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 which transactions must be included from a single Proposer to a 'Validator Committee' composed of multiple parties.
During each block slot, 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 globally attempt to censor a particular transaction, as long as there is 1 honest node in the committee that puts that transaction on its list, the transaction has a chance to become protocol-enforced. Anyone trying to continue excluding it would no longer just need to bypass one person, but several independent participants simultaneously.
So its advantage lies in not needing to trust that every single person on the committee will remain neutral.
But having a list is not enough. If a Builder receives the list and still chooses not to comply, the inclusion list becomes just an unenforceable suggestion.
Therefore, FOCIL adds a second layer of design: it introduces a Fork-Choice Rule for hard enforcement, requiring all validating nodes responsible for voting across the network to strictly check the block submitted by the Builder. Once it is discovered that a Builder dares to violate the committee's aggregated inclusion list, the entire network will directly refuse to vote for that block.
This means the offending block would be instantly judged invalid by the protocol, and the Builder would pay a huge price for the failed block.
2. FairFIL: Not Just Plugging Gaps, But Making Omissions Verifiable
If FOCIL is about hard-prohibiting censorship via consensus rules, then FairFIL (Fair Forward Inclusion Lists) and accountability mechanisms approach it from an economic angle, making censoring behavior extremely costly and unsustainable.
Put simply, it makes a further demand: for example, there should be a publicly verifiable record explaining why a transaction did not enter a block, whenever possible.
In actual network operation, a Builder might need a very short buffer period to optimize transaction ordering and MEV arbitrage. FairFIL allows Builders some flexibility under specific constraints. However, if a Builder attempts to extend a censoring behavior to the next block, the protocol immediately initiates an accountability procedure.
Its general logic can be understood in three steps.
- First, the protocol sets a publicly verifiable reference rule to determine which transactions in the public Mempool are normally qualified to enter the current block. If certain transactions that were qualified according to the reference rule ultimately were not processed, the Builder needs to publicly list them in the FairFIL.
- Subsequently, validators check if this list is complete. If the Builder clearly omitted a qualified transaction but did not include it in the list, this behavior may be detected and influence whether validating nodes support that block.
- Finally, valid transactions entered into the FairFIL become prioritized tasks for subsequent blocks to handle. The next Builder can still arrange their specific position within the block but cannot continue to pretend not to see them.
If a transaction is repeatedly omitted, the related blocks may lose validator support, and the Builder may also lose the entire block's reward as a result.
In other words, the 'accountability' emphasized by FairFIL is essentially introducing graduated economic penalties. A Builder persistently censoring transactions will face the risk of losing the entire block reward or even having its staked deposit slashed.
This is also the direction Ethereum's anti-censorship mechanisms are progressively deepening towards: aiming to establish a set of realistic constraints. Even if a few participants have censoring intentions, it becomes very difficult to control the transaction gateway long-term; even if someone deliberately omits a transaction, they need to leave a trace and pay an increasingly higher price for persistent censorship.
3. What Does This Mean for Ordinary Users?
For ordinary users who transfer, swap, or use DeFi through their wallets daily, even if these underlying mechanisms are implemented in the future, there's no need to change existing operational habits.
Users still fill in amounts, confirm Gas, sign, and then wait for the transaction to go on-chain in their wallets. However, in the invisible protocol layer, the logic determining whether a transaction can enter a block may undergo significant changes.
What it truly improves is the certainty of the transaction inclusion process.
- First, a rule-compliant transaction will no longer depend entirely on the choice of a specific Builder: Even if the current Builder is unwilling to process it, other validators can establish a protocol-level inclusion requirement for it via the inclusion list.
- Second, transaction inclusion rights and transaction ordering rights may gradually separate: Builders can still use professional algorithms to arrange transaction order and increase block revenue, and they can still compete around arbitrage and liquidation. But their power to decide 'who is eligible to enter the market' will be constrained.
Looking further, Ethereum's credible neutrality may gradually evolve from a value proposition reliant on participants' promises into protocol rules automatically enforced by clients.
Users won't need to know which Builder constructed the current block, nor individually trust these Builders to actively remain neutral. Validating nodes will check blocks according to the same set of rules, making blocks that violate inclusion obligations difficult to gain network acceptance.
In the future, wallets and block explorers might even provide more detailed transaction status based on this.
A transaction might no longer simply show 'Pending', but could further inform the user whether it has entered an inclusion list, whether it has acquired inclusion obligations for subsequent blocks, and whether the continued wait is due to insufficient Gas, the transaction already being invalid, or an anomaly in the block-building process.
However, anti-censorship mechanisms do not mean every transaction will succeed immediately.
Transactions with insufficient balance, Nonce conflicts, too low Gas, or whose contract execution conditions have already failed may still be unable to enter a block. When the network is congested and block space is insufficient, users will still need to compete via fees and wait for confirmation.
But the main improvement is that a transaction that is originally valid, has reasonable fees, and has propagated to the public Mempool should not be indefinitely delayed due to the subjective choice of a few block Builders.
In terms of progress, as of August 2026, the EIP-7805 corresponding to FOCIL is still in Draft status. However, it has been selected by Ethereum core developers as a consensus-layer Headliner for the Hegotá upgrade and entered the 'Scheduled for Inclusion' stage, meaning client teams have agreed to proceed with implementation and development network testing around it, but the specific mainnet launch timeline is not yet finalized.
FairFIL is even earlier, currently mainly a research proposal published in July 2026. Whether it enters the Ethereum roadmap in the future still requires broader discussion, implementation, and security verification.
In Conclusion
Objectively speaking, Ethereum cannot guarantee that every Builder, validator, and infrastructure operator will remain neutral forever.
Participants may be subject to regulatory pressure, may chase their own interests, or 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 is when, 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 neutrality principles, the protocol can make that behavior visible, expensive, and difficult to sustain.
From the initial inclusion lists, to FOCIL which collectively constrains Builders via a distributed committee, to FairFIL which demands that omissions be publicly verifiable—from allowing anyone to send a transaction, to guaranteeing anyone's transaction has a chance to be seen.
From this perspective, Ethereum is indeed trying to write this commitment, step by step, from a value statement into the protocol itself.
Worth looking forward to.
