Ethereum 2026: The End of "Trust Me" Wallets is Near!
Vitalik Buterin has framed 2026 as a pivotal year for Ethereum, marking a turning point after a decade of prioritizing convenience over core principles. His core thesis? While the Ethereum protocol has remained fundamentally trustless, the user experience has drifted towards reliance on centralized services. Wallets routinely outsource verification to centralized RPC providers, decentralized applications (dApps) have become server-dependent behemoths leaking user data, and block building is concentrated in the hands of a few powerful actors. The base layer has held strong, but the overall experience has become increasingly centralized. This isn't a failure of the protocol itself, but a consequence of the compromises made for usability. Now, a concrete plan is emerging to reverse this trend, making the trust-minimized path the easy path.
The Problem: A Drift Towards Centralization
For many Ethereum users, the experience isn't as decentralized as they believe. Nearly all wallet interactions rely on Remote Procedure Call (RPC) providers – centralized services that provide data about the blockchain. This creates a single point of failure and a potential privacy risk. Furthermore, dApps often depend on centralized servers, negating the benefits of a decentralized backend. This reliance on centralized infrastructure undermines the core promise of Ethereum: self-sovereignty and trustlessness.
The RPC Problem: Helios and Verified Clients
Ethereum wallets today almost universally route requests through centralized RPC providers. This means trusting these providers to accurately report balances, state, and transaction status. Helios, a light client developed by a16z crypto, offers a solution. It converts data from potentially untrusted RPCs into locally verifiable data. Syncing takes approximately 2 seconds, and it runs a local JSON-RPC server on port 8545, supporting both Ethereum and OP Stack networks like Optimism and Base.
Instead of blindly trusting a remote server, Helios verifies cryptographic proofs, ensuring data integrity. While it still relies on weak subjectivity checkpoints for bootstrapping and upstream execution endpoints for certain data, it significantly reduces trust assumptions. The key is making verifiability the default user experience. If wallets embed a verified light client path by default, RPC decentralization becomes a feature users experience, not a technical configuration.
The Ethereum Foundation’s Kohaku wallet project is explicitly designed to integrate Helios, signaling a commitment to this approach.
The Metadata Leak Problem: PIR and ORAM
Even if transactions are private, every balance check and dApp interaction can leak metadata to servers, potentially revealing user behavior and patterns. Private Information Retrieval (PIR) and Oblivious RAM (ORAM) are cryptographic tools designed to address this issue by hiding what users query from the servers they interact with. Vitalik’s privacy roadmap envisions PIR as the ultimate solution for private reads.
The Privacy and Scaling Explorations team highlights the scale challenge: a trie with roughly 33 million leaves requires about 1 gigabyte of storage, and PIR aims to reduce bandwidth per query to the kilobyte range. This requires significant server-side computational resources. While still in the research and early engineering phases, the goal is to make private reads a standard part of the user experience. Kohaku’s roadmap includes privacy-service abstraction as a first-phase deliverable, demonstrating a move from theory to implementation.
Infrastructure Fixes: Building a More Trustless Ethereum
The response to the centralization drift isn't just theoretical; it's a concrete menu of infrastructure improvements designed to make trust-minimized interactions the default.
FOCIL (EIP-7805): Enforcing Inclusion
Builder centralization is a major concern, as a few sophisticated actors dominate block production, potentially leading to censorship. Fork-choice-enforced inclusion lists (FOCIL), formalized as EIP-7805, aim to address this. A committee of 16 validators produces inclusion lists – small batches of transactions that must be included in the next block. Builders and proposers who ignore these lists face a fork-choice penalty, meaning attesters won't vote for blocks that violate inclusion constraints.
The maximum size per inclusion list is eight kilobytes. FOCIL is motivated by the need to counteract builder dominance and ensure censorship resistance, especially as private transaction flows like account abstraction become more common. However, it’s currently a draft EIP, and concerns remain regarding bandwidth and potential denial-of-service attacks.
BAL (EIP-7928): Making Nodes Accessible
Running a full Ethereum node has become increasingly difficult due to the growing state size and execution costs. Block-level access lists (BAL), formalized as EIP-7928, aim to make nodes cheaper and faster to run. BALs record which accounts and storage slots were accessed, along with post-state values, enabling parallel disk reads, parallel transaction validation, and executionless state updates.
Early benchmarks suggest a roughly 30% improvement in live sync with Geth using a BAL variant. Client teams are prioritizing BALs as part of the Glamsterdam upgrade, recognizing their importance for parallel execution and snap-sync healing. This infrastructure improvement is crucial for making “running a node” a normal and accessible practice.
Kohaku: The Wallet Delivery Vehicle
Kohaku, backed by the Ethereum Foundation, is the effort to translate protocol research into default wallet behavior. It’s an SDK plus a power-user reference wallet, starting with a browser extension designed to reduce trust assumptions. The first phase will ship with a Helios light client, privacy-service abstraction, private addresses, and private balance and send flows.
The reference wallet isn’t intended for mainstream consumers but serves as a demonstration of what privacy-by-default and verified-RPC-by-default look like in practice. It’s a fork of Ambire and explicitly lists native account abstraction as a dependency, with work planned for 2026. Kohaku is the “make it real” layer, ensuring that these improvements aren’t just theoretical but become tangible user experiences.
zkEVM: Shifting the Verification Burden
Zero-knowledge Ethereum Virtual Machine (zkEVM) proofs on layer-1 are often discussed as a scaling solution, but the Ethereum Foundation frames them as a decentralization safeguard. Currently, every validator re-executes every transaction to verify the chain. With zkEVM, validators would verify a cheap proof instead, shifting from N-of-N execution to 1-of-N proving.
The challenge lies in proving a full block within the 12-second slot. The zkEVM research roadmap prioritizes incentives and censorship resistance. If proving is cheap and verification is even cheaper, the cost of trustless participation drops dramatically. However, a concentrated prover market could recreate centralization at a different layer, highlighting the need to address this risk proactively.
Looking Ahead: The 2026 Reversal
Here's a breakdown of the key initiatives and their current status:
| What broke (default drift) | Fix (mechanism) | Concrete spec/number | Status | Key tradeoff / risk |
|---|---|---|---|---|
| Wallets defaulted to trusting centralized RPCs | Helios (verified RPC) | ~2s sync, local JSON-RPC :8545 | Live / usable | Bootstrapping trust, upstream endpoint reliance |
| Dapp usage leaks metadata | Private reads (PIR / ORAM) | ~33M leaves ≈ ~1GB trie, PIR targets KB/query | Research / early prototypes | Server compute cost, engineering complexity |
| Builder centralization | FOCIL (EIP-7805) | Committee = 16, max inclusion list = 8 KiB | Draft (EIP) | DoS/bandwidth concerns |
| Rising node costs | BAL (EIP-7928) | “Executionless state updates”, ~30% sync improvement (prelim) | Prototype / EIP in progress | Data complexity, adoption dependency |
| Research doesn’t translate to user experience | Kohaku | Helios integration, privacy-service abstraction | Prototype / roadmap | SDK adoption, native AA timelines |
| Re-execution burden on validators | zkEVM on L1 | N-of-N → 1-of-N proving | Research / roadmap | Prover market concentration |
The baseline scenario for 2026 is verified RPC becoming a wallet option, BALs advancing through client prototypes, and FOCIL remaining in draft. The acceleration scenario involves Glamsterdam landing with BALs, wallets integrating verified RPC by default, and “RPC trust” becoming a thing of the past. The risk scenario is zkEVM scaling but centralizing, recreating relays at the proving layer.
Vitalik Buterin’s message is aimed at the Ethereum builder community, but the underlying infrastructure determines whether self-sovereignty and trustlessness are core properties or merely marketing claims. The drift towards centralization was real. The reversal is underway.
Mentioned in this article: Ethereum, a16z, Ethereum Foundation, Vitalik Buterin