Ethereum may finally kill “trust me” wallets in 2026, and Vitalik says the fix is already shipping
Vitalik Buterin framed 2026 as the year Ethereum reverses a decade of convenience-first compromises. His thesis: the protocol stayed trustless, but the defaults drifted. Wallets outsourced verification to centralized RPCs.
Decentralized applications became server-dependent behemoths that leak user data to dozens of endpoints. Block building is concentrated in the hands of a few sophisticated actors. The base layer held, but the experience became something else entirely.
The response is a concrete menu of infrastructure fixes designed to make the trust-minimized path the easy path.
Verified RPC clients that turn untrusted providers into locally verifiable endpoints. Private information retrieval to hide what users query from the servers they query. Fork-choice-enforced inclusion lists that make censorship resistance structurally enforceable. Block-level access lists make running a node cheaper and faster.
Additionally, Kohaku is the Ethereum Foundation's wallet-delivery vehicle for turning protocol research into default user behavior.
Helios and the local RPC problem
Ethereum wallets today route nearly everything through remote procedure call providers: centralized services that answer queries about balances, state, and transaction status.
Helios, a light client built by a16z crypto, converts data from an untrusted RPC into a verifiably safe local RPC. It syncs in roughly 2 seconds, runs a local JSON-RPC server on port 8545, and supports Ethereum and OP Stack networks like Optimism and Base.
Instead of blindly trusting what a remote server returns, Helios verifies cryptographic proofs and serves locally verified data.
The trade-off is explicit: Helios still relies on weak subjectivity checkpoints for bootstrapping and leans on an upstream execution endpoint for certain data paths. It reduces trust, but does not erase it.
However, the point is verifiability as a default user experience, not as a hobbyist stance. If wallets embed a verified light client path by default, RPC decentralization becomes a feature users experience rather than a technical preference they have to configure.
The Kohaku wallet effort, backed by the Ethereum Foundation, explicitly plans to ship with Helios integrated.
PIR, ORAM, and the metadata leak problem
Private payments are useless if every balance check and dapp interaction leaks metadata to servers that can monetize access patterns.
Private information retrieval and oblivious RAM are the cryptographic tools designed to hide what users query from the providers they query. Vitalik's privacy roadmap outlines a progression from trusted execution environments toward PIR as the endgame for private reads.
The Privacy and Scaling Explorations team clearly frames the scale challenge: a trie with roughly 33 million leaves is about 1 gigabyte, and PIR aims to bring bandwidth per query down to the kilobyte range, with significant server-side computational trade-offs.
This is still research and early engineering. The language around 2026 should present PIR and ORAM as trajectories and prototypes, rather than as something users have today.
Yet, the forward-looking angle is structural: private reads are the missing half of the privacy user experience.
The Kohaku roadmap explicitly includes privacy-service abstraction as a first-phase deliverable, signaling that wallet-side tooling for private reads is moving from theory to implementation.
FOCIL and enforceable inclusion
Builder centralization is the most visible backslide in Ethereum's transaction inclusion guarantees. A few sophisticated builders dominate block production, and censorship resistance degrades when inclusion depends on their cooperation.
Fork-choice-enforced inclusion lists, formalized as EIP-7805, are the structural response.
A committee of 16 validators produces inclusion lists, which are small batches of transactions that must be included in the next block. Builders and proposers who ignore the list face a fork-choice penalty: attesters will not vote for blocks that violate inclusion constraints.
The maximum size per inclusion list is eight kilobytes.
FOCIL is explicitly motivated by builder dominance. The EIP's rationale states that a few builders controlling block production degrade censorship resistance, and that inclusion lists enforced by fork choice allow the validator set to force inclusion even when block building is centralized.
The mechanism matters more as private transaction flows, such as account abstraction and private mempools, become common, because those flows are easier to censor at the builder layer if no structural inclusion guarantee exists.
FOCIL is currently a draft, and the EIP explicitly discusses bandwidth and denial-of-service concerns that still need to be resolved.
Block-level access lists and the sync problem
Running a node went from easy to hard as the state grew and execution costs climbed.
Block-level access lists, formalized as EIP-7928, are plumbing that makes nodes cheaper to run and faster to sync.
The block records which accounts and storage slots were accessed, along with post-state values, enabling parallel disk reads, parallel transaction validation, parallel state root computation, and executionless state updates.
A widely circulated early benchmark in the Ethereum Magicians thread reports a roughly 30% improvement in live sync with Geth using an initial BAL variant, though the result is preliminary.
Client teams are treating BALs as a priority. A Besu tracking issue labels EIP-7928 as related to Glamsterdam, the umbrella term for Ethereum's anticipated 2026 upgrade bucket, and describes why it matters for parallel execution and snap-sync healing.
BALs are boring infrastructure, but boring infrastructure is what nudges Ethereum back toward “running a node is normal.”
Kohaku and the reference implementation
Kohaku is the Ethereum Foundation's effort to turn protocol research into wallet defaults. The third Protocol Update describes Kohaku as an SDK plus a power-user reference wallet, starting with a browser extension to reduce trust assumptions.
The first phase ships with a Helios light client, privacy-service abstraction, private addresses, and private balance and send flows.
The roadmap clarifies that the reference wallet is not consumer-oriented, but rather a fork of Ambire designed to demonstrate what privacy-by-default and verified-RPC-by-default look like in practice.
The roadmap also explicitly lists native account abstraction as a dependency and states that the team will work toward it in 2026.
Kohaku is the “make it real” layer. If verified RPC, private reads, and safer recovery patterns stay in research papers and EIPs, they do not change user behavior. If they ship as default wallet features in an open-source SDK that other wallets can adopt, they shift the baseline.
Verification without re-execution
Zero-knowledge Ethereum Virtual Machine proofs on layer-1 are often framed as a scaling story, but the Ethereum Foundation's zkEVM site frames them as a decentralization protection mechanism.
Today, every validator re-executes every transaction to verify the chain. In a zkEVM world, validators verify a cheap proof instead, shifting from N-of-N execution to 1-of-N proving.
The core challenge is proving a full block within the 12-second slot, and the zkEVM research roadmap treats incentives and censorship resistance as first-class concerns.
That is why Vitalik bundles “full nodes get easier” with zkEVM and BALs in the same breath. If proving is cheap and verification is cheaper, the cost of trustless participation drops.
If the prover market concentrates, the trust problem reappears at a different layer. The zkEVM roadmap explicitly treats that risk as a core workstream.
| Trust cut | What broke (default drift) | Fix (mechanism) | Concrete spec/number (from your text) | Status | Key tradeoff / risk |
|---|---|---|---|---|---|
| Helios (verified RPC) | Wallets defaulted to trusting centralized RPCs for reads (balances/state), turning “verify” into an opt-in. | Light client that verifies data from an untrusted upstream and serves it as a local RPC. | ~2s sync, local JSON-RPC :8545, uses weak subjectivity checkpoints. | Live / usable | Still needs bootstrapping trust (weak subjectivity) and may rely on an upstream execution endpoint for some paths. |
| Private reads (PIR / ORAM) | Dapp usage leaks metadata and access patterns to RPCs and middleware (even if payments are private). | Cryptographic/system techniques to hide what you queried from the server (PIR/ORAM). | ~33M leaves ≈ ~1GB trie, PIR targets KB/query, with heavy server-side compute. | Research / early prototypes | Cost shifts to servers (compute), engineering complexity, and likely latency/UX tradeoffs in early deployments. |
| FOCIL (EIP-7805) | Block building concentrated; inclusion guarantees became dependent on a few actors, weakening censorship resistance in practice. | Fork-choice enforced inclusion lists: committee publishes transactions that must be included or blocks get penalized. | Committee = 16, max inclusion list = 8 KiB. | Draft (EIP) | New DoS/bandwidth surfaces; committee + list sizing, propagation, and enforcement need tight bounds. |
| BAL (EIP-7928) | Running a node got harder as state/execution costs rose; syncing/verification burdens drifted upward. | Block-level access lists: record accessed state + post-state to enable parallelization and executionless update paths. | “Executionless state updates”; early claim: ~30% live sync improvement (prelim) on Geth. | Prototype / EIP in progress | Extra data/complexity; “30%” is preliminary; real gains depend on client adoption + spec finalization. |
| Kohaku (wallet execution track) | Even good protocol research doesn’t change reality if wallets keep defaulting to centralized infra + leaky UX. | EF-backed SDK + reference wallet to ship “trust cuts” as defaults (verified RPC + privacy plumbing). | “Ships with Helios”, “privacy-service abstraction”, “native AA dependency (work through 2026)”. | Prototype / roadmap | Not consumer-oriented; adoption depends on other wallets integrating the SDK + native AA timelines. |
| zkEVM on L1 | Verification requires re-execution by every validator, raising costs and pushing trust-minimized participation out of reach. | Shift from N-of-N execution → 1-of-N proving; validators verify cheap proofs instead of re-executing. | Prove within 12-second slot; risk: prover market concentration recreates central chokepoints. | Research / roadmap | Hard realtime proving constraint + incentive design; “trust” can migrate to the proving layer if markets centralize. |
What this means
The baseline scenario for 2026 is that verified RPC becomes a wallet option, BALs advance through client prototypes, and FOCIL stays in draft until risks are better bounded.
The acceleration scenario is that Glamsterdam lands with BALs, wallets integrate verified RPC by default, and “RPC trust” stops being a silent assumption.
The risk scenario is that zkEVM and prover markets scale but concentrate, recreating centralized relays at the proving layer and shifting the trust problem without solving it.
Vitalik's message was aimed at Ethereum's builder community, but the pipes he described are the same ones that determine whether self-sovereignty and trustlessness are protocol properties or marketing claims.
The backslide was real. The reversal is starting.
The post Ethereum may finally kill “trust me” wallets in 2026, and Vitalik says the fix is already shipping appeared first on CryptoSlate.
