TechFlow news, on January 4th, Ethereum founder Vitalik Buterin posted on social media stating that with ZK-EVMs entering the alpha stage (performance has reached production level, with the main remaining work focusing on security) and PeerDAS already live on the mainnet, he will delve deeply into discussing what this combination means for Ethereum. These are not minor improvements; they are transforming Ethereum into a fundamentally new and more powerful decentralized network.
BitTorrent (2000) had extremely high overall bandwidth and was highly decentralized, but lacked a consensus mechanism. Bitcoin (2009) was highly decentralized with consensus, but had very low bandwidth—because it did not achieve "distribution" by splitting work, but by replicating it. Now, with the addition of PeerDAS (2025) and ZK-EVMs (expected to see initial network usage starting in 2026), Ethereum simultaneously possesses: decentralization, consensus, and high bandwidth. The impossible trilemma has been solved, not just in theory, but through running code. Half of it (data availability sampling) is already operational on the mainnet today, while the other half (ZK-EVMs) has reached production-level performance, with the main remaining issue being security.
Over the next approximately 4 years, we can expect this vision to gradually unfold: · 2026: Due to BALs and ePBS, the gas limit without relying on ZK-EVMs will significantly increase, and we will also see the first opportunities to run ZK-EVM nodes; · 2026–2028: Gas repricing, state structure adjustments, execution payloads moving into blobs, and other adjustments to secure higher gas limits; · 2027–2030: As ZK-EVMs become the primary method for the network to validate blocks, the gas limit will see further substantial increases.
The third component of this vision is distributed block building. A long-term ideal goal is that complete blocks are never fully assembled in a single location. Even before reaching that stage, we want the substantive power in block building to be as decentralized as possible. This can be achieved through in-protocol methods (for example, expanding FOCIL to become the main channel for transactions entering blocks) or through out-of-protocol methods, such as a distributed builder market. Doing so reduces the risk of centralized forces intervening in real-time transaction packaging and also creates a better environment for geographic fairness.
