Ethereum founder Vitalik Buterin has responded to recent claims by Ethereum team lead Péter Szilágyi, “karalabe.eth,” regarding the alleged centralization of the Ethereum network.

Szilágyi claimed in an X post that PeerDAS was the direction Ethereum was being taken into with the next forks, intending to raise, although not immediately, the blobs up to a staggering 32MB.

In his words, Szilágyi feels that Ethereum is “losing the plot,” claiming that the research team “fully embraced the idea to centralize everything as long as it can be verified.” This, he thinks, is a cute charade of decentralized validation but centralized control.

Szilágyi’s claims that “the the research team fully embraced the idea to centralize everything as long as it can be verified” caught the attention of Ethereum founder Vitalik Buterin, who flagged this as false.

Buterin highlighted that the Ethereum team had been deeply engaged in discussions aimed at minimizing centralization, not promoting it.

Efforts to minimize centralization

Buterin listed several key discussions and suggestions aimed at minimizing centralization, which include deep analysis of multi-proposer and determining if the builder role can be eliminated.

The Ethereum team also shared ideas around making the fork choice depend on transaction inclusion while maximizing the power of the inclusion lists (FOCIL).

Other suggestions include an analysis of Orbit single slot finality (SSF) and thoughts around accelerating deployment of the Orbit mechanism, which has the potential to reduce minimum deposit sizes by roughly tenfold before single slot finality is realized. SSF is still in the research phase.

An Ethereum block takes approximately 15 minutes to finalize. However, research is being conducted to improve the efficiency with which Ethereum’s consensus mechanism validates blocks and significantly decreases time-to-finality. Instead of waiting 15 minutes, blocks could be proposed and finalized in the same slot. This concept is referred to as single-slot finality (SSF).

Other suggestions highlighted by Buterin in his X post include distributed block building for PeerDAS, networking analysis and bandwidth optimization of PeerDAS and fullDAS, ways to make recovery from 51% attacks more partially-automated and rely less on “the social layer” and ensuring inclusion lists apply fully to blobs and native-account-abstracted transactions, for instance EIP-7560.