On January 4th, Ethereum founder Vitalik Buterin posted on social media, stating, "With ZK-EVM entering its alpha phase (performance has reached production-grade levels, with the remaining main work focused on security) and PeerDAS already launched on the mainnet, we will delve into the implications of this combination for Ethereum. This is not a minor improvement; they are transforming Ethereum into a fundamentally new and more powerful decentralized network.
BitTorrent (2000) has extremely high overall bandwidth and is highly decentralized, but lacks a consensus mechanism. Bitcoin (2009) is highly decentralized and has consensus, but has low bandwidth—because it doesn't achieve 'distribution' by splitting work, but by replicating it. Now, with the addition of PeerDAS (2025) and ZK-EVM (expected to have limited network usage starting in 2026), Ethereum simultaneously possesses: decentralization, consensus, and high bandwidth. The Ethereum trilemma has been solved, not just in papers, but through running code." Half of this (data availability sampling) is already running on the mainnet today, and the other half (ZK-EVM) has reached production-grade performance. The main remaining issue is security.
Over the next four years, this vision can be expected to unfold gradually: • 2026: Due to BALs and ePBS, the gas cap independent of ZK-EVM will increase significantly, and we will also see the first opportunities to run ZK-EVM nodes; • 2026–2028: Gas repricing, state structure adjustments, execution payloads entering blobs, and other adjustments to provide security guarantees for higher gas caps; • 2027–2030: As ZK-EVM becomes the primary way to validate blocks on the network, the gas cap will see a further significant increase.
The third component of this vision is distributed block building. A long-term ideal is that complete blocks should never be built entirely in a single location. Even until this stage is reached, we hope that substantial power in block building is distributed as much as possible. This can be achieved through in-protocol methods (e.g., by extending FOCIL to become the primary channel for transactions to enter blocks) or out-of-protocol methods, such as distributed builder markets. Doing so reduces the risk of centralized interference in real-time transaction packaging and also creates a better environment for geographical fairness. (Source: BlockBeats)