Kaustinen testnet relaunch updates for Ethereum Verkle trees

The Kaustinen testnet relaunch modifies the SuffixStateDiff container by omitting the new_value field. Developers also added the ExecutionWitness directly to the Bellatrix ExecutionPayload without a fork implementation. Geth optimizes the implementation, while Besu uses a Java-based version of Verkle libraries. Lighthouse and Lodestar participate in this testnet. Developers also consider EIP-4762 to manage statelessness gas cost changes. The new EIP-7545 proposes a precompile to verify Verkle proofs. This precompile simplifies the process for dApps and bridges. Keys in these trees consist of 31-byte stems and 1-byte suffixes. Verkle Gen Devnet starts at a Verkle-genesis state, while regular Verkle devnets start at a Shapella-genesis state.

Implementation lags persist.

Current Verkle implementations run 40% slower than Merkle Patricia Trees. This speed deficit remains a hurdle for widespread adoption. Developers focus on reducing witness sizes to allow validators to process blocks within a 12 second slot. The current Merkle trie witness for 1,000 leaves requires 3.5 MB of data. Verkle trees reduce this requirement to 150 kB. This represents a 23x reduction in data. Verkle trees use 256-way branching to create shallower trees. This structure reduces the number of levels between a leaf and the root.

The consensus for the conversion strategy favors migrating a set number of values per block rather than per slot. This strategy simplifies the move from Merkle Patricia Trees to Verkle trees. Conversion lags persist. Because the transition from Merkle Patricia Trees to Verkle Trees requires a state migration that touches every account and contract on the network, engineers must ensure the process remains bulletproof. The transition to Verkle trees is a bottleneck. Erigon completes the conversion in 18 hours, but other implementations take much longer. This inefficiency complicates the move toward stateless clients.

Reducing the storage burden on node operators remains a priority. Current Ethereum nodes require over 50 GB for state data alone. This requirement can exceed 150 GB when including all Merkle proofs. Verkle trees could slash these requirements by roughly 90%. A Merkle proof requires all sibling nodes along the path to the root. This creates large data transfers. Verkle proofs only require the path and minimal proof data. This difference is why Verkle trees enable statelessness. Verkle trees use polynomial commitments, specifically KZG commitments, to replace standard hashing. This allows the tree to commit to many values at once. A prover provides a proof that a polynomial evaluates to a specific value at a given point. This mechanism allows the tree to be much flatter.

Hegota and the binary tree pivot

The Hegota upgrade targets the second half of 2026 to finalize the Verkle migration. Earlier, the Glamsterdam upgrade in the first half of 2026 begins the transition. You probably know that quantum resistance now drives much of the core developer discussion. EIP-7864 proposes a binary state tree built from hash functions to solve quantum risks associated with elliptic curve cryptography. This design competes with the Verkle implementation.

Developers must account for gas changes in the Hegota upgrade. Storage slots 0-63 will cost 200 gas instead of 2100 gas. Adjacent storage slots also drop from 2100 to 200 gas. This change favors sequential storage patterns. Glamsterdam introduces parallel transaction processing and pushes the gas limit from 60 million toward 200 million per block.

The implementation of FOCIL under EIP-7805 selects 17 participants at random per slot to enforce transaction inclusion. This prevents builders from excluding valid transactions. This feature reduces the concentration of power in a small number of relay operators. As of March 2026, over 1.1 million active validators secure Ethereum. The validator entry queue has reached approximately 60 days. This queue length reflects the massive demand for staking. The consensus of 17 participants ensures that no single builder controls the block content.

Account abstraction through EIP-8141 aims to make smart contract wallets first-class citizens. This allows for multisignature authorization and gas sponsorship. Users can choose programmable wallets to manage fees. The 23x reduction in witness size is the primary economic argument for the switch. This reduction helps keep the network decentralized.

Does the community favor the binary tree?

The lack of testing with shadow forks leaves uncertainty regarding how the implementation behaves in real-world scenarios.