Original compilation: 0x 11 , Foresight News
Original compilation: 0x 11 , Foresight News
In early 2022, there is a discussion about the potential centralization of block building and the impact of PBS (proposer/builder separation) after MEV and block ordering. I personally resonate with this concern and have published an article exploring the risks of centralization. The community is divided on this issue, with some embracing the idea of a decentralized network of validators and a more centralized block builder for Ethereum, as Vitalik Buterin wrote in "EndgameReportReportfirst level title
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 type of centralization can compromise these attributes. I will list the main issues and explain why some are important and some are not.
Exclusive order flow:Both Flashbots and the community are actively discussing how exclusive order flow can lead to a single block builder monopolizing winning bids and order flow. Consistently win auctions, assuming builders provide incentives such as MEV sharing, private transactions, and MEV backrun guarantees to collect order streams inaccessible to others to build higher value blocks. However, I think it's too broad a question to group all types of incentives that lead to exclusivity, so I've divided them into the following subcategories: Exclusive order flow via MEV redistribution and Exclusive order flow via MEV backrun guarantees, private transactions . Note that these subcategories are not mutually exclusive and have different meanings.
MEV redistribution: This concern may become less relevant as more order flow marketplaces are launched in the coming years. Market competition is intensifying and they will need to offer more MEV rebates through order flow auctions to attract users and transactions. This competition will ultimately affect where users choose to submit transactions.
Private transactions and MEV backrun guarantees: This is an optional feature that some may prefer. However, using this type of exclusive order flow can lead to order flow centralization if it is to grow at scale. To mitigate this, it would be beneficial for decentralized block builders to consistently propose higher value blocks.
Censorship:Insufficient decentralization of block builders can lead to a subset of builders colluding and censoring transactions. AlthoughcrListimage description
Average success rate of top five block builders
The top three block builders collectively controlled 60% of the total number of successfully submitted blocks during the month, indicating that a great deal of trust needs to be placed on their behavior of not colluding or censoring transactions. To address this, implementing a framework that decentralizes the block building process will increase the cost of collusion and censorship, enabling a more trustless block production system.
image description
Block success rate graph
The graph illustrates block success rates before and after the merge over time. Notably, it can be seen that Flashbots (in dark blue) have reduced their block success rate and reached a similar equilibrium point as other major block builders, rather than fully dominating block production. This contradicts the proposed centralization due to network effects, and there could be multiple explanations for this result.
Exclusive order flow for competitors: Other competing builders may have exclusive order flow (private transactions, etc.) that produce higher value blocks.
Order Flow Congestion: Too many orders want to be included in a block by Flashbots, causing delays. This could force users to place transactions between multiple builders to increase their chances of being committed in a block, especially during times of high traffic.
OFAC Compliance: Flashbots are OFAC compliant, while others are not. Users may decide to choose a builder based on some regulatory issues.
Flashbots open-sources the builder and relay code to attract more competition.
first level title
What are we decentralizing?
The power of block production is the key to decentralization. Rather than delegating full control of block building to one entity, there is 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 are not mutually exclusive.
Proposers participate in block construction
Decentralize block builders with new architecture and algorithm, allowing competitive block production (large design space)
first level title
Method 1: Proposer participates in block production
Currently there areseveral methodsherehere。
image description
Construction block process diagram, source Eigenlayer
The PBS system enhances Ethereum's censorship resistance by limiting the authority of validators to proposals for higher value blocks. However, Eigenlayer proposed a MEV governance framework called MEV+, which allows block proposers to include additional transactions on top of existing blocks. This is achieved by imposing additional slashing conditions.
image description
Schematic diagram of proposer participating in block generation, source Eigenlayer
This mechanism also works well in conjunction with crList, which is a list of transactions that a proposer must include in a block. This helps reduce the possibility of transactions being censored at the builder level. While other solutions have been proposed, such as pre-commitments to Merkle roots or KZG commitments to allow proposers to participate in block production, EigenLayer provides a simpler alternative that does not require additional computing resources from proposers, And can participate in block production at the same time.
first level title
Approach 2: Decentralized block builders
Designing decentralized block builders is a fascinating area to explore, and teams like Flashbots are already experimenting with different designs. When considering how to decentralize builders, it is important to be aware of the following challenges:
MEV Stealing: Builders can access information in bundle transactions submitted by Seekers and steal MEV from Seekers. To prevent this, the privacy of submitted bundles and transactions should be protected by design.
Suboptimal MEV: Ideally, builders should be decentralized while maintaining optimal MEV. Due to decentralization, some designs may lead to inefficient block construction and lead to a reduction in the MEV of the block, which in turn leads to a decrease in block competitiveness. But it could also be argued that suboptimal block production is acceptable as long as decentralized builders attract more order flow than other builders.
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 centralized order flow among centralized builders.
Latency: Block production is time sensitive and can have significant latency issues.
Jurisdiction (resistance to censorship): Decentralized builders should be spread across multiple jurisdictions so they are resistant to judicial scrutiny (like OFAC). Regulation is still a gray area in most countries and one does not want to risk the builder network being taken down by a single regulatory entity.
With these challenges in mind, I would like to discuss the proposed decentralized builder designs across the research community and delve into some of the potential issues surrounding them. Currently, there are two main types of decentralized builders:
Seeker-Aggregator model: Seekers submit bundles of transactions, and Aggregators will build blocks without knowing much/any information about the submitted bundle.
Slot auction model: block space is auctioned sequentially, blocks are gradually built by multiple builders, and there is no aggregator.
secondary title
Design 1: Seeker-Aggregator Model Using TEE/TPM
image description
Diagram of TEE-based block builder, source Vitalik
Flashbots published aprogress report, describing 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 takeaways from the experiment:
Running Geth in SGX is feasible, but resource intensive and time consuming, requiring a lot of 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 information disclosure from side-channel attacks, covert-channel attacks, and other programming errors.
There is a trade-off between performance and resources. For example, less resource-intensive methods perform poorly and may have more severe information leakage problems.
Additionally, there are other issues to consider when using SGX:
There are somemethodThe information leakage problem can be mitigated, but some methods may cause performance degradation, requiring more trial and error to hone the best performing framework to run SGX.
The complex setup and scarcity of SGX-compatible chips lead to a high barrier to entry. Cloud service providers may provide SGX accessibility and can be used as a temporary solution, but in the long run, cloud operators will be an important centralizing factor.
SGX leaks are still a problem. If one finds other exploitable vulnerabilities in SGX, the aggregator should immediately perform its own TCB recovery (the process designed to re-instantiate the SGX environment), rather than waiting for a response from Intel, which can take a long time.
Unlike centralized builders, decentralized builders should in principle welcome and encourage aggregation of order flows. Assuming zero information leakage, the searcher-aggregator model should have trust-minimum security, trusting that encryption and SGX work flawlessly. However, it may have a high degree of credible activity where only a few entities run aggregators, which is possible because bundles are naturally aggregated to the most successful aggregators. In this case, there will be no censorship issues in the order flow/bundles, but there may be liveness issues.
If the number of entities running aggregators is small, there may be insufficient geographic distribution leading to skewed jurisdictions, making the network more vulnerable to regulatory scrutiny.
secondary title
Design 2: Seeker-Aggregator Model with Threshold Encryption and ZK-SNARK
image description
Schematic diagram of block generator based on TE and ZKP
There is potential for collusion between aggregators and proposers in this design. Threshold encryption ensures the privacy of bundles only before the state root is computed, and the aggregators that compute the state root require access to transaction information or state updates. This access enables MEV theft by tracking the corresponding transactions. This design removes the need for a TEE/TPM, but it cannot prevent such collusion without adding additional complexity, such as requiring proposers to commit to blocks before allowing the decryption of the state root to be computed. Here are some problems with this type of design:
Proposers' early commitment to blocks can be achieved through re-staking infrastructure (such as Eigenlayer), but incurs additional operational costs, as ETH stakers need to be sufficiently incentivized to balance the associated slashing conditions.
Proposers may miss out on blocks of higher value by submitting a block early.
The added computational overhead and latency of generating ZK-SNARKs and threshold encryption makes this model potentially infeasible in practice.
Regarding the question of who will be the eligible keyholders for the threshold encrypted package, if a Seeker holds the key, an attacker masquerading as a Seeker can prevent decryption and delay block production. Conversely, aggregators cannot hold keys, since each of them is competing for block production and could be incentivized to block other aggregators. This may require a third party, neither a searcher nor an aggregator, and introduce additional trust assumptions that may reduce the trustless/trust-minimized properties of a decentralized builder.
secondary title
Design 3: A slot auction model based on chaotic iterative search
image description
Schematic diagram of block builder based on slot auction
The design aims to allow multiple block builders to participate in building a single block by dividing the block's maximum gas into n slots, given x builders, where n = f(x) and n
When a crypto slot is made public will determine the efficiency of the auction (the closer the bid is to the corresponding MEV, the more efficient the auction will be, since MEV will be the "true" price of the slot). If crypto slot N-1 is public before the slot N auction, then the auction will be efficient as builders will be able to bid based on their expected MEV. However, this can present latency issues in practice, as the strictly sequential auction and decryption of slots can take some time. Therefore, another option is to have builders pre-bid for the right to build blocks for all slots, and to decrypt blocks sequentially as builders fill slots. Auctions can be inefficient since builders don't know the MEV of a slot before bidding (the transactions in slot N-1 need to be known to determine MEV for slot N), and builders can even be careless due to lack of realized MEV Overbidding for slots. However, this problem can be mitigated by performing a statistical analysis of the historical bid prices for slots at a given location in the block.
To prevent builders from modifying transactions in previous slots, other builders must act as witnesses and provide some form of fraud proof.
When the slots are decrypted in order, the centralized builder can steal some MEV. If users only submit order flow through this network of builders based on slot auction, then MEV stealing problem is not so serious, but if order flow is submitted through centralized builders and this network of builders, then MEV stealing may be problematic .
secondary title
Design 4: Sequential Slot Auction with Proposer Commitments
first level title
Perspectives on the future of block construction
Decentralization is an important aspect of blockchain technology, and ensuring that block builders are decentralized is critical. In this article, we discuss several possible approaches to decentralizing block builders. However, this remains an open design space for the research community to explore and collaborate.
Designing a competitive decentralized block builder requires a lot of experimentation, and teams like Flashbots are already exploring SGX and other privacy-enabling technologies. However, more innovation and research are needed to realize the full potential of these technologies.
Overall, decentralizing block builders is an ongoing challenge that requires the collaboration and expertise of the broader research community beyond cryptocurrencies. Through experimentation, testing, and innovation, we can strive to create a decentralized, competitive block builder that enhances the network's censorship resistance.
