The Holy Trinity of Censorship Resistance in Ethereum

Many thanks to Julian and Marc for their valuable feedback on this post.

Censorship resistance and decentralization have been at the core of the value proposition of public blockchains since Satoshi Nakamoto’s Bitcoin whitepaper, embodying the spirit of open-source software development and privacy-preserving technology. In blockchains, these principles ensure that anyone can freely transact without reliance on intermediaries or exposure to arbitrary restrictions. However, in an era of high-frequency trading bots, AI-driven strategies, and speculative memecoin frenzies, these foundational values are often overlooked.

This is especially concerning as Ethereum is positioning itself more and more as a global settlement layer for real-world use cases. With the increasing volume of stablecoin transactions and Real World Assets (RWA’s), it will become more clear that robust, neutral trading infrastructure is Ethereum’s unique selling point compared to other, more centralized blockchains and centralized trading and settlement infrastructure. Thus, censorship resistance will be even more paramount than it is today.

Censorship in Ethereum primarily takes one of two forms: real-time and long-term. Real-time censorship refers to the immediate but temporary exclusion of transactions as they are broadcast to the network, which can be an issue for time-sensitive operations. Long-term censorship, on the other hand, involves the ongoing exclusion of certain transactions over an extended period, performed by colluding validators and attesters.

For a long time, both forms of censorship were viewed as a theoretical concern rather than a tangible issue. In fact, Vitalik highlights in one of his blog posts that even if a transaction is censored in 88% of all blocks in Ethereum, it still manages to be included within an average of 114 seconds. This demonstrates Ethereum provides a reasonable degree of long-term censorship resistance. However, the situation is different for real-time censorship: While a delay of a few seconds may seem insignificant for some applications, Vitalik correctly points out that it becomes a critical bottleneck for DeFi users engaged in arbitrage, liquidations, or other time-sensitive financial operations.

The case of Soneium provides additional concrete evidence that negative fallout from real-time censorship is no longer a theoretical concern: The L2 solution developed by a Sony subsidiary actively excluded transactions, leading to measurable financial harm for users who relied on timely execution (read more). 

The State of Censorship in Ethereum in 2025 - A Grim Outlook

In today’s Ethereum, centralization and trust assumptions present significant challenges. In the PBS (Proposer-Builder Separation) supply chain, censorship can occur at various stages, including at the relay, builder, and proposer levels. One of the most pressing issues is the increasing centralization of block builders: as of now, just two builders are responsible for producing around 80% of all blocks. This concentration of power in the supply chain could undermine the very principles of fairness and decentralization that blockchain systems aim to achieve. Ultimately, for use cases that do not require censorship resistance, a centralized database or settlement layer is likely a more suitable and efficient choice than Ethereum.

So what can we do about it?

If you’ve been in the space long enough, this will all sound like a broken record to you, and indeed, several solutions to the centralization issue have been proposed over the years, including decentralized block building, inclusion lists, and encrypted mempools. However, very little has been achieved and the ideal practical solution has always looked fuzzy and fragmented. But here’s the good news: A combination of the above solutions is emerging as a promising approach to achieve a much higher level of censorship resistance. This strategy—coined the "Holy Trinity of Censorship Resistance" by Marc Harvey-Hill from Nethermind—combines three key technologies: enshrined PBS (ePBS), FOCIL (Fork-Choice enforced Inclusion List), and encrypted mempools.

At a high level, what should this combination enable? Any user should be able to submit a transaction and have the following guarantees, regardless of who the user is and what type of transaction it sends: 

1. The transaction will be included within a predefined time-bound.
2. No one will see the content of the transaction before inclusion is guaranteed.
3. The user will be the first to benefit from their own trade.
4. The transaction flow does not rely on the mercy of trusted intermediaries.

In other words, users should be able to safely reveal information to the chain and get their transactions included quickly without relying on trusted intermediaries—something that is currently far from guaranteed.

The Three Pillars of Censorship Resistance

1. Enshrined PBS (ePBS): Eliminating Trusted Relays

Out-of-protocol PBS relies on relays, which act as trusted intermediaries between proposers and builders, eliminating the need for direct trust between them. At a high level, relays receive blocks from builders and forward the headers to the proposer. Once the proposer replies with a signature for one of the headers, the relay publishes the respective block along with the proposer’s signature. This role grants relays significant power over transaction inclusion, making them potential points of censorship. Enshrined PBS is a design proposal that directly implements PBS in the consensus layer of Ethereum, removing the need for external relays and reducing reliance on off-chain coordination. At a high level, this is done as follows: the builder sends a hash of its block payload to the proposer, upon which the proposer creates a beacon block that references this hash. Once this beacon block receives sufficiently many attestations, the builder releases the block payload, and a committee of validators votes on whether or not the payload was released on time.

While ePBS is a promising approach to eliminate reliance on trusted relays, it does not address builder centralization. Large builders may still dominate the block-building process, extracting malicious MEV or censoring transactions. To deal with those issues, we need the following two components.

2. Fork-Choice enforced Inclusion List (FOCIL): The Watchdog Against Censorship

A recent proposal introduced the concept of a Fork-Choice enforced Inclusion List (FOCIL), which acts as a countermeasure against censorship. In FOCIL, a set of validators is selected per slot into the so-called Inclusion List (IL) committee, which jointly computes an inclusion list. The next proposed block should then include all transactions specified in the inclusion list.FOCIL essentially works as follows: once the IL committee is selected, each member of the committee prepares a list of transactions from the public mempool and sends it to the network. The block proposer of the slot merges all lists into one and ensures that all transactions of the merged list are included in the block. Attesters then only attest the block if all transactions of the ILs are indeed included. This ensures that censored transactions have a guaranteed path to inclusion in the blockchain, provided that there is at least one honest member in the IL commitee. This serves as a powerful defense against transaction suppression by centralized builders.

3. Encrypted Mempools: Leveling the Playing Field

Vitalik has highlighted encrypted mempools as a crucial technology for implementing various censorship resistance mechanisms. By encrypting transactions before they enter the mempool and by fixing the position of encrypted transactions at the top of the block before decrypting, they prevent front-running and malicious MEV extraction. This protects users from unfair advantages taken by sophisticated actors—such as builders and validators—and effectively reduces opportunities for selective inclusion or exclusion of transactions, creating a more equitable and censorship-resistant network.An encrypted mempool is established by a service provider that provides public information necessary to encrypt transactions and eventually releases the required information to decrypt these transactions. Several technologies are being discussed in the community to establish an encrypted mempool including threshold encryption, Trusted Execution Environments, or delay encryption.

Recently, there has been growing interest in the design of encrypted mempools. We recently proposed a practical roadmap for a threshold encrypted mempool on Ethereum L1, leveraging Shutter and proposer commitments to make this system viable within Ethereum’s current architecture. We also implemented a Shutter encrypted mempool on the Gnosis Chain.Additionally, other notable proposals have emerged:

• Marc Harvey-Hill from Nethermind has explored encrypted mempools using smart accounts.
• Anders Elowsson from the Ethereum Foundation proposed a design where users commit and later reveal their own transactions.

How These Components Work Together 

The good news is that the three components above integrate well with each other, thereby paving the way to return to a decentralized and censorship-resistant Ethereum. In the following, we outline the potential transaction flow in a network that implements ePBS, FOCIL, and an encrypted mempool:

1. Users submit encrypted transactions using a public encryption key provided by the encrypted mempool service provider.
2. An IL committee observes the public mempool, and each member of the committee builds an inclusion list for encrypted transactions.
3. The block proposer merges the ILs into one list of encrypted transactions. This essentially forces the builder, who holds the block execution ticket under ePBS, to include these encrypted transactions in the next block. If the builder omits them even though there is enough gas left to include them, the block is considered invalid.

4. The decryption material for the encrypted transactions is released by the encrypted mempool service provider. Attesters commit to having seen the decryption material, requiring a supermajority of at least two-thirds. If the decryption material does not receive sufficient attestations, the encrypted transactions are included in the IL of the next slot and do not need to be included in the current block.
5. The builder decrypts the transactions in the block and must include the decrypted transactions at the top of the block so as to prevent malicious MEV attacks.
6. The builder then sends the block to the proposer via the ePBS flow as described above. If the proposed block does not include the transactions from the IL—despite the decryption material being attested and sufficient gas remaining—the block proposer risks slashing or having their block made invalid.

Result

The combination of ePBS, FOCIL, and encrypted mempools has the potential to fundamentally reshape Ethereum’s transaction layer by eliminating relays, enforcing timely transaction inclusion, and neutralizing malicious MEV. 

In contrast to the current system, where builder centralization, trusted relays, MEV extraction, and selective censorship undermine Ethereum’s core values, this approach restores Ethereum’s credible neutrality, ensuring that the network remains open, fair, and resilient against manipulation.

Open Questions

While the Holy Trinity presents a powerful solution for Ethereum’s centralization and censorship problem, a few challenges remain to be solved:

• Openness of Encryption Technology: Can we build a generalized encryption interface that allows the use of any encryption/decryption mechanism? This would allow us to abstract the exact encryption type and leave that choice up to the provider of the encrypted mempool.
• Ensuring Decryption for Pending Transactions: When encryption parameters change, e.g., due to committee rotation, periodic key updates, or a transition to a new cryptographic scheme, pending transactions encrypted under the old system must still be decryptable. How can we ensure that?
• Best Encryption Type: Which type of encryption mechanism offers the best liveness and security guarantees under the most reasonable assumptions? 
• In-Protocol vs Out-of-Protocol: In how far should the three techniques (ePBS, FOCIL, encrypted mempools) be enshrined into the Ethereum protocol, and in how far should they operate on the application layer?
• Inclusion Enforcement: What is the best measure to enforce the inclusion of transactions from the IL? 

Conclusion

Ethereum faces a growing censorship problem that threatens its core principles of decentralization and neutrality. The Holy Trinity of Censorship Resistance, consisting of ePBS, FOCIL and encrypted mempools, presents a comprehensive solution that could restore Ethereum's foundational values. As the network continues to evolve toward becoming a global settlement layer, implementing these measures will be crucial to ensuring that Ethereum remains true to the vision outlined in its whitepaper: a credibly neutral, decentralized platform accessible to all.