核心观点是：虽然 ePBS（执行提议者-构建者分离）解决了质押中心化的问题，但我们现在必须通过分层方案来解决构建者中心化和有害 MEV 的问题：
1. 引入 FOCIL（强制包含列表）：通过让验证者强制包含交易，从根本上解决审查问题。
2. 加密内存池：通过隐藏交易内容，防止抢跑和三明治攻击。
3. 网络层匿名：通过 Tor 或混合网络等技术，隐藏交易源头，防止 RPC 节点或监视者窥探隐私。
4. 长期愿景：探索“大 FOCIL”或“局部交易”等方案，最终实现无需单一服务器的完全分布式区块构建。
Finally, the block building pipeline.
---------Explain-----
Below origin text provides a high-level roadmap and overview of the challenges and proposed solutions surrounding Ethereum's block building process. It explains how the system is evolving to prevent censorship, reduce centralization, and protect users from harmful MEV (Maximal Extractable Value).
Here is a breakdown of the key concepts and arguments:
1. The Core Problem: Centralization of Power
The text starts with the current state (ePBS in "Glamsterdam"), which allows block proposers to outsource the work of building blocks to specialist "builders."
· The Good: This prevents the power of staking from merging with the power of block building, keeping staking decentralized.
· The Question: But if builders themselves become centralized, what do we do about that? This document explores the next steps.
2. Solution 1: FOCIL (In-Protocol Censorship Resistance)
FOCIL (Forward/Forced Inclusion Lists) is the first major upgrade discussed. It is a mechanism built directly into Ethereum's rules.
· How it works: 16 randomly selected validators (attesters) get to force a few transactions into the block.
· The Result: Even if a single malicious builder controls 100% of block production, they cannot censor specific transactions. The "FOCILers" will push them in. This solves the censorship problem.
3. Solution 2: "Big FOCIL" (The Path to Distributed Building)
This is a speculative extension of FOCIL. If the inclusion lists are big enough to contain all transactions, the role of the central builder shrinks dramatically.
· The Mechanism: To avoid everyone including the same transactions (duplication), each FOCILer is assigned a specific slice of the mempool (e.g., based on the user's address).
· The Endgame: The builder’s role becomes reduced to only handling complex "MEV" transactions (like arbitrage) and ordering the state. This moves Ethereum toward distributed block building.
4. Solution 3: Encrypted Mempools (Fighting "Toxic MEV")
To solve malicious attacks like sandwiching (where bots exploit a user's trade), the text proposes encrypted mempools.
· The Concept: If a transaction is encrypted until it is included in a block, bots cannot see it and cannot wrap it with harmful transactions.
· The Challenge: How do we guarantee the transaction is valid while encrypted? How do we ensure it gets decrypted only after inclusion, and not before? This is a major technical hurdle.
5. Solution 4: The Network Layer (Anonymization)
The text points out that we often ignore the moment a transaction is traveling through the network. If a hostile actor sees it "in the clear" before it's in a block:
· They can sandwich it.
· They can "grief" you by invalidating it.
· RPC providers can spy on your activity even if you use privacy tools on-chain.
The Fix: Anonymizing the network layer itself. This involves routing transactions through privacy networks like Tor, mixnets, or specialized designs like Flashnet to hide who is sending what, right from the start.
6. The Long-Term Dream: Fully Distributed Block Building
The ultimate goal is to make Ethereum function like BitTorrent—able to process massive amounts of data without a single server holding everything.
· The Conflict: Ethereum relies on "synchronous shared state" (every transaction could affect every other), which naturally forces centralization.
· The Speculative Idea: If we accept that 95% of transactions don't need global interaction, we could create new "local" transaction types that are cheaper and can be built in a distributed way, reserving the expensive, global slots for high-value, complex interactions.
Summary
In short, the text argues that while ePBS solved one centralization problem, we must now tackle the remaining issues through a layered approach:
1. FOCIL to stop censorship.
2. Encrypted Mempools to stop frontrunning.
3. Network Anonymization to stop surveillance.
4. Long-term Rearchitecting to truly distribute the building workload.
-----------origin------
In Glamsterdam, Ethereum is getting ePBS, which lets proposers outsource to a free permissionless market of block builders.
This ensures that block builder centralization does not creep into staking centralization, but it leaves the question: what do we do about block builder centralization? And what are the _other_ problems in the block building pipeline that need to be addressed, and how? This has both in-protocol and extra-protocol components.
## FOCIL
FOCIL is the first step into in-protocol multi-participant block building. FOCIL lets 16 randomly-selected attesters each choose a few transactions, which *must* be included somewhere in the block (the block gets rejected otherwise). This means that even if 100% of block building is taken over by one hostile actor, they cannot prevent transactions from being included, because the FOCILers will push them in.
## "Big FOCIL"
This is more speculative, but has been discussed as a possible next step. The idea is to make the FOCILs bigger, so they can include all of the transactions in the block.
We avoid duplication by having the i'th FOCIL'er by default only include (i) txs whose sender address's first hex char is i, and (ii) txs that were around but not included in the previous slot. So at the cost of one slot delay, only censored txs risk duplication.
Taking this to its logical conclusion, the builder's role could become reduced to ONLY including "MEV-relevant" transactions (eg. DEX arbitrage), and computing the state transition.
## Encrypted mempools
Encrypted mempools are one solution being explored to solve "toxic MEV": attacks such as sandwiching and frontrunning, which are exploitative against users. If a transaction is encrypted until it's included, no one gets the opportunity to "wrap" it in a hostile way.
The technical challenge is: how to guarantee validity in a mempool-friendly and inclusion-friendly way that is efficient, and what technique to use to guarantee that the transaction will actually get decrypted once the block is made (and not before).
## The transaction ingress layer
One thing often ignored in discussions of MEV, privacy, and other issues is the network layer: what happens in between a user sending out a transaction, and that transaction making it into a block? There are many risks if a hostile actor sees a tx "in the clear" inflight:
* If it's a defi trade or otherwise MEV-relevant, they can sandwich it
* In many applications, they can prepend some other action which invalidates it, not stealing money, but "griefing" you, causing you to waste time and gas fees
* If you are sending a sensitive tx through a privacy protocol, even if it's all private onchain, if you send it through an RPC, the RPC can see what you did, if you send it through the public mempool, any analytics agency that runs many nodes will see what you did
There has recently been increasing work on network-layer anonymization for transactions: exploring using Tor for routing transactions, ideas around building a custom ethereum-focused mixnet, non-mixnet designs that are more latency-minimized (but bandwidth-heavier, which is ok for transactions as they are tiny) like Flashnet, etc. This is an open design space, I expect the kohaku initiative @ncsgy will be interested in integrating pluggable support for such protocols, like it is for onchain privacy protocols.
There is also room for doing (benign, pro-user) things to transactions before including them onchain; this is very relevant for defi. Basically, we want ideal order-matching, as a passive feature of the network layer without dependence on servers. Of course enabling good uses of this without enabling sandwiching involves cryptography or other security, some important challenges there.
## Long-term distributed block building
There is a dream, that we can make Ethereum truly like BitTorrent: able to process far more transactions than any single server needs to ever coalesce locally. The challenge with this vision is that Ethereum has (and indeed a core value proposition is) synchronous shared state, so any tx could in principle depend on any other tx. This centralizes block building.
"Big FOCIL" handles this partially, and it could be done extra-protocol too, but you still need one central actor to put everything in order and execute it.
We could come up with designs that address this. One idea is to do the same thing that we want to do for state: acknowledge that >95% of Ethereum's activity doesn't really _need_ full globalness, though the 5% that does is often high-value, and create new categories of txs that are less global, and so friendly to fully distributed building, and make them much cheaper, while leaving the current tx types in place but (relatively) more expensive.
This is also an open and exciting long-term future design space.