Design concepts and potential challenges of decentralized block construction

Author: BallsyAlchemist, Distributed Capital Researcher

Compiled by: 0x11, Foresight News

At the beginning of 2022, there was a discussion about the potential centralization of block building and the effects of MEV and block sorting after PBS (Proposer/Builder Separation). Personally, I resonated with these concerns and published an article exploring the risks of centralization. The community had differing views on this issue, with some accepting the idea of a decentralized validator network on Ethereum alongside a more centralized block builder, as outlined by Vitalik Buterin in his Endgame.

However, these concerns were ultimately set aside and faded from public discussion. Nevertheless, the last SBC meeting brought these concerns back to the forefront as Vitalik proposed methods for decentralized block building (Jon Charbonneau wrote an excellent report on-site). Since then, I have been contemplating the potential designs for decentralized block builders and trying to share my thoughts and the challenges faced in decentralized block building.

How centralized is block building, and why do we need decentralization?

Ethereum has been striving to be the most censorship-resistant, permissionless, and trustless blockchain, and any form of centralization could undermine these attributes. I will outline the main issues and explain why some are significant while others are not.

Exclusive Order Flow: Flashbots and the community have been actively discussing how exclusive order flow can lead to a single block builder monopolizing bids and order flow. If builders provide incentives such as MEV sharing, private transactions, and MEV backrun guarantees to collect order flow that others cannot access, they can build higher-value blocks and consistently win auctions. However, I believe it is too broad to categorize all types of incentives that lead to exclusivity into one issue, so I will divide them into the following subcategories: exclusive order flow through MEV redistribution and exclusive order flow through MEV backrun guarantees and private transactions. It is important to note that these subcategories are not mutually exclusive and have different implications.

• MEV Redistribution: As more order flow markets emerge in the coming years, this concern may become less significant. Market competition will intensify, and they will need to offer more MEV rebates through order flow auctions to attract users and trades. This competition will ultimately affect users' choices about where to submit transactions.

• Private Transactions and MEV Backrun Guarantees: This is an optional feature that some may prefer. However, if it is to grow on a large scale, using this type of exclusive order flow could lead to order flow centralization. To mitigate this, it would be beneficial to have decentralized block builders continuously proposing higher-value blocks.

Censorship Regime: Insufficient decentralization of block builders may lead to collusion among some builders and censorship of transactions. While solutions like crList, Geth's native block building options, and cryptographic mempool aim to mitigate this risk, they also introduce challenges, such as partial embodiment of account abstraction, the need for infrastructure to support stateless validators' state access, and enabling privacy around existing security issues. To gain a deeper understanding of the current block building environment, here are some statistics on block production. Based on the block success rates of all builders in December 2022, the top 5 builders are as follows:

Average success rate of the top five block builders

The top three block builders collectively controlled 60% of the total successfully submitted blocks that month, indicating a significant trust placed in their non-collusion or censorship of transactions. To address this issue, implementing a framework for a decentralized block building process would increase the costs of collusion and censorship, thereby achieving a more trustless block production system.

Centralization due to Network Effects: In imperfect market competition, it can be argued that a builder will naturally outperform its competitors by building higher-value blocks and attracting more order flow without the need for direct incentives, leading to centralization. However, this is not always the case in reality.

Block success rate chart

The chart illustrates the block success rates over a period before and after the merge. Notably, it can be seen that Flashbots (represented in dark blue) has seen a reduction in block success rates, reaching a balance similar to other major block builders, rather than completely dominating block production. This contradicts the proposed centralization due to network effects, and this outcome may have multiple explanations.

• Exclusive Order Flow from Competitors: Other competing builders may have exclusive order flow (such as private transactions) that allows them to produce higher-value blocks.

• Order Flow Congestion: Too many orders wishing to be included in blocks via Flashbots may lead to delays. This may force users to place transactions across multiple builders to increase their chances of being included in a block, especially during high traffic periods.

• OFAC Compliance: Flashbots complies with OFAC standards, while some others do not. Users may choose builders based on certain regulatory concerns.

• Flashbots open-sourced builder and relay code, attracting more competition.

These factors somewhat mitigate the impact of network effects on builder centralization. However, as shown in the table above, centralization remains an issue, and I believe the community should pay more attention and recognition to it.

What are we decentralizing?

The power of block production is key to decentralization. Rather than entrusting a single entity with complete control over block construction, it is better to have a framework that allows multiple entities or individuals to participate in the process. Currently, there are two ways to achieve this, and it should be noted that these methods are not mutually exclusive.

• Proposers participating in block building

• Decentralizing block builders through new architectures and algorithms, allowing competitive block production (a large design space)

The technical feasibility and challenges surrounding the proposed methods are still under discussion, and I would like to share my thoughts here.

Method 1: Proposers Participating in Block Production

There are several methods currently available to enable proposers to participate in block production, but I believe the Eigenlayer approach offers a cleaner solution. Before delving into the specifics of Eigenlayer, here is a brief overview: it is a set of smart contracts on the Ethereum blockchain that allows validators holding ETH to choose to provide security for new services by imposing additional penalty conditions on their staked ETH. For a more comprehensive understanding, you can read here.

How do builders currently interact with proposers in the block production process? The Proposer-Builder Separation (PBS) system has been implemented. In this system, builders can submit a block to a relayer, which then verifies the correctness of the block and relays it to the proposer. This system is designed to prevent proposers from censoring, as the content of the block is only revealed to the proposer after the block header with the highest bid and corresponding signature is relayed back to the relayer. The entity responsible for ensuring the data availability of the submitted block will then reveal the data (transactions) to the proposer, who will then send the block to the rest of the network. The following diagram illustrates this process.

Block construction process diagram, source Eigenlayer

The PBS system enhances Ethereum's censorship resistance by limiting the authority of validators to proposing higher-value blocks. However, Eigenlayer has proposed a MEV management framework called MEV+, which allows block proposers to include additional transactions on top of existing blocks. This is achieved by imposing additional penalty conditions.

Currently, block proposers are only constrained by one penalty condition, which is the prohibition of the same proposer proposing two blocks simultaneously. Using the MEV-Boost+ framework, if a proposer modifies or fails to include the submitted "builderpart" when proposing a new block that adds a "proposerpart" transaction, they will also be penalized. This effectively prevents proposers from attempting to modify or remove transactions from the block builders. The following diagram illustrates how MEV-Boost+ works.

Proposer participation in block production diagram, source Eigenlayer

This mechanism also works effectively when combined with crList, which is a list of transactions that proposers must include in the block. This helps reduce the likelihood of transaction censorship at the builder level. While other solutions have been proposed, such as pre-committing to the Merkle root or KZG commitments to allow proposers to participate in block production, EigenLayer offers a simpler alternative that does not require proposers to provide additional computational resources and can participate in block production simultaneously.

Overall, this method is straightforward and can further decentralize block production by bringing proposers into the process, thereby sharing block authority with more entities. However, the impact of this method is limited, as it fundamentally still relies on centralized block builders and cannot fully prevent censorship arising from builder centralization. Thus, we have a second method.

Method 2: Decentralized Block Builders

Designing decentralized block builders is an intriguing area of exploration, with teams like Flashbots already experimenting with different designs. When considering how to decentralize builders, it is important to be aware of the following challenges:

• MEV Theft: Builders can access information in the bundled transactions submitted by seekers and steal the MEV from seekers. To prevent this, the privacy of submitted bundles and transactions should be protected by design.

• Suboptimal MEV: Ideally, decentralization should be achieved while maintaining optimal MEV. Due to decentralization, some designs may lead to inefficiencies in block building and result in reduced MEV for blocks, thereby decreasing the competitiveness of blocks. However, it can also be argued that as long as decentralized builders attract more order flow than other builders, suboptimal block production is acceptable.

• Competition with Centralized Builders: Decentralized builders need to compete with centralized builders in producing MEV. The goal of decentralized builders is to aggregate as much order flow as possible to compete with the centralized order flow between centralized builders.

• Latency: Block production is time-sensitive, and there may be significant latency issues.

• Jurisdiction (Censorship Resistance): Decentralized builders should be distributed across multiple jurisdictions to resist judicial censorship (such as OFAC). Regulatory frameworks in most countries/regions remain gray, and there is a reluctance to risk the builder network being shut down by a single regulatory entity.

Considering these challenges, I would like to discuss the proposed decentralized builder designs within the research community and delve into some potential issues surrounding them. Currently, there are two main types of decentralized builders:

• Seeker - Aggregator Model: Seekers submit transaction bundles, and aggregators build blocks without knowing much or any information about the submitted bundle.

• Slot Auction Model: Block space is auctioned sequentially, with blocks being constructed incrementally by multiple builders without an aggregator.

The following proposed designs are variants of either of these two schemes:

Design 1: Seeker - Aggregator Model using TEE/TPM

This method requires aggregators to use a Trusted Execution Environment (TEE) or Trusted Platform Module (TPM) to ensure the privacy of the received transaction bundles, thereby preventing MEV theft. For more information on the differences between TEE and TPM, see here. Below are the design details (TPM and TEE can be used interchangeably in this case):

TEE-based block builder diagram, source Vitalik

Flashbots released a progress report detailing their experience running Geth in SGX, a TEE developed by Intel. While there are many technical challenges, they have successfully run Geth using encrypted swap space in SGX and Gramine, one of the library operating systems designed for SGX, with 500 GB RAM, 1 TB SSD swap space, and 64 GB protected memory. Here are some key points from the experiment:

• Running Geth in SGX is feasible but resource-intensive and time-consuming, requiring significant memory and a 3-hour startup time to store and encrypt on-chain data.

• Encrypted swap space provides good performance but is still vulnerable to side-channel attacks, covert channel attacks, and information leaks caused by other programming errors.

• Trade-offs need to be made between performance and resources. For example, resource-light methods may perform poorly and may have more severe information leakage issues.

Additionally, there are other considerations when using SGX:

There are some methods to mitigate information leakage issues, but some methods may lead to performance degradation, requiring more trial and error to refine the best-performing framework for running SGX.

The complexity of the setup and the scarcity of SGX-compatible chips create a high barrier to entry. Cloud service providers may offer accessibility to SGX and can serve as a temporary solution, but in the long run, cloud operators will be a significant centralizing factor.

SGX information leakage remains a concern. If other exploitable vulnerabilities are discovered in SGX, aggregators should immediately execute their own TCB recovery (the process aimed at re-instantiating the SGX environment) instead of waiting for Intel's response, which may take a long time.

Unlike centralized builders, decentralized builders should, in principle, welcome and encourage the aggregation of order flow. Assuming zero information leakage, the seeker-aggregator model should have trust-minimized security, trusting that encryption and SGX operate perfectly. However, it may have highly trusted liveness, where only a few entities run aggregators, which is possible because bundles naturally aggregate to the most successful aggregators. In this case, order flow/bundles would not lead to censorship issues but could lead to liveness issues.

If the number of entities running aggregators is low, there may be a lack of geographical distribution leading to jurisdictional bias, making the network more susceptible to regulatory scrutiny.

While TEE-based solutions like SGX seem to be the more practical method for decentralizing builders at present, they still face many technical challenges that need to be overcome.

Design 2: Seeker - Aggregator Model with Threshold Encryption and ZK-SNARKs

This is another seeker-aggregator model where encryption is applied to the bundles rather than the aggregator. Here is a rough example:

Block generator diagram based on TE and ZKP

This design may have collusion between the aggregator and the proposer. Threshold encryption only ensures the privacy of the bundles before computing the state root, and the aggregator computing the state root needs access to transaction information or state updates. This access can enable MEV theft by tracking the corresponding transactions. This design eliminates the need for TEE/TPM, but it cannot prevent such collusion without adding additional complexity, such as requiring proposers to submit to the block before allowing decryption to compute the state root. Here are some issues with such designs:

• Early commitment by proposers to the block can be achieved through re-staking infrastructure (like Eigenlayer), but it incurs additional operational costs, as ETH stakers need to be adequately incentivized to balance the associated penalty conditions.

• Proposers may miss out on higher-value blocks by submitting a block too early.

• Increased computational overhead and latency for generating ZK-SNARKs and threshold encryption may render this model impractical.

• Questions about who will be the qualified key holders for the threshold encryption package arise; if seekers hold the keys, an attacker masquerading as a seeker could block decryption and delay block production. Conversely, aggregators cannot hold the keys, as each of them is competing for block production and may be incentivized to obstruct other aggregators. This may require a third party, neither a seeker nor an aggregator, introducing additional trust assumptions that could undermine the trustless/trust-minimized attributes of decentralized builders.

• Same jurisdictional issues as mentioned in the first design.

Design 3: Slot Auction Model Based on Chaotic Iterative Search

This design allows multiple block builders to participate in block production without an aggregator. Below is a rough illustration:

Block builder diagram based on slot auction

This design aims to allow multiple block builders to participate in constructing a single block by dividing the maximum gas of the block into n slots, given x builders, where n = f(x) and n < MAX_THRESHOLD. Builders in the network start bidding for the allocation of block space, with the highest bidder filling that portion of the block; the first successful bidder becomes the block builder, and bidding for the remaining slots continues, with new bidders receiving the in-progress block to build upon. When there are no more bidders or the block is full, the bidding cycle ends. The builder holding the block at the end submits it to the proposer. This design protects privacy by executing MEV auctions (MEVA) in each slot and applying threshold encryption, dividing the traditional task of a single builder into smaller parts. The main advantage of this design is that it eliminates the need for a centralized aggregator and allows builders to be distributed globally, providing distributed jurisdiction. However, this design also presents some potential challenges:

• When to reveal encrypted slots will determine the efficiency of the auction (the closer the bids are to the corresponding MEV, the more efficient the auction will be, as MEV will be the "true" price of the slot). If encrypted slot N-1 is revealed before the auction for slot N, the auction will be effective, as builders will be able to bid based on their expected MEV. However, in practice, there may be latency issues, as the strict sequential auctioning and decryption of slots may take some time. Therefore, another option is to allow builders to pre-bid for the rights to build blocks for all slots and decrypt the blocks sequentially as builders fill the slots. Since builders do not know the MEV of the slots before bidding (they need to know the transactions in slot N-1 to determine the MEV of slot N), the auction may be inefficient, and builders may even inadvertently overbid for slots due to a lack of realized MEV. However, this issue can be mitigated by conducting statistical analysis of historical bidding prices for slots in given positions in blocks.

• To prevent builders from modifying transactions in previous slots, other builders must act as witnesses and provide some form of fraud proof.

• When slots are decrypted sequentially, centralized builders can steal some MEV. If users submit order flow solely through this slot auction-based builder network, the MEV theft issue may not be as severe, but if order flow is submitted through both centralized builders and this builder network, MEV theft may become a problem.

• Malicious attackers, such as competing centralized builders, can disrupt the network by winning bids instead of building blocks, temporarily halting block production. If there are enough such attackers, this builder network may become dysfunctional (unable to produce any blocks). A mechanism is needed to ban malicious builders from the network and have a backup plan for unfilled slots.

Design 4: Proposer Commitment Sequential Slot Auction

This is another approach using the slot auction model, similar to the third design that does not rely on aggregators. The main difference is that this design enforces proposer commitments for each filled slot through Eigenlayer. Instead of submitting the entire block to the proposer at the end, each slot will be sequentially submitted by the proposer, and Eigenlayer can be used to avoid protocol-level changes to Ethereum. Since the proposer's commitment occurs immediately after the slots are revealed, there are fewer concerns about builders modifying transactions in previous slots. However, aside from potentially worse delays due to the additional sequential proposer commitments in the process, most of the other issues mentioned in the third design also apply to this design.

Outlook on the Future of Block Building

Decentralization is an important aspect of blockchain technology, and ensuring the decentralization of block builders is crucial. In this article, we discussed several potential methods for decentralized block builders. However, this remains an open design space for the research community to explore and collaborate.

Designing a competitive decentralized block builder requires extensive experimentation, and teams like Flashbots are already exploring SGX and other privacy-preserving technologies. However, more innovation and research are needed to fully realize the potential of these technologies.

Overall, decentralized block builders represent an ongoing challenge that requires collaboration and expertise from a broader research community beyond cryptocurrency. Through experimentation, testing, and innovation, we can strive to create a decentralized, competitive block builder to enhance the network's censorship resistance.