← All articles

Unpacking Vitalik's Protocol Roadmap: From ZK Hashing to Distributed Block Building

@0x3hu79
@0x3hu79
April 11, 2026 · Protocol Design
#account-abstraction#FOCIL#ZK#block-building#ePBS#RISC-V

In late February 2026, Ameen Soleimani kicked off a debate by calling out Ethereum for lacking native Poseidon support - a ZK-friendly hash function that Solana, StarkNet, Stellar, Mina, and Polygon zkEVM all ship at the VM level. Vitalik responded with what turned into a multi-post deep dive across four major areas of Ethereum’s protocol evolution: cryptographic primitives, account abstraction, execution layer changes, and the block building pipeline.

These posts are dense and scattered across platforms. This article unpacks them into something more digestible, with attention to what these changes mean in practice - especially for those building and operating block production infrastructure.

1. The Poseidon Debate: Why Ethereum Hasn’t Shipped a ZK-Friendly Hash

The Criticism

Ameen’s argument is simple: Ethereum talks about “privacy by default” but doesn’t have the basic primitive - a ZK-friendly hash function at the VM level - that makes privacy protocols efficient onchain. Five other chains already do. EIP-5988 (a Poseidon precompile for Ethereum) is still in research, with a cryptanalysis initiative running through 2026.

He’s not wrong about the gap. If you want to verify a ZK proof onchain and that proof involves hashing (most do), implementing Poseidon in Solidity is prohibitively expensive in gas. A native precompile would drop costs dramatically.

Vitalik’s Response: Don’t Hardcode What You Haven’t Finished Studying

Vitalik pushes back with a surprisingly practical argument. Ethereum has been running a cryptanalysis program on Poseidon2 for nearly two years and found real security issues - solvable by adding rounds or reverting to Poseidon1, but real nonetheless. Had Ethereum already shipped a precompile, they’d be stuck with a specific (possibly insecure) version baked into the protocol permanently.

This is the precompile trap: once deployed, a precompile can never be removed. It becomes permanent complexity that every client must implement. Ship the wrong version and you’re left with either a dangerous primitive or a dead one that still costs engineering effort to maintain forever.

The Alternative: A “GPU for the EVM”

Instead of a precompile for one specific hash, Vitalik proposes something more general: a vectorized math precompile that does 32-bit (or 64-bit) operations on lists of numbers simultaneously. Think numpy for the EVM.

Why this is better than a single-hash precompile:

One general-purpose feature that benefits ZK, post-quantum crypto, and FHE simultaneously. That’s a better return on protocol complexity than a single precompile.

For block builders, the vectorized precompile is worth watching closely. ZK proof verification gas costs directly affect the economics of transactions involving privacy protocols and ZK rollup proof submissions. When this ships, the gas profile of ZK-heavy transactions changes significantly - they become cheaper, which means more of them, which means gas estimation and simulation need to be updated accordingly.

2. Account Abstraction: Frame Transactions (EIP-8141)

A Decade in the Making

Account abstraction has been discussed since EIP-86 in 2016. The problem: Ethereum has two account types - externally owned accounts (EOAs, controlled by a private key) and smart contracts - and EOAs are painfully limited. You can’t change your key, can’t use multisig, can’t batch operations, can’t pay gas in tokens other than ETH, can’t use quantum-resistant signatures.

Every workaround so far (ERC-4337, smart wallets) has been extra-protocol, adding complexity and - critically - intermediaries.

EIP-8141 (“Frame Transactions”) aims to solve this at the protocol level.

How It Works

The concept is surprisingly simple. A transaction becomes N ordered calls (“frames”) that can:

That’s the entire protocol-level mechanism. Everything else is application logic built on top.

Walking Through the Use Cases

A normal transaction (from a multisig, an account with rotatable keys, or one using a quantum-resistant signature scheme):

The validation frame can use any signature scheme because it’s just a smart contract. Want ed25519? Lattice-based? Multisig? Just write the verification logic.

First-time account deployment prepends a deployment frame that creates the smart contract account via a factory. EIP-7997 (deterministic factory) ensures consistent addresses across chains - solving a real pain point for smart wallets today.

Paying gas in a token (e.g., RAI):

The key detail: the paymaster is an onchain DEX, not an off-chain service. No relayer. No API key. No intermediary. If every piece of infrastructure except Ethereum itself goes down, this still works. Vitalik calls this “non-ugly cypherpunk ethereum” - maximizing what you can do even if all external infrastructure disappears.

Privacy protocol transactions get two approaches:

  1. A paymaster contract that verifies a ZK-SNARK and pays gas if valid - the user never needs ETH in a linkable wallet
  2. 2D nonces that let a single contract act as a privacy pool, receiving parallel transactions from many users

This eliminates “public broadcasters” - the relayer intermediaries that privacy protocols like Railgun currently require. Users can submit privacy transactions directly to the public mempool. That removes a massive UX friction point and a centralization/censorship vector.

The Mempool Safety Question

If validation frames could execute arbitrary code, an attacker could craft a transaction whose validity depends on thousands of external contract states. When any of those states change, the transaction becomes invalid - wasting CPU on every node that validated it. Classic denial-of-service.

The solution is layered mempool rules:

This mirrors Bitcoin’s “standard transactions” concept - the chain itself accepts anything valid, but the mempool gossip layer is more selective.

Timeline

Vitalik says Frame Transactions can ship in the Hegota fork, framed as “within a year” - roughly targeting late 2026 or early 2027.

Block builders should start thinking about this now. Frame Transactions fundamentally change what a “transaction” looks like. Multi-frame validation, paymasters, and privacy transactions become first-class protocol objects. Transaction pool management, simulation, and gas estimation all need to handle these new structures. The interaction with FOCIL (covered below) adds another dimension - AA transactions forced in by inclusion lists create new constraints for block construction.

3. Execution Layer: Deep Structural Changes

Binary State Trees (EIP-7864)

Ethereum currently stores all account state in a hexary (16-branch) Merkle Patricia Trie hashed with keccak. EIP-7864 replaces this with a binary tree using a more efficient hash function (either blake3 or a Poseidon variant).

The benefits stack up:

4x shorter Merkle proofs. Binary trees produce proofs with 32 * log(n) bits vs. hexary’s 512 * log(n) / 4. This makes light clients like Helios 4x cheaper in bandwidth, and makes PIR (private information retrieval) more viable.

3-100x better proving efficiency. 3-4x from shorter branches, multiplied by the hash function improvement: blake3 gives roughly 3x over keccak, a Poseidon variant could give 100x (pending more cryptanalysis).

Cheaper access for adjacent storage slots. The binary tree groups slots into “pages” (64-256 slots, roughly 2-8 kB). An account’s block header and first ~1-4 kB of code and storage live in the same page. Many contracts today load heavily from their first few storage slots - think of a Uniswap pool reading token addresses, fee tiers, liquidity, and tick state in a single swap. With pages, after loading the first slot, subsequent reads from the same page are nearly free. Vitalik estimates >10,000 gas savings per transaction for many dapps.

Client-side proving becomes possible. If you want ZK applications that compose directly with Ethereum state (“prove I hold >100 ETH without revealing my address”), the state tree itself needs to be prover-friendly. Today, applications work around this by maintaining separate Merkle trees, fragmenting the ecosystem.

For block builders, the page-based storage model changes gas cost profiles significantly. Contracts that access many nearby storage slots become much cheaper. This shifts which transaction types are most gas-efficient and affects optimal block packing strategies. Builders will need to update gas estimation to account for the new access patterns.

Replacing the EVM with RISC-V

This is the most ambitious proposal and still “speculative and non-consensus,” but Vitalik clearly has high conviction.

The argument against the EVM’s status quo: People have developed a latent fear of “using the EVM” in protocol design. If a wallet feature or privacy protocol can be done without involving the EVM, there’s a noticeable sigh of relief. To Vitalik, this means the VM isn’t good enough to serve Ethereum’s core value proposition of generality - and the answer is to fix the VM, not work around it.

Why RISC-V:

The migration path (3 phases):

  1. RISC-V for precompiles only - ~80% of current precompiles become RISC-V code. This immediately reduces client complexity.
  2. Users can deploy RISC-V contracts alongside EVM contracts.
  3. The EVM retires and becomes a smart contract written in RISC-V that interprets EVM bytecode. Full backwards compatibility - existing contracts keep working, only gas costs change.

This is long-term (3+ years), but block builders should keep it on their radar. If the EVM becomes a RISC-V contract, the gas cost of every existing contract changes. That’s a fundamental shift in the economic landscape of block production - gas estimation, MEV extraction strategies, and bundle simulation would all need reworking.

4. The Block Building Pipeline

ePBS: Builder Separation Goes In-Protocol

Arriving in Glamsterdam. Today, proposer-builder separation works via MEV-Boost - an extra-protocol system that relies on relays as trusted intermediaries. ePBS (enshrined PBS) moves builder selection into the protocol itself.

What changes: proposers can outsource block building to a permissionless market without trusting a relay.

What doesn’t change: block building itself remains concentrated among a small number of sophisticated operators. ePBS prevents this concentration from creeping into staking (validators don’t need to be builders), but the builder market structure stays as-is.

FOCIL: Censorship Resistance Gets Teeth

FOCIL (Fork-Choice Enforced Inclusion Lists) is the first step toward multi-participant block building.

Each slot, 16 randomly-selected attesters each publish a list of transactions that must be included somewhere in the block. If the builder omits them, the block gets rejected. This isn’t a soft suggestion - it’s a consensus rule.

Even if one entity controls 100% of block building, they cannot censor transactions. The FOCIL committee independently forces inclusion. This is a hard guarantee - not social pressure, not incentive alignment, but protocol enforcement.

For block builders, FOCIL adds a non-negotiable constraint to block construction. Builders must check inclusion lists and ensure all FOCIL’d transactions appear in their blocks. Missing one means the block is rejected - the slot is lost entirely. This means reserving space and ordering flexibility for forced transactions, and factoring them into optimization algorithms. It also makes transaction exclusion physically impossible at the protocol level.

”Big FOCIL”: How Far Can This Go?

This is more speculative but directionally significant. The idea: scale FOCIL up so the committees handle all non-MEV transactions.

Each of the 16 FOCIL members would handle transactions from senders whose address starts with their assigned hex character (0 through f). Transactions that were missed or censored in one slot get picked up by any FOCIL member in the next.

If fully realized, the builder’s role shrinks to:

  1. Including MEV-relevant transactions (arbitrage, liquidations)
  2. Computing the state transition (state root)

This is a significant strategic signal for anyone operating block building infrastructure. If Big FOCIL materializes, the “commodity transaction inclusion” part of block building becomes a distributed protocol function. Builder differentiation would come entirely from MEV extraction efficiency and fast state root computation. The business model shifts from “selling blockspace” to “optimizing MEV + proving.” Anyone building in this space should be thinking about what their competitive advantage looks like in that world.

Encrypted Mempools

The goal: prevent toxic MEV (sandwiching, frontrunning) by encrypting transactions until they’re included in a block. If nobody can see a transaction’s contents before inclusion, nobody can wrap it in a hostile sandwich.

Two hard unsolved problems:

  1. Validity: how do you verify an encrypted transaction has a correct nonce and enough gas without decrypting it?
  2. Guaranteed decryption: how do you ensure the transaction will be decrypted after inclusion? If the key holder can refuse, you’ve created a new censorship vector.

Block builders should anticipate that encrypted mempools, in whatever form they arrive, will reshape which order flow is valuable. Arbitrage (which doesn’t depend on seeing other transactions’ contents) survives. Toxic MEV strategies disappear. Builders that compete on latency, execution efficiency, and legitimate arbitrage would be well-positioned; those dependent on information asymmetry from the mempool would not.

Transaction Ingress Layer: The Network Privacy Gap

Even with onchain privacy and encrypted mempools, the network layer can leak information:

Solutions being explored include Tor routing for transactions, custom Ethereum-focused mixnets, low-latency anonymity protocols like Flashnet, and the Kohaku initiative which aims to integrate pluggable privacy protocols at the network layer.

This is often overlooked in MEV and privacy discussions, but the ingress layer is where information first becomes available to extract value from. Changes here affect everyone downstream.

Long-Term: Distributed Block Building

The dream: Ethereum processes more transactions than any single server ever needs to handle locally, like BitTorrent.

The obstacle: Ethereum has synchronous shared state. Any transaction could in principle depend on any other transaction. This centralizes block building - someone must put everything in order and execute it.

A possible direction: acknowledge that >95% of Ethereum’s activity doesn’t truly need full global synchrony, and create new transaction categories that are “less global.” These would be cheaper and friendly to fully distributed building. The current fully-global transaction types remain but become relatively more expensive.

Combined with Big FOCIL, this points toward a future where the centralized builder only handles the high-value 5% of transactions that actually need global ordering - and even that role is constrained by protocol-level inclusion guarantees.

Connecting the Threads

These four topics aren’t independent - they form a unified vision:

The common thread: Ethereum is systematically removing dependence on trusted intermediaries - relays for PBS, relayers for privacy protocols, RPC providers for access, centralized builders for inclusion - and replacing them with protocol-level guarantees.

Each piece above makes it so one more thing “just works” even if all infrastructure except the Ethereum chain itself goes down.

Sources

This article unpacks posts from Vitalik Buterin responding to a thread started by Ameen Soleimani (@ameensol) on February 27, 2026, criticizing Ethereum’s lack of native Poseidon support.

Ameen Soleimani’s original post:

Vitalik Buterin’s response posts:

Referenced EIPs and resources: