Ethereum co-founder Vitalik Buterin believes that proof-of-stake (POS) centralization poses a significant threat to Ethereum. In POS centralization, large stakes dominate and small stakes participate in a large pool.
Centralization increases the risk of issues such as 51% attacks and transaction censorship. Additionally, there is the risk of value extraction, where a small group benefits at the expense of Ethereum users.
According to Buterin, the risk exists in building blocks and providing staking capital.
problem
Ethereum follows a Proposer-Builder Separation (PBS) protocol for block construction. This means that the work is split between validators, who propose blocks and conduct auctions and are responsible for selecting the contents of blocks, and builders, who organize transactions into blocks and place bids.
Buterin pointed out:
“While this separation of powers helps keep validators decentralized, there is one important trade-off: actors performing “specialized” tasks can easily become highly centralized. It means that there is a gender.
Data as of October 2024 shows that only two builders are responsible for 88% of Ethereum blocks. This means that if these two builders decide to censor a transaction, there could be delays. Transactions can now take an average of 114 seconds to process instead of 6 seconds. While delays may not affect specific trades, builders could manipulate the market by delaying emergency trades, such as during decentralized finance (DeFi) liquidations.
Therefore, the concentration of power could pose a serious threat to the integrity of Ethereum.
solution
According to Buterin, one of the best solutions to avoid centralization is to further subdivide the responsibility for block generation. Buterin suggested that the task of selecting transactions should be returned to the proposer, or staker, and the constructor would only be able to choose the order of transactions and insert some of his own transactions. I am. This can be achieved through inclusion lists.
This is how it works. Randomly selected stakers create an inclusion list containing valid transactions. Block builders must include all transactions in the inclusion list while creating a block, but have the power to rearrange them and add their own transactions.
Another possible solution is a multiple concurrent proposer (MCP) scheme like BRAID. According to Buterin, “BRAID avoids splitting the role of block proponents into parts with low economies of scale and parts with high economies of scale, and instead seeks to distribute the block production process among many actors. In this way, each proponent can maximize their profits with only a moderate amount of knowledge.
Buterin pointed out that encrypted memory pools are a key technology needed to implement the design changes mentioned above. Encrypted memory pools allow users to broadcast their transactions in encrypted form with proof of validity. Transactions are also included in blocks in encrypted form. The builder doesn't know what it is. The deal will only be revealed later.
Buterin writes that the main challenge in implementing encrypted memory pools is ensuring the design ensures that transactions are later revealed. This can be achieved through two techniques: (i) threshold decryption and (ii) delayed encryption.
mentioned in this article
