Introduction
Vitalik Buterin has articulated a vision for the year 2026, positing it as a pivotal moment for Ethereum—a year in which the protocol will endeavor to reverse the cumulative effects of a decade characterized by convenience-centric compromises. The crux of his thesis suggests that while Ethereum has maintained its trustless nature, the operational defaults have gradually become less decentralized. Specifically, the reliance on centralized Remote Procedure Calls (RPCs) for transaction verification has significantly altered the landscape.
The Current Landscape of Decentralization
Decentralized applications (dApps), initially conceived to embody the principles of decentralization, have evolved into server-dependent entities that expose user data to numerous endpoints. While the foundational layer of Ethereum has remained intact, the user experience has deviated markedly from its original ethos.
In response, Buterin has proposed a series of infrastructural enhancements aimed at making trust-minimized pathways the default choice for users. This comprehensive framework includes:
- Verified RPC clients that transform untrusted providers into locally verifiable endpoints.
- Private Information Retrieval (PIR) mechanisms to obscure user queries from the servers engaged.
- Fork-choice-enforced inclusion lists that structurally enforce censorship resistance.
- Block-level access lists designed to enhance cost-efficiency and speed in node operation.
The Kohaku Initiative
Furthermore, the Kohaku initiative has emerged as the Ethereum Foundation’s strategic vehicle for translating protocol research into standard user behavior. This effort aims to solidify the integration of these infrastructural improvements within user wallets.
The Helios Framework and Local RPC Challenges
Contemporary Ethereum wallets predominantly depend on centralized RPC providers for nearly all data-related queries, including balances, state information, and transaction statuses. In this context, Helios—a light client developed by a16z crypto—represents a transformative approach by enabling users to convert data from untrusted RPCs into verifiably secure local RPCs. Helios offers rapid synchronization, achieving this in approximately two seconds while supporting both Ethereum and OP Stack networks such as Optimism and Base.
Rather than passively accepting responses from remote servers, Helios employs cryptographic proofs to validate data locally. However, it is crucial to note that this solution entails certain trade-offs:
- Helios utilizes weak subjectivity checkpoints for initial bootstrapping.
- It relies on upstream execution endpoints for specific data paths.
The overarching goal is to embed verifiability as a standard component of user experience, thereby transforming what constitutes decentralized infrastructure into an intuitive feature rather than an optional configuration. The Kohaku wallet endeavor is set to incorporate Helios by default, ensuring that the benefits of verified RPC are seamlessly integrated into user interactions.
PIR and ORAM: Addressing Metadata Leaks
The efficacy of private payments is severely undermined if every interaction with decentralized applications inadvertently exposes metadata to servers capable of monetizing user behavior patterns. To counteract this vulnerability, Private Information Retrieval (PIR) and Oblivious RAM (ORAM) serve as complementary cryptographic solutions designed to conceal user queries from their respective providers. Buterin’s privacy roadmap delineates a clear progression from trusted execution environments toward PIR as the ultimate objective for safeguarding private reads.
The Privacy and Scaling Explorations team has explicitly framed the scale challenges associated with implementing PIR: a trie comprising approximately 33 million leaves translates to around 1 gigabyte of data, with PIR striving to reduce query bandwidth requirements to the kilobyte range—albeit at substantial computational costs on the server side. It is essential to recognize that both PIR and ORAM remain areas of active research and early engineering; thus, they should be regarded as developmental trajectories rather than present-day solutions. Nevertheless, it is evident that private reads represent a critical component in enhancing user privacy experiences.
The Kohaku roadmap distinctly prioritizes privacy-service abstraction as an initial deliverable, indicating tangible progress toward equipping wallets with tools necessary for facilitating private reads.
FOCIL: Enforceable Inclusion Mechanisms
A notable concern within the Ethereum ecosystem is builder centralization, which poses significant risks to transaction inclusion guarantees. Currently, a small cadre of sophisticated builders wields disproportionate control over block production, thereby compromising censorship resistance when inclusion is contingent upon their cooperation. To address this issue, Fork-choice-enforced Inclusion Lists (FOCIL), formalized as EIP-7805, provide a structural remedy.
This mechanism involves a committee of 16 validators tasked with generating inclusion lists—small batches of transactions mandated for inclusion in forthcoming blocks. Builders who disregard these lists face penalties within the fork-choice protocol: attesters will abstain from endorsing blocks that contravene established inclusion constraints. The maximum permissible size per inclusion list is capped at eight kilobytes.
The motivation behind FOCIL is explicitly rooted in counteracting builder dominance; it seeks to fortify censorship resistance through structural mechanisms that compel compliance even amid concentrated block building. As private transaction flows become more commonplace—such as account abstraction and private mempools—this mechanism’s importance escalates because these flows are inherently more susceptible to censorship without robust structural guarantees for inclusion.
Block-Level Access Lists: Mitigating Synchronization Challenges
The operational complexity associated with running an Ethereum node has significantly escalated as state size and execution costs have surged over time. Block-level access lists, formalized through EIP-7928, aim to streamline node operation by facilitating faster synchronization processes and reducing associated costs.
This mechanism records which accounts and storage slots have been accessed within each block alongside post-state values, thereby enabling parallel disk reads, transaction validation processes, state root computations, and executionless state updates. Preliminary benchmarks suggest potential improvements of approximately 30% in live synchronization performance using an initial variant of block-level access lists with Geth; however, further testing is necessary to validate these findings comprehensively.
Client teams are prioritizing block-level access lists due to their pivotal role in restoring normalcy to node operation within the Ethereum ecosystem. For example, a tracking issue documented by Besu designates EIP-7928 as integral to Glamsterdam—an umbrella term encompassing anticipated upgrades slated for implementation in 2026—highlighting its significance for parallel execution capabilities and synchronization restoration efforts.
Kohaku: Advancing Reference Implementations
Kohaku represents the Ethereum Foundation’s concerted effort to transition protocol research into practical wallet defaults. The third Protocol Update characterizes Kohaku as both a software development kit (SDK) and a reference wallet targeting power users; its initial phase will unveil browser extension capabilities designed to minimize trust assumptions among users.
The first phase includes critical components such as:
- An integrated Helios light client
- A privacy-service abstraction layer
- Mechanisms for private addresses and secure balance transfers
It is imperative to note that while the reference wallet serves not as a consumer product but rather as a prototype derived from Ambire—demonstrating what privacy-by-default and verified-RPC-by-default would entail—it nonetheless lays essential groundwork for broader adoption. Furthermore, native account abstraction is explicitly identified as a dependency within Kohaku’s roadmap, indicating ongoing efforts throughout 2026 toward its realization.
Verification Without Re-execution: zkEVM Implications
The introduction of zero-knowledge Ethereum Virtual Machine (zkEVM) proofs on layer-1 is often framed primarily through the lens of scalability; however, the Ethereum Foundation’s zkEVM initiative also underscores its role as a mechanism for enhancing decentralization protections. Currently, every validator must re-execute all transactions for chain verification purposes. In contrast, zkEVM enables validators to verify succinct proofs instead—transitioning from N-of-N execution paradigms toward 1-of-N proving methodologies.
A critical challenge lies in proving an entire block within the prescribed 12-second slot; consequently, incentives and censorship resistance are paramount concerns addressed within zkEVM’s research roadmap. This interrelationship underscores why Vitalik juxtaposes “easier full nodes” with zkEVM and block-level access lists; if proving becomes cost-effective while verification remains inexpensive, then barriers hindering trustless participation will diminish accordingly.
Summary Table: Trust Mechanisms Overview
| Trust Cut | Broke (Default Drift) | Fix (Mechanism) | Concrete Spec/Number (from your text) | Status | Key Tradeoff / Risk |
|---|---|---|---|---|---|
| Helios (verified RPC) | Wallets defaulted to trusting centralized RPCs. | Light client that verifies data from an untrusted upstream. | ~2s sync; local JSON-RPC :8545; uses weak subjectivity checkpoints. | Live / usable | Still needs bootstrapping trust (weak subjectivity). |
| PIR / ORAM (private reads) | Dapp usage leaks metadata and access patterns. | Crytographic techniques like PIR/ORAM. | PIR aims for Kb/query bandwidth efficiency. | Research / early prototypes | Carries engineering complexity and potential latency trade-offs. |
| EIP-7805 (FOCIL) | Censorship resistance eroded by block building centralization. | Presents fork-choice enforced inclusion lists. | |||
| EIP-7928 (BAL) | Deterioration in node usability due to rising execution costs. | Implements BAL technology for enhanced syncing efficiency. | |||
| Kohaku Initiative | |||||
