The Frontier launch and the path to Ethereum statelessness

The Genesis of Frontier

The Frontier launch in July 2015 provided a barebones implementation for technical users. Developers worked with a hardcoded gas limit per block of 5,000 during the first few days of the network. This "thawing" period allowed miners to start operations before a software update raised the limit to 3 million. The Ethereum Foundation used the Olympic testnet to push the network toward 25 transactions per second before the mainnet went live. I clearly prefer this period because it allowed early adopters to form a live ecosystem through direct experimentation. Vitalik Buterin outlined his vision at the 2014 North American Bitcoin Conference. Early investors raised about $18 million in BTC through an ICO later that year. Gavin Wood helped create the Solidity coding language to turn the whitepaper into reality. While the network launched in 2015, the community faced a crisis in 2016 when hackers stole $50 million worth of ETH from the DAO smart contract. This theft prompted a contentious fork that created the Ethereum Classic chain. Initially, Ethereum miners used computers with graphics processing units (GPUs) rather than ASIC rigs. Following that event, the Byzantium Fork of 2017 reduced the block reward from five ETH to three ETH.

The Verkle Tree Shift

Verkle trees solve the storage problem that the Merkle Patricia Trie created for Ethereum nodes. Full nodes currently require 4 to 8 TB of storage, while archive nodes approach 12 TB. Because Verkle trees use polynomial math to shrink proof sizes by 23x compared to Merkle trie witnesses, they allow for much faster verification. In a scenario with 1,000 leaves, a Merkle trie witness requires 3.5 MB of data, but a Verkle tree witness needs only 150 kB of space to verify the inclusion. This reduction makes it possible for a phone or a Raspberry Pi to verify blocks without a local state database. You already know that high disk space requirements prevent universal access to nodes. One significant downside remains the heavy CPU load required to open polynomial commitments over elliptic curve points.

Verkle trees treat an address as a set of coordinates by splitting the key into a 31-byte stem and a 1-byte suffix. Each node in the tree contains up to 256 slots, which allows the structure to be much shallower than a Merkle tree. The MapToScalarField function acts as a translator to ensure child commitments fit into the parent vector. This process ensures that a single vector commitment can cover a whole account’s balance, nonce, and code hash at once. This width reduction means a verifier only needs to navigate 3 or 4 floors to find a specific room in the data hotel. Why did the transition to Verkle trees take so many years of research to reach the mainnet?

The Fusaka Era

The Fusaka upgrade on December 3, 2025, moved the network closer to statelessness. This hard fork raised the block gas limit from 45 million to 60 million. It introduced PeerDAS and Verkle Trees to manage the extra data load without burdening node operators. PeerDAS lets validators check small, randomly sampled pieces of data from different network peers instead of downloading entire data blobs. This follows the Pectra upgrade that occurred in May 2025. The Ethereum Foundation offered a bug bounty of up to $2 million for critical vulnerabilities ahead of the Fusaka launch.

The upgrade also aids Layer 2 rollups because they post transaction data in blob format. PeerDAS enables more efficient sampling of those blobs, which reduces operating costs for rollup operators and lowers fees for users who use Layer 2 networks. The Ethereum Foundation scheduled testnet deployments on Holesky on October 1, 2025, Sepolia on October 14, 2025, and Hoodi on October 28, 2025, to prepare all network validators for the mainnet activation. The current roadmap includes Glamsterdam in 2026 to follow the Fusaka rollout. This next step will introduce Enshrined Proposer-Builder Separation and Block-level Access Lists to improve performance.