Vitalik Buterin lays down roadmap to minimize centralization risk in Ethereum POS design

Ethereum co-founder Vitalik Buterin believes that the centralization of proof-of-stake (POS) poses a significant threat to Ethereum. POS centralization is where large stakers dominate and small stakers join large pools.

Centralization increases the risk of problems like 51% attacks and transaction censorship. Additionally, there’s the risk of value extraction, where a small group benefits at the cost of Ethereum users.

According to Buterin, the risk exists in block construction and staking capital provision.

The problem

Ethereum follows the protocol of proposer-builder separation (PBS) for block construction. This means that the job is divided between the validators, who propose blocks and auction off the responsibility of choosing block contents, and builders, who organize transactions into a block and place bids.

Buterin noted:

“This separation of powers helps keep validators decentralized, but it has one important cost: the actors that are doing the “specialized” tasks can easily become very centralized.”

Data as of October 2024 indicates that only two builders are responsible for 88% of Ethereum blocks. This means that if these two builders decide to censor a transaction, it can cause a delay—processing of the transaction can take an average of 114 seconds instead of 6 seconds. While the delay may not affect certain transactions, the builders can manipulate the market by delaying urgent transactions, like those during decentralized finance (DeFi) liquidations.

Therefore, the concentration of power can pose serious threats to the integrity of Ethereum.

Solutions

According to Buterin, one of the best solutions to avoid centralization is to further break down the responsibilities of block production. Buterin proposes that the task of choosing transactions should go back to the proposer, or staker, and the builder will only get to choose the ordering of the transactions, and insert some of their own. This can be achieved through inclusion lists.

This is how it would work. A randomly selected staker creates an inclusion list, which includes valid transactions. A block builder, while creating a block, is required to include all the transactions in the inclusion list, but has the power to rearrange them and add their own transactions.

Another possible solution is multiple concurrent proposers (MCP) schemes like BRAID. According to Buterin, “BRAID seeks to avoid splitting up the block proposer role into a low-economies-of-scale part and a high-economies-of-scale part, and instead tries to distribute the block production process among many actors, in such a way that each proposer only needs to have a medium amount of sophistication to maximize their revenue.”

Buterin noted that encrypted mempools are a crucial technology required to implement the above stated design changes. Using encrypted mempools, users can broadcast their transactions in an encrypted format along with proof of their validity. The transactions are also included in the blocks in encrypted form—the builder does not know the contents. The transactions are only revealed later.

Buterin wrote that the main challenge of implementing encrypted mempools is ensuring a design where the transactions are definitely revealed later. This can be achieved through two techniques: (i) threshold decryption, and (ii) delay encryption.

Mentioned in this article