Vitalik Buterin lays down roadmap to minimize centralization risk in Ethereum POS design
Vitalik Buterin has suggested possible design changes that could potentially lower the risks of centralization.
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 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 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 DeFi liquidations.
Therefore, the concentration of power can seriously threaten Ethereum’s integrity.
Solutions
According to Buterin, one of the best solutions to avoid centralization is to break down block production responsibilities further. Buterin proposes that the task of choosing transactions should go back to the proposer or staker, and the builder will only get to select 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 design changes above. 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.