Vitalik's "Shelter Technology" Declaration: How Does Ethereum Incorporate Censorship Resistance into the Protocol?

ETH0,42%

Written by: imToken

If one day, the core development team of Ethereum were to “disappear” collectively, or if a sovereign nation demanded to censor specific transactions, could Ethereum still remain open?

These questions sound like extreme hypotheticals, but they are increasingly becoming a practical reference point in the design of Ethereum’s protocol.

In early March, Vitalik Buterin proposed a new concept, openly stating that the Ethereum community should see itself as part of an ecosystem of “sanctuary technologies”: these free, open-source tools enable people to live, work, communicate, manage risks, and build wealth, collaborating toward common goals while maximizing resistance to external pressures.

This framing appears to be an abstract upgrade of core values, but when viewed in the context of Ethereum’s recent protocol evolution, it corresponds to very concrete engineering challenges:

As block construction becomes more specialized, transaction ordering power concentrates, and the public mempool becomes more vulnerable to front-running and censorship, how can Ethereum continue to uphold its most fundamental principle of an “open network”—that user transactions should not be easily blocked or excluded by a few?

1. Vitalik Coined a New Term: “Sanctuary Technologies”

Vitalik’s approach this time is marked by rare frankness.

He doesn’t continue with grandiose phrases like “changing the world,” but admits that, so far, Ethereum’s real-world improvements for ordinary people remain limited. For example, on-chain financial efficiency may have improved, and the application ecosystem has become richer, but many achievements still circulate within the crypto world’s internal loop.

Therefore, he proposes a new way to define Ethereum’s role: rather than viewing it solely as a financial network, see it as part of a broader “sanctuary technology” ecosystem.

According to his definition, these technologies typically share several characteristics: they are open-source, free, accessible to anyone; they help people communicate, collaborate, manage risks and wealth; and importantly, they can operate even under government pressure, corporate blockades, or other external interventions.

Vitalik even offers a vivid analogy—true decentralized protocols should be more like a hammer than a subscription service. When you buy a hammer, it’s yours; it won’t suddenly stop working if the manufacturer goes out of business, nor will you see a prompt saying “This feature is unavailable in your region.”

Ultimately, if a technology is to serve as a sanctuary, it cannot rely on a centralized organization’s ongoing existence, nor should it leave users passively dependent on service providers.

Source: CoinDesk

This naturally brings to mind another long-standing Ethereum standard Vitalik has often mentioned for assessing its long-term value: the walkaway test. This test asks a straightforward question: if all core developers disappeared tomorrow, would the protocol still function properly?

This isn’t just a slogan; it’s a strict decentralization standard. It’s not about whether there’s a narrative of decentralization now, but whether the system can withstand the worst-case future.

Applied to block production, the answer becomes very specific: to pass the walkaway test, a blockchain must prevent transaction control from being concentrated in a few hands, and it must ensure that public transaction flow isn’t inherently vulnerable to front-running, censorship, or manipulation.

This is precisely the context behind the discussions of FOCIL and encrypted mempools in Ethereum.

2. Censorship Resistance Returns to Protocol Core: FOCIL + Encrypted Mempools

Let’s carefully analyze the current issues facing Ethereum’s public mempool.

Over the past few years, Ethereum has increasingly specialized in block construction. To improve efficiency and MEV extraction, the role of builders has become more important. Block production is no longer an idealized process where each validator independently constructs blocks; while this has practical benefits, it also has clear costs:

If block construction power becomes concentrated among a few dominant participants, censorship is no longer just a theoretical risk. In theory, any major builder could selectively refuse to include certain transactions, such as transfers from sanctioned Tornado Cash addresses.

In other words, Ethereum today faces a challenge not just about high fees or throughput, but about whether its public transaction infrastructure remains trustworthy for ordinary users.

Therefore, FOCIL (Fork-Choice Enforced Inclusion Lists) is Ethereum’s direct response to censorship concerns at the protocol level. Its core idea is straightforward: by introducing an Inclusion List mechanism, whether a transaction is included in a block no longer depends solely on the proposer or builder’s unilateral decision.

In each slot, an Inclusion List Committee is selected from the validator set. Committee members, based on their view of the mempool, compile a list of transactions to include and broadcast it; the next slot’s proposer must build a block that satisfies these constraints, and attesters will only vote for blocks that meet the list’s criteria.

In other words, FOCIL doesn’t eliminate builders but uses fork-choice rules to provide stronger guarantees that valid transactions in the public mempool will be included. This allows builders to still optimize transaction ordering and MEV strategies, but they no longer have the sole power to decide whether a transaction is eligible for inclusion.

Although controversial, FOCIL has been confirmed as a core proposal for the next major upgrade, Hegotá, with a specification freeze. It is expected to be deployed after the Glamsterdam upgrade, in the second half of 2026.

However, FOCIL doesn’t solve another equally critical issue: before a transaction is actually included in a block, has it already been fully observed by the market? MEV searchers can front-run, sandwich, or reorder transactions based on this knowledge—especially in DeFi, where transactions are most vulnerable. For ordinary users, this means that even if their transactions aren’t censored, they can still be targeted for front-running before they are confirmed.

This is the root cause of sandwich attacks.

The community’s current main solutions include LUCID (proposed by Ethereum Foundation researchers Anders Elowsson, Julian Ma, and Justin Florentine) and EIP-8105 (Universal Enshrined Encrypted Mempool). The EIP-8105 team recently announced full support for LUCID, and both teams are collaborating to push these solutions forward.

The core idea of encrypted mempools is:

  • When users send transactions, the content is encrypted;
  • Transactions are only decrypted after being included in a block and reaching a certain confirmation threshold;
  • Until then, searchers cannot see transaction intent, preventing sandwich or front-running attacks;
  • As a result, the public mempool becomes “secure and usable” again.

As researchers describe, the combination of ePBS (Execution Layer Proposer-Builder Separation), FOCIL, and encrypted mempools forms the “Holy Trinity of Censorship Resistance,” providing a comprehensive systemic defense across the entire transaction supply chain.

Currently, FOCIL has been confirmed for Hegotá; the encrypted mempool solution (LUCID) is actively being promoted as another headline proposal for Hegotá.

3. What Does All This Mean?

Looking at the bigger picture, FOCIL and encrypted mempools are not just new terms in Ethereum’s upgrade list—they signal a shift:

Ethereum is re-centering “censorship resistance” in its protocol design.

Although the blockchain industry often talks about “decentralization,” users only realize its importance when a transaction is censored, blocked, or disappears from the network. At that moment, they understand that decentralization is not a default state but something that must be actively protected through protocol code.

As early as February 20, Vitalik wrote that FOCIL and Ethereum’s account abstraction proposal EIP-8141 (based on 7701) have significant synergy. EIP-8141 elevates smart accounts (including multisigs, quantum-resistant signatures, key management, gas sponsorship, etc.) to “first-class citizens,” meaning operations from these accounts can be directly packaged as on-chain transactions without additional wrapping.

Some may question: does FOCIL add too much complexity? Could encrypted mempools cause efficiency losses? Are these trade-offs worth it?

This is precisely the most noteworthy aspect of “sanctuary technologies”: the true value of blockchain may never be just asset on-chain or transaction speed. Instead, it’s whether, under high-pressure environments, blockchain can continue providing a permissionless, hard-to-shut-down, and resilient digital refuge.

From this perspective, the significance of FOCIL and encrypted mempools is clear: they aim to harden protocol rules, transforming what once relied on good faith, market self-regulation, or “hope nothing goes wrong” into more robust safeguards.

When countless users live, work, communicate, manage risks, and build wealth freely on this “digital safe haven,” without fear of censorship or eviction by centralized entities—then Ethereum will have truly passed the “Walkaway Test.”

And that, ultimately, is the true meaning of sanctuary technology.

View Original
Disclaimer: The information on this page may come from third parties and does not represent the views or opinions of Gate. The content displayed on this page is for reference only and does not constitute any financial, investment, or legal advice. Gate does not guarantee the accuracy or completeness of the information and shall not be liable for any losses arising from the use of this information. Virtual asset investments carry high risks and are subject to significant price volatility. You may lose all of your invested principal. Please fully understand the relevant risks and make prudent decisions based on your own financial situation and risk tolerance. For details, please refer to Disclaimer.
Comment
0/400
No comments