Vitalik Buterin envisioned 2026 as the year Ethereum reverses a decade of compromises in favor of convenience. His argument was that the protocol remained trustless, but the defaults varied. The wallet outsourced validation to a centralized RPC.
Decentralized applications have become server-dependent behemoths that leak user data to dozens of endpoints. Block construction is concentrated in the hands of a small number of sophisticated actors. The base layer was kept, but the experience was now completely different.
The response is a specific menu of infrastructure fixes designed to make the path of least trust the easy path.
A verified RPC client that turns untrusted providers into locally verifiable endpoints. Obtaining personal information to hide query content from the servers users query. Inclusion lists that enforce fork selection, allowing for structurally enforced resistance to censorship. Block-level access lists make nodes run cheaper and faster.
Additionally, Kohaku is the Ethereum Foundation’s wallet delivery vehicle for turning protocol research into default user behavior.
Helios and local RPC issues
Currently, Ethereum wallets route almost everything through a remote procedure call provider, a centralized service that answers queries about balances, status, and transaction status.
Helios, a light client built with a16z cryptography, transforms data from untrusted RPCs into verifiable, secure local RPCs. It syncs in about 2 seconds, runs a local JSON-RPC server on port 8545, and supports Ethereum and OP Stack networks such as Optimism and Base.
Rather than blindly trusting what is returned by a remote server, Helios verifies cryptographic proofs and provides locally verified data.
The trade-off is clear. Helios still relies on weak subjectivity checkpoints for bootstrapping and relies on upstream execution endpoints for certain data paths. Trust declines, but it doesn’t disappear.
However, what’s important is not verifiability as a hobbyist stance, but verifiability as the default user experience. When wallets have a verified light client path embedded by default, RPC decentralization becomes a feature that users experience rather than a technical setting that needs to be configured.
The Kohaku Wallet initiative, backed by the Ethereum Foundation, clearly plans to integrate and ship Helios.
PIR, ORAM, metadata leakage issues
Private payments are useless if every balance check or dapp interaction leaks metadata to the server that can monetize access patterns.
Personal Information Capture and Oblivious RAM are encryption tools designed to hide what you query from providers. Vitalik’s Privacy Roadmap outlines the transition from a trusted execution environment to PIR as the final step for private reads.
The Privacy and Scaling Explorations team articulates the challenges of scale. A trie with approximately 33 million leaves is approximately 1 gigabyte, and PIR aims to bring the per-query bandwidth down to the kilobyte range, with significant computational trade-offs on the server side.
This is still research and early engineering. Languages around 2026 will need to present PIR and ORAM as trajectories and prototypes, not as what users currently have.
But the positive perspective is structural, and private reads are the missing half of the privacy user experience.
Kohaku’s roadmap explicitly includes a privacy service abstraction as a first-phase deliverable, indicating that wallet-side tools for private reads are moving from theory to implementation.
FOCIL and forced inclusion
Builder centralization is the most visible setback in Ethereum’s transaction inclusion guarantees. Resistance to censorship decreases when a small number of sophisticated builders dominate block production and inclusion depends on their cooperation.
Fork selection forced inclusion list, formalized as EIP-7805, is a structural counterpart.
A committee of 16 validators creates an inclusion list, a small batch of transactions that must be included in the next block. Constructors and proposers who ignore the list face a fork selection penalty. That is, the authenticator will not vote for blocks that violate inclusion constraints.
The maximum size per inclusion list is 8 kilobytes.
FOCIL is clearly motivated by the builder advantage. The rationale for EIP states that a small number of builders controlling block production reduces censorship resistance, and inclusion lists enforced by fork selection allow validator sets to enforce inclusion even when block construction is centralized.
This mechanism becomes more important as private transaction flows, such as account abstractions and private memory pools, become more common. Without structural containment guarantees, these flows are susceptible to censorship at the builder layer.
FOCIL is currently in draft form and the EIP clearly discusses bandwidth and denial of service issues that still need to be resolved.
Block-level access list and synchronization issues
Running a node went from easy to difficult as the state grew and the cost of running went up.
Block-level access lists, formalized as EIP-7928, are a mechanism that reduces node execution costs and speeds up synchronization.
This block records accessed accounts and storage slots with post-state values, enabling parallel disk reads, parallel transaction validation, parallel state root computation, and execution-free state updates.
Early benchmarks widely circulated on the Ethereum Magicians thread report around 30% improvement in live syncing with Geth using early BAL variants, but the results are preliminary.
Client teams treat BAL as a priority. Besu’s tracking issue labels EIP-7928 as related to Gramsterdam (a generic term for Ethereum’s expected 2026 upgrade buckets) and explains why it is important for parallel execution and snap sync repair.
BAL is boring infrastructure, but boring infrastructure is what will drive Ethereum back to running a node.
Kohaku and reference implementation
Kohaku is an effort by the Ethereum Foundation to turn protocol research into the default for wallets. The third protocol update describes Kohaku as an SDK and reference wallet for power users, starting with a browser extension to reduce trust assumptions.
The first phase ships with the Helios light client, privacy service abstraction, private address, private balance and sending flows.
The roadmap makes it clear that the reference wallet is not consumer-facing, but rather a fork of Ambire designed to demonstrate what privacy by default and verified RPC by default looks like in practice.
The roadmap also explicitly lists native account abstraction as a dependency and says the team will be working towards it in 2026.
Amber is the “realizing” layer. If verified RPC, private reads, and more secure recovery patterns remain in research papers and EIPs, they won’t change user behavior. The baseline changes when shipped as a default wallet feature in an open source SDK that other wallets can adopt.
Verification without reruns
Zero-knowledge Ethereum virtual machine proofs at layer 1 are often framed as scaling stories, but the Ethereum Foundation’s zkEVM site frames them as a decentralized protection mechanism.
All validators are currently validating the chain by re-executing all transactions. In the zkEVM world, validators instead verify cheap proofs, moving from N-of-N executions to 1-of-N proofs.
The central challenge is to prove a complete block within a 12 second slot, and the zkEVM research roadmap treats incentives and resistance to censorship as a primary concern.
This is why Vitalik bundles zkEVM and BAL together to “make full nodes easier.” If proof is cheap and verification is cheap, the cost of trustless participation goes down.
When the prover market becomes concentrated, the trust problem reoccurs at another layer. The zkEVM roadmap explicitly addresses that risk as a core workstream.
| trust cut | What broke (default drift) | Correction (mechanism) | Specific specifications/numbers (from text) | situation | Key trade-offs/risks |
|---|---|---|---|---|---|
| Helios (Verified RPC) | default wallet Trust centralized RPC For reads (balance/status), change “verify” to opt-in. | light client Verify data from an untrusted upstream, local RPC. | ~2 seconds sync, Local JSON-RPC:8545use Weak subjectivity checkpoint. | live/available | There is still a need bootstrapping trust (weak subjectivity) upstream execution endpoint For some paths. |
| Private Read (PIR/ORAM) | Dapp usage status leaked Metadata and access patterns to RPC and middleware (even if the payment is private). | Encryption/system technology Hide what you asked From the server (PIR/ORAM). | ~33M leaf ≈ ~1GB tryPIR target KB/Queryand heavy server-side computing. | Research / Early prototypes | Costs include servers (computing), engineering complexity, and perhaps Latency and UX trade-offs In the initial deployment. |
| Fosil (EIP-7805) | Concentrated on block construction. Guarantees of inclusiveness have become dependent and weakened on a small number of actors. Resistance to censorship actually. | Forcing fork selection inclusion list: The commission will publish transactions that need to be included, and failure to block them will result in penalties. | Committee = 16 people, Maximum inclusion list = 8 KiB. | Draft (EIP) | New DoS/Bandwidth Surface. There must be strict limits on the sizing, dissemination, and enforcement of committees and lists. |
| BAL (EIP-7928) | As state/execution costs increased, nodes became harder to run. Increased synchronization/validation burden. | Block-level access list: Record access state + enable post-state Parallelization and No executions Update the path. | “State updates without execution”; Early claims: Up to 30% improvement in live sync on Geth (preliminary). | Prototype/EIP in progress | Extra data/complexity. “30%” means spare;Actual benefits will depend on client adoption and finalization of specifications. |
| Kohaku (wallet execution track) | Even great protocol research won’t change the reality if wallets continue to default to centralized infrastructure + leaky UX. | EF support SDK + Reference Wallet Ship “Trust Cut” as follows: default (RPC + privacy plumbing verified). | “Included with Helios”,”Privacy service abstraction”,”Native AA dependencies (functional until 2026)”. | Prototype/Roadmap | It’s not consumer-oriented. Deployment relies on SDK + native AA timeline integration with other wallets. |
| zkEVM in L1 | Verification requires Rerun with all validatorscosts rise and trust-minimized participation is pushed out of reach. | shift from N-of-N execution → 1-of-N proof;Validators validate cheap proofs instead of re-running them. | prove within range 12 seconds slot;risk: Concentration of the prover market Recreate the central choke point. | Research/Roadmap | Hard real-time proof constraints + incentive design. As markets become more centralized, “trust” can shift to the proof layer. |
what this means
The base scenario for 2026 is that Verified RPC becomes an option for wallets, BAL progresses through client prototypes, and FOCIL remains in draft until risks are better limited.
The acceleration scenario is that Gramsterdam lands with BAL, wallets integrate verified RPC by default, and “trust in RPC” is no longer an implicit assumption.
The risk scenario is that zkEVM and the prover market grow but become concentrated, recreating the centralized relay at the proof layer and allowing the migration without resolving the trust issue.
Although Vitalik’s message was directed at Ethereum’s builder community, the conduits he described are the same ones that determine whether self-sovereignty and trustlessness are characteristics of the protocol or marketing claims.
The setback was real. The reversal has begun.
(Tag translation) Ethereum
