The Good Tech Companies - Futures of Ethereum II - Censorship Resistance

Episode Date: February 7, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/futures-of-ethereum-ii-censorship-resistance. The article explores Ethereum's efforts to ensure censorship resistance, focusing on solutions like PBS and encrypted mempools amid regulatory pressures. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum-blockchain, #ethereum-eips, #ethereum-scalability, #mev-on-ethereum, #ethereum-merge, #ethereum-censorship-resistance, #2077-research, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. The article examines Ethereum's strategies for maintaining censorship resistance, highlighting Proposer-Builder Separation (PBS), encrypted mempools, and potential solutions to combat regulatory challenges and centralization risks.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. Futures of Ethereum 2, Censorship Resistance, by 2077 Research. 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 TitanBuilder, 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 1. 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. 2. 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. Ablock 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 forms 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 proposers ends 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 builder's authority to select transactions to prove censorship

resistance. One of the most prominent proposals for implementing an inclusion list WASEIP7547 forward inclusion list. This proposal allowed a proposer to include up to 16 transactions in the inclusion list. The forwarding mechanism 16 transactions in the inclusion list. The forwarding mechanism ensured that the inclusion list proposed for block N would be applied to block N plus 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 a UTHCALL, 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 plus 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 N valid. Consequently, the builder for block N plus 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, 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. 1. Instead of one proposer, an IL committee of 16 members independently proposes inclusion lists. 2. The inclusion list proposed for block N is included in block N itself, not block N plus 1. Mechanism details the construction of the inclusion list for block N begins when the slot for block N1 starts. A randomly selected IL committee of 16 validators receives block N1, 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 N1 slot, after which

the committee can no longer add to the list. Having received these lists via TEP2P 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 FOSSIL over EIP-7547 compared to the previously proposed EIP-7547, FOCIL offers the following benefits 1. 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. 2. Seamless implementation. By utilizing the standard API fork choice update used by consensus clients, inclusion lists can be more easily and seamlessly integrated into the protocol. 3. Real-time censorship resistance. Unlike EIP-7547, where the inclusion list proposed for block N plus 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 LIKEE.K.E.E.I.P.3074 or E.I.P.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 Fossil in BLOCKSFOCIL allows for up to 16 inclusion lists per block, with each list limited to a maximum size of 8 kilobytes, 8,192 bytes. If there is no overlap in the transactions proposed by the 16 inclusion lists, the maximum size of ill transactions in a single

block could reach 128 kilobytes. 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 IELTS under FOCIL? Historically, the average Ethereum block size has been around 80 to 100 kilobytes, with a maximum of approximately 300 kilobytes. 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 a tester-proposer separation, APS, proposals like execution tickets. What ISAPs and how does it complement FOCIL? APS proposes separating the roles of the proposer and a tester 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 1. Collusion between proposers and builders. Builders are already centralized, but proposers also exhibit some centralization. For instance, Coinbase holds approximately 10% of the total state debt. If Coinbase colluded with a specific builder to accept only its blocks, this would introduce a significant centralization vector into the ecosystem. 2. 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 scan 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 slots 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 payload sand 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 layered centralized 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 tickets 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-resistant solutions align seamlessly with Ethereum's vision for APS. Consequently, FOCIL is considered one of the most promising solutions for censorship resistance. Advantages of FossilFacil ensures

effective censorship resistance while maintaining network resource usage at reasonable levels by limiting each yield to 8 kilobytes 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 end proposers,

thereby drastically increasing the cost of censorship. For example, imagine a situation where end 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 1. If two or more proposers include the transaction, Alice gives a small tip of tea to each of them. 2. If only one proposer includes the transaction, Alice gives a small tip of T to each of them. 2. 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 a 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 end proposers, costing him NT. On the other hand, Alice only needs to spend at most end 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 one braid multiple concurrent proposer two builder net 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 consolidated, ordered transactions. Advantages and limitations Braid offers several advantages 1. 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. 2. 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 1. Order flow sharing among achieve. Future releases of BuilderNet aim to decentralize its network further and enhance censorship resistance through the following changes 1. Order flow 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. 2. 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. T for Better UX and DX BuilderNet also creates a more user-friendly environment for apps,

wallets, searchers, and users by leveraging trusted execution environments. T 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 T 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 L2SA 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 12 to 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 T, 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 blockbuilders, 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. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.