Futures of Ethereum II - Censorship Resistance

This piece on the Futures of Ethereum explores its ongoing fight for censorship resistance, examining the impact of regulatory pressure, the role of Proposer-Builder Separation (PBS), and potential solutions like encrypted mempools to keep the network neutral and decentralized. Ethereum has adopted the PBS structure to mitigate the centralization risks of MEV profits. In this system, block proposers (regular validator nodes) delegate block construction to specialized builders, who optimize transaction ordering to maximize MEV extraction. The proposer then selects and signs the most profitable block before broadcasting it to the network. MEV-Boost, an off-chain block auction mechanism, is widely used in Ethereum today to facilitate this process. MEV-Boost allows specialized builders to submit bids to proposers, competing to have their blocks included. While Ethereum's validator set remains highly decentralized, building a block—especially one optimized for MEV—is complex and resource-intensive. Given this high computational and infrastructural burden, it is more efficient to centralize block construction while keeping block attestation decentralized. This is the core principle of PBS: it fairly distributes a portion of MEV profits to validators by the auction happening every block, while ensuring that general validators (including home stakers) are not burdened with the complexities of block construction. By isolating this specialized role, PBS preserves the decentralization of the Ethereum network as a whole while optimizing the efficiency of block production. However, since successful builders require significant resources and privileged transaction flow, only a handful consistently win auctions. Some builders maintain dominance by establishing exclusive deals with specific wallets, dApps, and order flow providers, ensuring access to high-MEV transactions that give them a competitive edge in block auctions. As a result, competition among builders diminishes over time, leading to an oligopolistic structure. Today, approximately 90% of Ethereum blocks are built through MEV-Boost, with just two entities—Beaverbuild and Titan Builder—constructing 95% of these blocks. This concentration raises concerns about censorship resistance, transaction fairness, and the long-term decentralization of Ethereum's block production. Although disruptions or malicious behavior by these builders do not significantly affect the safety of the Ethereum network, they pose a serious threat to censorship resistance. If all MEV-Boost builders decide to censor transactions from specific users, those users will only be able to send transactions through blocks produced by validators not using MEV-Boost, which is about 10% of the total. As a result, processing such transactions would take an average of 10 blocks (approximately 2 minutes). This situation raises two major issues: Regulatory vulnerabilities First, it could make Ethereum more vulnerable to regulations. For instance, the Tornado Cash sanctions imposed by OFAC in 2022 led to a significant number of builders and validators censoring transactions associated with OFAC-sanctioned accounts. Unfair competition in protocols like auctions Second, censorship can distort the outcomes of on-chain auctions. For example, consider an auction where one NFT is sold to the highest bidder every block. A block builder could censor all other bids while placing a very low bid, allowing them to acquire the NFT at a significantly reduced price. Various solutions have emerged to address these problems. This post will explore these solutions in two main categories and discuss what form censorship resistance might take in Ethereum’s future. Possible solution 1: Inclusion List Background: Initial Inclusion List Proposal, EIP-7547 The Inclusion List is a censorship-resistance solution that ensures certain transactions are included in a block. It can typically be implemented as follows: Here's a simple mental model: before a builder constructs a block, the proposer sends an order with an 'Inclusion List' stating, "Include these transactions in the block." Builders must include these transactions in the block they create, and if a block is built without the transactions in the Inclusion List, it is considered invalid. For Ethereum before PBS, the mempool, where transactions are held before being entered into blocks, was included in Ethereum as a non-consensus component. Therefore, from the perspective of the Ethereum consensus layer, it was not known where the transactions contained in the blocks came from. One of the main reasons why MEV led to censorship is that mempool is a non-consensus component, so the builders who created the block had complete authority over which transactions to censor or include in the block. Inclusion lists introduce a mechanism that uses multiple validators to act as an 'on-chain mempool' on the consensus layer. In this way, the consensus layer sufficiently constrains the builders' authority to select transactions to provide censorship resistance. One of the most prominent proposals for implementing an Inclusion List was EIP-7547, Forward Inclusion List. This proposal allowed a proposer to include up to 16 transactions in the Inclusion List. The "forwarding" mechanism ensured that the Inclusion List proposed for block N would be applied to block N+1. This proposal was initially intended to be part of Ethereum's Pectra upgrade, but it was eventually excluded, and one reason was compatibility issues between the forwarding mechanism and EIP-3074. EIP-3074 introduces a form of Native Account Abstraction that uses an opcode called AUTHCALL, enabling one account to adjust the balances of multiple EOAs (Externally Owned Accounts). This mechanism can easily undermine the Inclusion List. For example, suppose Alice includes a transaction (A) in the Inclusion List, where her EOA sends ETH to Bob. At the same time, she creates another transaction (B) using EIP-3074's AUTHCALL to transfer all her EOA's balances to a different account. Let's assume transaction B is included in block N, while transaction A is included in the Inclusion List for block N+1. Here's the key issue: when the proposer creates the Inclusion List, they do not know what transactions the builder will include in the current block. In this scenario, transaction B in block N makes transaction A invalid. Consequently, the builder for block N+1 would be unable to construct a valid block due to the invalidity of transaction A in the Inclusion List. Attempts have been made to resolve this issue through additional constraints within the Inclusion List. However, the core issue remains: EIP-3074 inherently allows for manipulating balances in other EOAs. Simple checks, such as verifying the "From" address, cannot detect interference between Inclusion List transactions and other transactions. This is called the free data availability problem, mentioned in the article 'No Free Lunch - a new inclusion list design.' Although EIP-3074 was excluded from the Pectra upgrade, a similar functionality—EIP-7702—was included. As a result, these issues must be resolved before EIP-7547 can be implemented on the Ethereum mainnet. Moreover, EIP-7547 faced additional challenges, such as the limitation that only one proposer could create an Inclusion List per block. These factors made it difficult to apply EIP-7547 to the Ethereum mainnet as-is. Consequently, EIP-7547 was excluded from the Pectra upgrade. FOCIL Is there no solution to these issues? Recently, a solution called FOCIL (Fork-choice enforced Inclusion Lists) has gained significant attention within the Ethereum ecosystem and is considered one of the most likely solutions to be implemented on the Ethereum mainnet. Proposed as EIP-7805, FOCIL introduces a mechanism where not just one but multiple entities propose Inclusion Lists. Its details and characteristics are as follows: At its core, FOCIL adopts the Inclusion List concept, meaning that someone creates a list of transactions that must be included in every block, and proposers are required to incorporate them. However, FOCIL differs from EIP-7547 in two significant ways: Instead of one proposer, an IL committee of 16 members independently proposes Inclusion Lists. The Inclusion List proposed for block N is included in block N itself, not block N+1. Mechanism details The construction of the Inclusion List for block N begins when the slot for block N-1 starts. A randomly selected IL committee of 16 validators receives block N-1, sets it as their head, builds their respective Inclusion Lists, and propagates these through peer-to-peer. The construction process ends 9 seconds into the 12-second N-1 slot, after which the committee can no longer add to the list. Having received these lists via the P2P network, the builder for block N must include them while constructing the block. Shortly after the start of the N slot, the block is delivered to the proposer. Validators verifying block N compare the transactions in the Inclusion Lists they received earlier with those included in block N to ensure compliance. Advantages of FOCIL over EIP-7547 Compared to the previously proposed EIP-7547, FOCIL offers the following benefits: Higher resistance to censorship Each slot involves an IL committee of 16 validators constructing the Inclusion List. This provides stronger resistance to censorship than EIP-7547, where only a single validator was responsible. Seamless implementation By utilizing the standard API forkChoiceUpdate used by consensus clients, Inclusion Lists can be more easily and seamlessly integrated into the protocol. “Real-time” censorship resistance Unlike EIP-7547, where the Inclusion List proposed for block N+1 causes a delay, FOCIL includes the IL in the block proposed for N itself, allowing transactions to be incorporated without delay. This simultaneous construction of blocks and Inclusion Lists ensures compatibility with previously proposed account abstraction mechanisms like EIP-3074 or EIP-7702. Prior blocks cannot invalidate transactions in the Inclusion List. Builders receive the IL before finalizing block construction, enabling them to exclude any transactions that would render the IL invalid. This process is straightforward: builders record the nonce and balance of all EOAs involved in the IL and update these values whenever changes occur. This simple method allows builders to verify the validity of IL transactions and complete block construction successfully. Role of FOCIL in blocks FOCIL allows for up to 16 Inclusion Lists per block, with each list limited to a maximum size of 8KB (8192 bytes). If there is no overlap in the transactions proposed by the 16 Inclusion Lists, the maximum size of IL transactions in a single block could reach 128KB. This limitation is designed to minimize resource usage for validators as Inclusion Lists propagate through the P2P network. So, how much of an Ethereum block could be built using ILs under FOCIL? Historically, the average Ethereum block size has been around 80–100KB, with a maximum of approximately 300KB. If there is no overlap in the transactions proposed by the 16 Inclusion Lists, it is theoretically possible to construct an entire Ethereum block using only IL transactions. However, this scenario is unlikely. Since transactions in the Inclusion List are generally sourced from the public mempool, there is a high probability of overlap unless the 16 IL committee members use entirely different configurations. In summary, transactions in FOCIL's Inclusion Lists are expected to occupy between 6–10% and up to 100% of an Ethereum block, with cases leaning closer to the 6-10% range provided the IL committee members are looking at the same public mempool. Beyond FOCIL: Combining APS with FOCIL Background of APS One reason FOCIL has become a leading solution is its potential synergy with Attester-Proposer Separation (APS) proposals like Execution Tickets. What is APS, and how does it complement FOCIL? APS proposes separating the roles of the proposer and attester for blocks. In Ethereum, block building under PBS involves splitting the roles between proposers, who propose blocks, and builders, who construct block contents. This prevents centralized staking pools formed by proposer-builder alliances from monopolizing MEV profits and recording much higher APR than regular validators, which could centralize validator operations. This issue was resolved through MEV-Boost, and an in-protocol relay system (ePBS) has been proposed to address remaining centralization concerns. However, is PBS truly the optimal structure? One critical role of Ethereum's consensus layer is distributing rewards and imposing penalties on validators. If this process becomes centralized, the chain will be affected by centralized entities, regardless of validator votes. So, the consensus layer should remain highly decentralized. The execution layer, however, does not have the same constraints. Tasks like MEV extraction and transaction ordering are inherently complex and strategic, necessitating centralized entities. If these tasks were imposed on all validators, it would drive the chain towards centralization. In this regard, Ethereum's philosophy is that 'consensus participants should not be incentivized to pursue complex tasks for individual profit.' Through PBS, Ethereum separates validators from MEV actors (builders, searchers) to distribute MEV profits evenly across the entire network. Still, proposers can employ unconventional strategies to gain additional profits: Collusion between proposers and builders Builders are already centralized, but proposers also exhibit some centralization. For instance, Coinbase holds approximately 10% of the total staked ETH. If Coinbase colluded with a specific builder to accept only its blocks, this would introduce a significant centralization vector into the ecosystem. Proposer timing games Ethereum’s relatively long 12-second block time introduces an interesting dynamic called timing games, where proposers delay block publication to maximize MEV profits. The MEV available in a block generally increases linearly over time. Proposers can delay block propagation to maximize their MEV, publishing just before they risk rejection by the next proposer. So, how much can a proposer delay block publication within a single slot (12 seconds)? According to Ethereum's protocol specifications, for the next proposer to consider the previous block valid, the block must receive votes from 40% of the validators (attesters) assigned to the previous slot's committee. On the current Ethereum mainnet, the point at which 40% of validator votes are received occurs approximately 3.8 seconds into the slot. A proposer attempting to play timing games would adopt a strategy of delaying block publication as much as possible, waiting until just enough votes (40% or more) are received to avoid rejection by the next proposer. However, the outcome does not always align with the proposer's intentions. If the block fails to receive 40% of the votes, the next proposer will reject it. In such cases, validators who voted for the rejected block will have voted for a block not part of the canonical chain, resulting in slashing penalties. If this situation persists, validators may delay their votes to observe the network's state and ensure their votes are accurate. This behavior can increase the number of reorgs in the chain. In summary, proposer timing games can negatively affect Ethereum's consensus outcomes and must be prevented. Role of APS APS is the solution designed to address this issue. APS proposes creating a separate proposer for the execution layer, completely separating the consensus layer from MEV. For example, one of the representative APS proposals, Execution Ticket, introduces an "execution proposer" distinct from the beacon chain proposer. In this system, the protocol generates and sells execution tickets, which grant their holders the right to be randomly selected as execution proposers for each block. These execution proposers will take on the parts of the role currently performed by beacon chain proposers in MEV-Boost, receiving execution payloads and proposing them. The rationale behind this design is that centralization of execution proposers is not problematic; in fact, separating them from the consensus layer improves the overall system. Then, what tasks would the beacon chain proposer handle under APS? Apart from managing validator deposits, rewards, and penalties (state transitions within the beacon chain), the consensus layer proposer has an additional key role in APS: constructing Inclusion Lists and passing them to the execution layer. It is more desirable for the Inclusion List to rely on the consensus layer's decentralized validator set rather than the relatively more centralized execution proposers. This helps reduce the likelihood of censorship attackers colluding with proposers to censor transactions. Thus, APS proposals like Execution Ticket suggest a mechanism where the consensus layer validators construct Inclusion Lists as part of the beacon block. These lists then serve as the foundation for the execution proposer to build and propose the full block. In summary, Inclusion List-based censorship resistance solutions align seamlessly with Ethereum's vision for APS. Consequently, FOCIL is considered one of the most promising solutions for censorship resistance. Advantages of FOCIL FOCIL ensures effective censorship resistance while maintaining network resource usage at reasonable levels by limiting each IL to 8KB and having an IL committee of 16 validators (which is the same as the size of one blob). The chart below illustrates how long it takes for a transaction to be included in the chain, depending on the percentage of honest validators in the IL committee. Even if only 15% of validators in the committee are non-censoring, transactions can still be included immediately. This demonstrates how a small committee of 16 validators can achieve efficient censorship resistance. Possible solution 2: Multiple concurrent proposer/builder How about enabling multiple participants to propose an entire block together? This concept is known as "Multiple Concurrent Proposer". Rather than a single entity proposing a block at a time, multiple entities propose blocks simultaneously for the same slot. Under certain conditions, adopting such a solution can significantly increase the cost of censorship. Ethereum has a mechanism where proposers for 32 blocks in each epoch are revealed simultaneously. This setup allows for scenarios where someone could attempt to "bribe" the proposers to censor specific transactions. But what if blocks were proposed not by one person but by N proposers simultaneously? In this scenario, employing a mechanism like conditional tips makes it possible to introduce a "prisoner's dilemma" among the N proposers, thereby drastically increasing the cost of censorship. For example, imagine a situation where N proposers are tasked with creating a block, Alice requests them to include her transaction, and Bob is trying to censor Alice's transaction. Alice can offer a bribe to the proposers for including her transaction, while Bob can also bribe them to censor it. In this situation, Alice can adopt a bribing strategy that effectively increases Bob's cost of censorship, as follows: If two or more proposers include the transaction, Alice gives a small tip of t to each of them. If only one proposer includes the transaction, Alice gives a large tip of T to that proposer. In this case, the proposers find themselves in a "prisoner's dilemma"-like scenario. The optimal strategy for each proposer in this game is to include the transaction rather than censor it. For Bob to successfully censor Alice's transaction, he would need to bribe all N proposers, costing him NT. On the other hand, Alice only needs to spend at most Nt to ensure her transaction is included. This significantly increases the cost of censorship. This concept can be implemented on top of PBS in several ways. For instance, multiple proposers could build blocks simultaneously, or multiple builders could construct blocks concurrently. This section introduces two mechanisms to achieve this within the PBS structure: BRAID - Multiple Concurrent Proposer BuilderNet - Multiple Concurrent Builder BRAID Overview of BRAID BRAID is an Ethereum censorship-resistant solution proposed by Max Resnick, who was part of the Special Mechanism Group. The mechanism is based on a simple yet powerful concept: instead of running a single chain as Ethereum does now, k synchronized LMD-GHOST chains would run in parallel. In other words, with BRAID, k proposers simultaneously produce their own blocks for each slot. How BRAID works An obvious question arises: How are the k blocks processed? Since the blocks must ultimately be consolidated into one to maintain a single blockchain, BRAID uses a predefined ordering rule to merge them. For example, the blocks could be merged by removing duplicates and sorting transactions in descending order of fees. The finalized block would then contain the consolidated, ordered transactions. Advantages & Limitations BRAID offers several advantages: Strong censorship resistance By enabling multiple proposers to work concurrently, BRAID significantly increases the cost of censorship, as multiple entities would need to be bribed. Enforced transaction ordering The mechanism explicitly defines transaction ordering, making it suitable for applications like real-time on-chain auctions that are sensitive to transaction order. Note that this is not always an advantage since it prevents certain applications from implementing their app-specific sequencing rules. However, BRAID also has a limitation. Since all k chains must remain synchronized, validators require additional network resources. This goes against Ethereum's goal of reducing validator requirements. BuilderNet Overview of BuilderNet BuilderNet is a solution proposed by Flashbots to increase censorship resistance by allowing multiple entities to act as block builders simultaneously. The initial version of BuilderNet implements a multi-operator model, where multiple entities operate a single builder following different regulatory guidelines. This ensures higher censorship resistance compared to a single-operator builder. BuilderNet represents a step toward building a Multiple Concurrent Builder solution. The first release of BuilderNet is jointly operated by Flashbots, Beaverbuild, and Nethermind, and there are plans to onboard more builders in the future. Future decentralization plans for BuilderNet The current multi-operator model still appears as a single builder to external observers, limiting the level of censorship resistance it can achieve. Future releases of BuilderNet aim to decentralize its network further and enhance censorship resistance through the following changes: Orderflow sharing among builders Future versions of BuilderNet will decentralize the block-building process, allowing one builder to pick up transactions censored by another builder. In theory, as long as at least one non-censoring builder exists, all user transactions can still be included in a block. This approach is expected to evolve BuilderNet into a true Multiple Concurrent Builder model. Decentralized infrastructure The current version of BuilderNet relies on centralized infrastructure for transaction ingress and data storage, and participation requires permission. Future versions aim to address this by making BuilderNet permissionless. TEE for better UX & DX BuilderNet also creates a more user-friendly environment for apps, wallets, searchers, and users by leveraging Trusted Execution Environments. TEE ensures that software behaves as specified based on trust in hardware, preventing builders from arbitrarily omitting data or modifying code. By using BuilderNet, searchers gain higher guarantees when sending bundles to builders, as the TEE enforces the execution of reward distribution logic to searchers contributing to block construction. If the reward distribution logic is fair enough, this will provide searchers with economic guarantees comparable to formal contracts with builders. In addition to searchers, apps, and wallets aiming to capture MEV can also benefit from BuilderNet's architecture. BuilderNet in L2s A noteworthy aspect of BuilderNet is its potential applicability to Layer 2 solutions. Ethereum L2s are actively developing proof systems and decentralized validator architectures to inherit Ethereum's security. While these systems ensure the safety of user funds in bridges, they do not inherit Ethereum's censorship resistance. The forced transaction mechanism for L1-to-L2 transactions currently takes at most 12–24 hours (depending on the design) to include transactions in L2, which fails to provide real-time censorship resistance. By outsourcing block building to BuilderNet, L2s could achieve higher censorship resistance than single sequencers while enabling MEV redistribution through enforced transaction ordering with TEE, similar to architectures like Unichain. Conclusion Ideally, blockchains should resist censorship, and the Ethereum community has proposed various solutions to address censorship resistance issues caused by builder centralization. Among the most promising solutions is FOCIL, where 16 validators propose Inclusion Lists for each block, offering efficient censorship resistance and compatibility with APS. FOCIL is expected to be discussed for inclusion in the Fusaka upgrade scheduled for late 2025 or early 2026. Simultaneously, discussions on Multiple Concurrent Builder models led by Flashbots are ongoing. Decentralizing builders could significantly improve Ethereum's censorship resistance and could be implemented independently of core Ethereum development, allowing for faster adoption. Through these initiatives, Ethereum is steadily advancing toward a credibly neutral execution layer, where no single entity holds undue influence over transaction inclusion. By combining FOCIL's validator-driven Inclusion Lists with the potential decentralization of block builders, Ethereum can enhance its resilience against censorship while maintaining efficiency and fairness in MEV distribution. As these solutions evolve, the network continues to uphold its core principles of decentralization, permissionless access, and neutrality, ensuring that Ethereum remains a robust and censorship-resistant settlement layer for the future. A version of this article was originally published here. This piece on the Futures of Ethereum explores its ongoing fight for censorship resistance, examining the impact of regulatory pressure, the role of Proposer-Builder Separation (PBS), and potential solutions like encrypted mempools to keep the network neutral and decentralized. Ethereum has adopted the PBS structure to mitigate the centralization risks of MEV profits. In this system, block proposers (regular validator nodes) delegate block construction to specialized builders, who optimize transaction ordering to maximize MEV extraction. The proposer then selects and signs the most profitable block before broadcasting it to the network. MEV-Boost, an off-chain block auction mechanism, is widely used in Ethereum today to facilitate this process. MEV-Boost allows specialized builders to submit bids to proposers, competing to have their blocks included. While Ethereum's validator set remains highly decentralized, building a block—especially one optimized for MEV—is complex and resource-intensive. Given this high computational and infrastructural burden, it is more efficient to centralize block construction while keeping block attestation decentralized. This is the core principle of PBS: it fairly distributes a portion of MEV profits to validators by the auction happening every block, while ensuring that general validators (including home stakers) are not burdened with the complexities of block construction. By isolating this specialized role, PBS preserves the decentralization of the Ethereum network as a whole while optimizing the efficiency of block production. However, since successful builders require significant resources and privileged transaction flow, only a handful consistently win auctions. Some builders maintain dominance by establishing exclusive deals with specific wallets, dApps, and order flow providers, ensuring access to high-MEV transactions that give them a competitive edge in block auctions. As a result, competition among builders diminishes over time, leading to an oligopolistic structure. Today, approximately 90% of Ethereum blocks are built through MEV-Boost, with just two entities—Beaverbuild and Titan Builder—constructing 95% of these blocks. This concentration raises concerns about censorship resistance, transaction fairness, and the long-term decentralization of Ethereum's block production. Although disruptions or malicious behavior by these builders do not significantly affect the safety of the Ethereum network, they pose a serious threat to censorship resistance. If all MEV-Boost builders decide to censor transactions from specific users, those users will only be able to send transactions through blocks produced by validators not using MEV-Boost, which is about 10% of the total. As a result, processing such transactions would take an average of 10 blocks (approximately 2 minutes). This situation raises two major issues: Regulatory vulnerabilities Regulatory vulnerabilities First, it could make Ethereum more vulnerable to regulations. For instance, the Tornado Cash sanctions imposed by OFAC in 2022 led to a significant number of builders and validators censoring transactions associated with OFAC-sanctioned accounts. OFAC in 2022 Unfair competition in protocols like auctions Unfair competition in protocols like auctions Second, censorship can distort the outcomes of on-chain auctions. For example, consider an auction where one NFT is sold to the highest bidder every block. A block builder could censor all other bids while placing a very low bid, allowing them to acquire the NFT at a significantly reduced price. Various solutions have emerged to address these problems. This post will explore these solutions in two main categories and discuss what form censorship resistance might take in Ethereum’s future. Possible solution 1: Inclusion List Background: Initial Inclusion List Proposal, EIP-7547 The Inclusion List is a censorship-resistance solution that ensures certain transactions are included in a block. It can typically be implemented as follows: Here's a simple mental model: before a builder constructs a block, the proposer sends an order with an 'Inclusion List' stating, "Include these transactions in the block." Builders must include these transactions in the block they create, and if a block is built without the transactions in the Inclusion List, it is considered invalid. For Ethereum before PBS, the mempool, where transactions are held before being entered into blocks, was included in Ethereum as a non-consensus component. Therefore, from the perspective of the Ethereum consensus layer, it was not known where the transactions contained in the blocks came from. One of the main reasons why MEV led to censorship is that mempool is a non-consensus component, so the builders who created the block had complete authority over which transactions to censor or include in the block. Inclusion lists introduce a mechanism that uses multiple validators to act as an 'on-chain mempool' on the consensus layer. In this way, the consensus layer sufficiently constrains the builders' authority to select transactions to provide censorship resistance. One of the most prominent proposals for implementing an Inclusion List was EIP-7547 , Forward Inclusion List. This proposal allowed a proposer to include up to 16 transactions in the Inclusion List. The "forwarding" mechanism ensured that the Inclusion List proposed for block N would be applied to block N+1. EIP-7547 This proposal was initially intended to be part of Ethereum's Pectra upgrade, but it was eventually excluded, and one reason was compatibility issues between the forwarding mechanism and EIP-3074 . EIP-3074 EIP-3074 introduces a form of Native Account Abstraction that uses an opcode called AUTHCALL, enabling one account to adjust the balances of multiple EOAs (Externally Owned Accounts). This mechanism can easily undermine the Inclusion List. For example, suppose Alice includes a transaction (A) in the Inclusion List, where her EOA sends ETH to Bob. At the same time, she creates another transaction (B) using EIP-3074's AUTHCALL to transfer all her EOA's balances to a different account. Let's assume transaction B is included in block N, while transaction A is included in the Inclusion List for block N+1. Here's the key issue: when the proposer creates the Inclusion List, they do not know what transactions the builder will include in the current block. In this scenario, transaction B in block N makes transaction A invalid. Consequently, the builder for block N+1 would be unable to construct a valid block due to the invalidity of transaction A in the Inclusion List. Attempts have been made to resolve this issue through additional constraints within the Inclusion List. However, the core issue remains: EIP-3074 inherently allows for manipulating balances in other EOAs. Simple checks, such as verifying the "From" address, cannot detect interference between Inclusion List transactions and other transactions. This is called the free data availability problem, mentioned in the article 'No Free Lunch - a new inclusion list design.' 'No Free Lunch - a new inclusion list design.' Although EIP-3074 was excluded from the Pectra upgrade, a similar functionality—EIP-7702—was included. As a result, these issues must be resolved before EIP-7547 can be implemented on the Ethereum mainnet. Moreover, EIP-7547 faced additional challenges, such as the limitation that only one proposer could create an Inclusion List per block. These factors made it difficult to apply EIP-7547 to the Ethereum mainnet as-is. Consequently, EIP-7547 was excluded from the Pectra upgrade. FOCIL Is there no solution to these issues? Recently, a solution called FOCIL (Fork-choice enforced Inclusion Lists) has gained significant attention within the Ethereum ecosystem and is considered one of the most likely solutions to be implemented on the Ethereum mainnet. Proposed as EIP-7805 , FOCIL introduces a mechanism where not just one but multiple entities propose Inclusion Lists. Its details and characteristics are as follows: EIP-7805 At its core, FOCIL adopts the Inclusion List concept, meaning that someone creates a list of transactions that must be included in every block, and proposers are required to incorporate them. However, FOCIL differs from EIP-7547 in two significant ways: Instead of one proposer, an IL committee of 16 members independently proposes Inclusion Lists. The Inclusion List proposed for block N is included in block N itself, not block N+1. Instead of one proposer, an IL committee of 16 members independently proposes Inclusion Lists. The Inclusion List proposed for block N is included in block N itself, not block N+1. Mechanism details The construction of the Inclusion List for block N begins when the slot for block N-1 starts. A randomly selected IL committee of 16 validators receives block N-1, sets it as their head, builds their respective Inclusion Lists, and propagates these through peer-to-peer. The construction process ends 9 seconds into the 12-second N-1 slot, after which the committee can no longer add to the list. Having received these lists via the P2P network, the builder for block N must include them while constructing the block. Shortly after the start of the N slot, the block is delivered to the proposer. Validators verifying block N compare the transactions in the Inclusion Lists they received earlier with those included in block N to ensure compliance. Advantages of FOCIL over EIP-7547 Compared to the previously proposed EIP-7547, FOCIL offers the following benefits: Higher resistance to censorship Higher resistance to censorship Each slot involves an IL committee of 16 validators constructing the Inclusion List. This provides stronger resistance to censorship than EIP-7547, where only a single validator was responsible. Seamless implementation Seamless implementation By utilizing the standard API forkChoiceUpdate used by consensus clients, Inclusion Lists can be more easily and seamlessly integrated into the protocol. “Real-time” censorship resistance “Real-time” censorship resistance Unlike EIP-7547, where the Inclusion List proposed for block N+1 causes a delay, FOCIL includes the IL in the block proposed for N itself, allowing transactions to be incorporated without delay. This simultaneous construction of blocks and Inclusion Lists ensures compatibility with previously proposed account abstraction mechanisms like EIP-3074 or EIP-7702. Prior blocks cannot invalidate transactions in the Inclusion List. Builders receive the IL before finalizing block construction, enabling them to exclude any transactions that would render the IL invalid. This process is straightforward: builders record the nonce and balance of all EOAs involved in the IL and update these values whenever changes occur. This simple method allows builders to verify the validity of IL transactions and complete block construction successfully. Role of FOCIL in blocks FOCIL allows for up to 16 Inclusion Lists per block, with each list limited to a maximum size of 8KB (8192 bytes). If there is no overlap in the transactions proposed by the 16 Inclusion Lists, the maximum size of IL transactions in a single block could reach 128KB. This limitation is designed to minimize resource usage for validators as Inclusion Lists propagate through the P2P network. So, how much of an Ethereum block could be built using ILs under FOCIL? Historically, the average Ethereum block size has been around 80–100KB, with a maximum of approximately 300KB. If there is no overlap in the transactions proposed by the 16 Inclusion Lists, it is theoretically possible to construct an entire Ethereum block using only IL transactions. However, this scenario is unlikely. Since transactions in the Inclusion List are generally sourced from the public mempool, there is a high probability of overlap unless the 16 IL committee members use entirely different configurations. In summary, transactions in FOCIL's Inclusion Lists are expected to occupy between 6–10% and up to 100% of an Ethereum block, with cases leaning closer to the 6-10% range provided the IL committee members are looking at the same public mempool. Beyond FOCIL: Combining APS with FOCIL Background of APS One reason FOCIL has become a leading solution is its potential synergy with Attester-Proposer Separation (APS) proposals like Execution Tickets . What is APS, and how does it complement FOCIL? Execution Tickets APS proposes separating the roles of the proposer and attester for blocks. In Ethereum, block building under PBS involves splitting the roles between proposers, who propose blocks, and builders, who construct block contents. This prevents centralized staking pools formed by proposer-builder alliances from monopolizing MEV profits and recording much higher APR than regular validators, which could centralize validator operations. This issue was resolved through MEV-Boost, and an in-protocol relay system (ePBS) has been proposed to address remaining centralization concerns. However, is PBS truly the optimal structure? One critical role of Ethereum's consensus layer is distributing rewards and imposing penalties on validators. If this process becomes centralized, the chain will be affected by centralized entities, regardless of validator votes. So, the consensus layer should remain highly decentralized. The execution layer, however, does not have the same constraints. Tasks like MEV extraction and transaction ordering are inherently complex and strategic, necessitating centralized entities. If these tasks were imposed on all validators, it would drive the chain towards centralization. In this regard, Ethereum's philosophy is that 'consensus participants should not be incentivized to pursue complex tasks for individual profit.' Through PBS, Ethereum separates validators from MEV actors (builders, searchers) to distribute MEV profits evenly across the entire network. Still, proposers can employ unconventional strategies to gain additional profits: Collusion between proposers and builders Collusion between proposers and builders Builders are already centralized, but proposers also exhibit some centralization. For instance, Coinbase holds approximately 10% of the total staked ETH. If Coinbase colluded with a specific builder to accept only its blocks, this would introduce a significant centralization vector into the ecosystem. Proposer timing games Proposer timing games Ethereum’s relatively long 12-second block time introduces an interesting dynamic called timing games, where proposers delay block publication to maximize MEV profits. The MEV available in a block generally increases linearly over time. Proposers can delay block propagation to maximize their MEV, publishing just before they risk rejection by the next proposer. So, how much can a proposer delay block publication within a single slot (12 seconds)? According to Ethereum's protocol specifications, for the next proposer to consider the previous block valid, the block must receive votes from 40% of the validators (attesters) assigned to the previous slot's committee. On the current Ethereum mainnet, the point at which 40% of validator votes are received occurs approximately 3.8 seconds into the slot. A proposer attempting to play timing games would adopt a strategy of delaying block publication as much as possible, waiting until just enough votes (40% or more) are received to avoid rejection by the next proposer. However, the outcome does not always align with the proposer's intentions. If the block fails to receive 40% of the votes, the next proposer will reject it. In such cases, validators who voted for the rejected block will have voted for a block not part of the canonical chain, resulting in slashing penalties. If this situation persists, validators may delay their votes to observe the network's state and ensure their votes are accurate. This behavior can increase the number of reorgs in the chain. In summary, proposer timing games can negatively affect Ethereum's consensus outcomes and must be prevented. Role of APS APS is the solution designed to address this issue. APS proposes creating a separate proposer for the execution layer, completely separating the consensus layer from MEV. For example, one of the representative APS proposals, Execution Ticket, introduces an "execution proposer" distinct from the beacon chain proposer. In this system, the protocol generates and sells execution tickets, which grant their holders the right to be randomly selected as execution proposers for each block. These execution proposers will take on the parts of the role currently performed by beacon chain proposers in MEV-Boost, receiving execution payloads and proposing them. The rationale behind this design is that centralization of execution proposers is not problematic; in fact, separating them from the consensus layer improves the overall system. Then, what tasks would the beacon chain proposer handle under APS? Apart from managing validator deposits, rewards, and penalties (state transitions within the beacon chain), the consensus layer proposer has an additional key role in APS: constructing Inclusion Lists and passing them to the execution layer. It is more desirable for the Inclusion List to rely on the consensus layer's decentralized validator set rather than the relatively more centralized execution proposers. This helps reduce the likelihood of censorship attackers colluding with proposers to censor transactions. Thus, APS proposals like Execution Ticket suggest a mechanism where the consensus layer validators construct Inclusion Lists as part of the beacon block. These lists then serve as the foundation for the execution proposer to build and propose the full block. In summary, Inclusion List-based censorship resistance solutions align seamlessly with Ethereum's vision for APS. Consequently, FOCIL is considered one of the most promising solutions for censorship resistance. Advantages of FOCIL FOCIL ensures effective censorship resistance while maintaining network resource usage at reasonable levels by limiting each IL to 8KB and having an IL committee of 16 validators (which is the same as the size of one blob). The chart below illustrates how long it takes for a transaction to be included in the chain, depending on the percentage of honest validators in the IL committee. Even if only 15% of validators in the committee are non-censoring, transactions can still be included immediately. This demonstrates how a small committee of 16 validators can achieve efficient censorship resistance. Possible solution 2: Multiple concurrent proposer/builder How about enabling multiple participants to propose an entire block together? This concept is known as "Multiple Concurrent Proposer". Rather than a single entity proposing a block at a time, multiple entities propose blocks simultaneously for the same slot. Under certain conditions, adopting such a solution can significantly increase the cost of censorship. Ethereum has a mechanism where proposers for 32 blocks in each epoch are revealed simultaneously. This setup allows for scenarios where someone could attempt to "bribe" the proposers to censor specific transactions. But what if blocks were proposed not by one person but by N proposers simultaneously? In this scenario, employing a mechanism like conditional tips makes it possible to introduce a "prisoner's dilemma" among the N proposers, thereby drastically increasing the cost of censorship. For example, imagine a situation where N proposers are tasked with creating a block, Alice requests them to include her transaction, and Bob is trying to censor Alice's transaction. Alice can offer a bribe to the proposers for including her transaction, while Bob can also bribe them to censor it. In this situation, Alice can adopt a bribing strategy that effectively increases Bob's cost of censorship, as follows: If two or more proposers include the transaction, Alice gives a small tip of t to each of them. If only one proposer includes the transaction, Alice gives a large tip of T to that proposer. If two or more proposers include the transaction, Alice gives a small tip of t to each of them. If only one proposer includes the transaction, Alice gives a large tip of T to that proposer. In this case, the proposers find themselves in a "prisoner's dilemma"-like scenario. The optimal strategy for each proposer in this game is to include the transaction rather than censor it. For Bob to successfully censor Alice's transaction, he would need to bribe all N proposers, costing him NT. On the other hand, Alice only needs to spend at most Nt to ensure her transaction is included. This significantly increases the cost of censorship. This concept can be implemented on top of PBS in several ways. For instance, multiple proposers could build blocks simultaneously, or multiple builders could construct blocks concurrently. This section introduces two mechanisms to achieve this within the PBS structure: BRAID - Multiple Concurrent Proposer BuilderNet - Multiple Concurrent Builder BRAID - Multiple Concurrent Proposer BuilderNet - Multiple Concurrent Builder BRAID Overview of BRAID BRAID is an Ethereum censorship-resistant solution proposed by Max Resnick, who was part of the Special Mechanism Group. The mechanism is based on a simple yet powerful concept: instead of running a single chain as Ethereum does now, k synchronized LMD-GHOST chains would run in parallel. In other words, with BRAID, k proposers simultaneously produce their own blocks for each slot. How BRAID works An obvious question arises: How are the k blocks processed? Since the blocks must ultimately be consolidated into one to maintain a single blockchain, BRAID uses a predefined ordering rule to merge them. For example, the blocks could be merged by removing duplicates and sorting transactions in descending order of fees. The finalized block would then contain the consolidated, ordered transactions. Advantages & Limitations BRAID offers several advantages: Strong censorship resistance Strong censorship resistance By enabling multiple proposers to work concurrently, BRAID significantly increases the cost of censorship, as multiple entities would need to be bribed. Enforced transaction ordering Enforced transaction ordering The mechanism explicitly defines transaction ordering, making it suitable for applications like real-time on-chain auctions that are sensitive to transaction order. Note that this is not always an advantage since it prevents certain applications from implementing their app-specific sequencing rules. However, BRAID also has a limitation. Since all k chains must remain synchronized, validators require additional network resources. This goes against Ethereum's goal of reducing validator requirements. BuilderNet Overview of BuilderNet BuilderNet is a solution proposed by Flashbots to increase censorship resistance by allowing multiple entities to act as block builders simultaneously. The initial version of BuilderNet implements a multi-operator model, where multiple entities operate a single builder following different regulatory guidelines. This ensures higher censorship resistance compared to a single-operator builder. BuilderNet represents a step toward building a Multiple Concurrent Builder solution. The first release of BuilderNet is jointly operated by Flashbots, Beaverbuild, and Nethermind, and there are plans to onboard more builders in the future. Future decentralization plans for BuilderNet The current multi-operator model still appears as a single builder to external observers, limiting the level of censorship resistance it can achieve. Future releases of BuilderNet aim to decentralize its network further and enhance censorship resistance through the following changes: Orderflow sharing among builders Orderflow sharing among builders Future versions of BuilderNet will decentralize the block-building process, allowing one builder to pick up transactions censored by another builder. In theory, as long as at least one non-censoring builder exists, all user transactions can still be included in a block. This approach is expected to evolve BuilderNet into a true Multiple Concurrent Builder model. Decentralized infrastructure Decentralized infrastructure The current version of BuilderNet relies on centralized infrastructure for transaction ingress and data storage, and participation requires permission. Future versions aim to address this by making BuilderNet permissionless. TEE for better UX & DX BuilderNet also creates a more user-friendly environment for apps, wallets, searchers, and users by leveraging Trusted Execution Environments. TEE ensures that software behaves as specified based on trust in hardware, preventing builders from arbitrarily omitting data or modifying code. By using BuilderNet, searchers gain higher guarantees when sending bundles to builders, as the TEE enforces the execution of reward distribution logic to searchers contributing to block construction. If the reward distribution logic is fair enough, this will provide searchers with economic guarantees comparable to formal contracts with builders. In addition to searchers, apps, and wallets aiming to capture MEV can also benefit from BuilderNet's architecture. BuilderNet in L2s A noteworthy aspect of BuilderNet is its potential applicability to Layer 2 solutions. Ethereum L2s are actively developing proof systems and decentralized validator architectures to inherit Ethereum's security. While these systems ensure the safety of user funds in bridges, they do not inherit Ethereum's censorship resistance. The forced transaction mechanism for L1-to-L2 transactions currently takes at most 12–24 hours (depending on the design) to include transactions in L2, which fails to provide real-time censorship resistance. By outsourcing block building to BuilderNet, L2s could achieve higher censorship resistance than single sequencers while enabling MEV redistribution through enforced transaction ordering with TEE, similar to architectures like Unichain. Conclusion Ideally, blockchains should resist censorship, and the Ethereum community has proposed various solutions to address censorship resistance issues caused by builder centralization. Among the most promising solutions is FOCIL, where 16 validators propose Inclusion Lists for each block, offering efficient censorship resistance and compatibility with APS. FOCIL is expected to be discussed for inclusion in the Fusaka upgrade scheduled for late 2025 or early 2026. Simultaneously, discussions on Multiple Concurrent Builder models led by Flashbots are ongoing. Decentralizing builders could significantly improve Ethereum's censorship resistance and could be implemented independently of core Ethereum development, allowing for faster adoption. Through these initiatives, Ethereum is steadily advancing toward a credibly neutral execution layer, where no single entity holds undue influence over transaction inclusion. By combining FOCIL's validator-driven Inclusion Lists with the potential decentralization of block builders, Ethereum can enhance its resilience against censorship while maintaining efficiency and fairness in MEV distribution. As these solutions evolve, the network continues to uphold its core principles of decentralization, permissionless access, and neutrality, ensuring that Ethereum remains a robust and censorship-resistant settlement layer for the future. A version of this article was originally published here. A version of this article was originally published here. A version of this article was originally published here . here here