Vitalik Floats Ethereum Transaction Split for Faster Checks

Vitalik Splits What Transactions Do From What They Prove

An action is the result a transaction produces: sending ETH, updating storage or calling a smart contract. A dependency is a precondition, such as a signature, a proof or a state assertion, that determines whether the action is allowed to proceed.

Ethereum today handles many of those jobs within one transaction-processing path. Buterin’s point is that not all dependencies have the same cost or need the same treatment. A pure cryptographic check, for example, can be verified without looking at the chain’s changing state. A condition about an account balance or storage slot cannot, because an earlier transaction may alter it.

Making that boundary explicit could allow clients to check independent dependencies in parallel before execution. It could also let the fee model better reflect whether a transaction exposes its conditions clearly or requires more dynamic work. Neither outcome is guaranteed by the post, and the final design would still need agreement on the security and mempool rules.

That focus on transaction authorization is part of a wider wallet-design push. Daily Crypto Briefs previously covered Ethereum’s quantum-safe key registry, another effort to make future account-security choices less dependent on one legacy key format. The two proposals address different layers, but both show why Ethereum developers are treating signature flexibility as protocol infrastructure.

EIP-8141 Turns the Idea Into Transaction Frames

EIP-8141 is the concrete draft most closely related to Buterin’s framework. It specifies a new transaction type with a sequence of frames. VERIFY frames establish authorization, while other frames can approve payment or run the user’s operations.

The design lets an account define how it validates a transaction and who pays for it. The EIP lists native account abstraction, third-party fee sponsorship, batched calls, key rotation and support for post-quantum systems as intended benefits. It also has substantial operational surface area: public-mempool restrictions, gas accounting, receipts, signature handling and wallet tooling all must work together.

The execution-specs implementation tracker names Bogota as its target fork, but its checklist still includes test coverage, multi-client test results and devnet work. That means a target is not a deployed feature, and it should not be read as a fixed shipping date.

There is a direct reader impact if the work matures. Wallets could eventually use different authorization methods, pay fees in more flexible ways or batch actions without relying on the same separate infrastructure. But those are capabilities proposed by the specification, not features available in ordinary Ethereum wallets today.

The design also sits alongside execution-capacity work. Our coverage of Ethereum’s 200 million gas-limit test for Glamsterdam concerns how much execution a block can carry; EIP-8141 concerns how a transaction is structured and approved before that execution is measured.

STARK Mempools Could Stop Validators Rechecking Pure Proofs

Buterin’s longer-horizon example goes beyond Frame Transactions. He said some pure dependencies could be checked once in the mempool, then represented to validators by a recursive STARK that proves a batch of checks was performed correctly.

A STARK is a cryptographic proof used to show that a computation was completed correctly. Recursion allows proofs to be combined, potentially turning many verification tasks into one smaller proof for the next verifier. Applied to a mempool, the idea could spare every validator from separately replaying the same pure checks.

That is still a research direction. It would need secure proving infrastructure, clear rules for what counts as pure, protection against invalid or censored transactions and careful incentives for the participants producing proofs. Ethereum Research is already discussing minimum validation budgets for privacy applications, a reminder that more programmable validation can introduce its own inclusion and denial-of-service tradeoffs.

The important near-term signal is not a gas-price forecast. It is that the transaction format, wallet authorization and mempool validation are being designed together rather than as separate patches. Readers should watch for EIP status changes, developer-call decisions, client test results and a devnet before treating any part of the model as a scheduled Ethereum upgrade.

The Crypto Fear & Greed Index read 73, or Greed, on September 6. That broad market reading does not measure demand for EIP-8141 or validate the proposal’s technical case.

For now, the confirmed development is narrower but meaningful: Buterin has laid out a transaction vocabulary that could make Ethereum’s future validation work more modular. Whether it reaches mainnet will depend on the engineering milestones that have not yet been completed.