Context and Chronology

On Feb. 27, Ethereum protocol lead Vitalik Buterin published a public sketch tying two architectural changes to a larger multi‑year engineering strawmap: (1) a binary state representation proposed under EIP-7864 aimed at shrinking historical Merkle branches and (2) a staged migration path toward a RISC‑V–aligned execution environment to reduce prover translation costs. Buterin framed the work as architectural rather than incremental, positioning it alongside other roadmap items such as parallel block validation, storage repricing, and post‑quantum (PQ) preparations that core teams are sequencing into 2026 coordination points (commonly discussed as Glamsterdam in H1 2026 and a later Hegota fork).

On the state layer, the binary-tree proposal is expected to reduce Merkle branch length materially—practical estimates in design notes show roughly a ~4x contraction relative to today’s tree formats—while swapping hash families (e.g., Blake3 or, after audits, algebraic hashes such as Poseidon) can multiply prover gains. At the extreme, different hash choices and prover architectures produce projecting improvements ranging from ~3x up to ~100x for some proving workloads; those bounds are workload- and implementation-dependent and contingent on secure primitive selection and audit outcomes.

For execution, Buterin outlined a three-stage approach: limit RISC‑V to precompiled primitives, permit user-deployed RISC‑V contracts, then subsume the legacy EVM into the new runtime as a contract. The goal is to align the runtime ISA with what many modern ZK provers already use, lowering translation overhead and simplifying prover stacks. Core teams have counterproposals that favor WASM (or a WASM delivery layer) to preserve broader language/tooling compatibility and to separate the proving ISA from the delivery ISA; the tension highlights two distinct optimization philosophies—proof‑native efficiency versus ecosystem compatibility.

Buterin’s notes sit within a larger set of technical vectors public planning documents and core developers have circulated: parallel validation and block-construction edits to increase effective payload per slot, fee‑reweighting that raises the cost of permanent storage while easing transient compute friction, expanded use of detachable data units ("blobs"), and explicit pruning or “garbage collection” of legacy behaviors. These measures are coupled to governance and legal questions (for example, inclusion‑enforcement proposals like EIP-7805 and account‑abstraction work such as EIP-8141) that could change validator responsibilities and create operational or regulatory exposure if not carefully specified.

Operationally, adoption requires synchronized, cross‑client coordination: client teams must adopt new execution patterns for parallel validation, auditors must vet any new hash families and ISA transitions for security and PQ-resilience, and prover vendors will need to retool compilers and toolchains. The roadmap also references numeric ambitions debated in planning channels—gas ceilings floated past ~100,000,000 (some discussions near ~180,000,000), long‑run L1 throughput targets when coupled with ZK proving in the ~10,000 tps band, and slot/finality compression ambitions toward single‑digit seconds—each target carrying non‑linear propagation, prover and PQ dependencies. If implemented successfully, these changes could lower rollup verification costs and light‑client bandwidth; if miscoordinated, they risk specialization and supplier concentration, legal friction from inclusion mechanisms, and migration burdens for existing applications.