Vitalik Buterin said he no longer agrees with his 2017 tweet that downplayed the need for users to personally verify Ethereum end-to-end.
This week, he argued that the network should consider self-hosted verification as a non-negotiable loophole, as its architecture becomes lighter and more modular.
Buterin’s original position arose from a design debate over whether a blockchain should commit to maintaining state on-chain or treat state as “implicit”, reconstructable only by repeating ordered transactions.
Ethereum’s approach, by placing a state root in each block header and supporting Merkle-style proofs, allows a user to prove a specific balance, contract code, or storage value without rerunning the entire history, provided the user accepts the consensus validity of the chain under an honest majority assumption.
The idea that average users personally validate the entire history of the system is a strange man-mountain fantasy. There, I said it. (2017)
In his new post, Buterin called this compromise incomplete in practice, because it may still force users to choose between replaying the full chain or trusting an intermediary such as an RPC operator, an archive data host, or a proof service.
I no longer agree with my previous tweet – since 2017 I have become a much more willing mountain connoisseur (…) We don’t need to start living in the Mountain Man’s cabin every day. But part of maintaining Ethereum’s infinite garden is certainly keeping the shed well-maintained. (2026)
Vitalik U-turns on personal blockchain history verification
He anchored the change on two axes: feasibility and fragility.
Regarding feasibility, Buterin wrote that zero-knowledge proofs now offer a way to verify correctness without “literally rerunning every transaction.”
In 2017, he argued that this would have pushed Ethereum into lower capacity to keep verification within reach.
This change is important because Ethereum’s public roadmap increasingly treats ZK as a verifiability primitive, with ethereum.org framing zero-knowledge proofs as a way to preserve security properties while reducing what a verifier must calculate.
Work on the “ZK-light-client” directions also points to a model in which a device can synchronize using compact proofs rather than trusting an always-on gateway.
Regarding fragility, Buterin listed failure modes that fall outside of specific threat models: degraded p2p networks, closure of long-term services, concentration of validators which modifies the practical meaning of “honest majority” and informal governance pressure which transforms “call the developers” into a safety net.
He cited censorship pressure around Tornado Cash as an example of how intermediaries can restrict access, arguing that a user’s last resort option should be to “use the channel directly.”
This framework is part of a broader discussion about strengthening Ethereum’s base layer and limiting churn, amid a push toward “ossification” of the protocol.
According to Buterin, the “mountain cabin” is not a default way of life.
This is a credible fallback that shifts incentives because knowing users can exit reduces the leverage of any service layer.
This argument arises as Ethereum shrinks what ordinary nodes are expected to store, while the network’s verification story must keep pace.
Ethereum client usage and history
Execution clients are moving toward partial history expiration, and the Ethereum Foundation has stated that users can reduce disk usage by approximately 300 to 500 GB by deleting pre-merge block data, thereby putting a handy node on a 2 TB disk.
At the same time, thin clients already reflect a formalized trust model optimized for low-resource devices, relying on a synchronization committee of 512 validators selected approximately every 1.1 days.
These settings make thin client verification feasible at scale.
However, they also focus the user experience on ensuring the availability of correct data and high-performance relays when conditions deteriorate.
Ethereum’s long-term work on “statelessness” aims to reduce the need for nodes to hold large state while keeping block validation intact.
Ethereum.org cautions that “statelessness” is a misnomer, distinguishing weaker forms from stronger designs that remain researched, including state expiration.
Verkle trees lie inside this plan because they reduce the size of proofs and are positioned as a key step enabling validation without storing large state locally.
As the storage load shifts outward, either to specialized history hosts or to other data networks, the security question becomes less about who can store it all, and more about who can independently verify accuracy and recover what they need if a default path fails.
| What changes | Why it is important for verification | Parameter or concrete figure |
|---|---|---|
| Support for partial history expiration in runtime clients | Less local storage may increase reliance on external history availability unless recovery and verification paths remain open | Disk reduction of approximately 300 to 500 GB, “comfortable” on a 2 TB disk |
| Lightweight PoS customer trust model | Low-resource verification relies on committee signatures and data availability through peers or services | Synchronization committee of 512 validators, rotates approximately every 1.1 days |
| Verkle Trees as a Stateless Client Tool | Smaller proofs can make validation with less stored state more practical | Roadmap Framing Links Verkle Trees to Stateless Validation Goals |
| Statelessness Roadmap Distinctions | Separates short-term approaches from research elements such as state expiration | Terminology relating to weak or strong statelessness |
| EF’s work on L1 zkEVM security foundations | The rigor and stability of the proof system is now part of Ethereum’s core security story | Emphasis on stabilization and preparation for formal verification |
What this means for the future
Over the next 12 to 36 months, the practical question is whether verification will expand as Ethereum outsources more storage loads, or whether trust will coalesce around new service choke points.
One solution is for wallets and infrastructure to move from “trust the RPC” to “verify the proof”, as proof production consolidates into a small set of optimized stacks that are difficult to replicate, shifting dependency from one class of provider to another.
Another path is for evidence-based verification to become mainstream, with redundant proof implementations and tools that allow users to switch providers or verify locally when an endpoint censors, degrades, or disappears, thereby aligning with efforts toward lightweight verification flows.
A third path is that pruning and scalability advance faster than UX verification, leaving users with fewer practical options in the event of outages or censorship events.
This would make the “mountain hut” operationally real for only a restricted part of the network.
Buterin presented the cab as the BATNA of Ethereum, rarely used but always available, because the existence of a standalone option constrains the conditions imposed by intermediaries.
He concluded by saying that maintaining this fallback is part of maintaining Ethereum itself.
