Buterin Unveils Plan to Redesign Ethereum Transactions

A new transaction architecture for Ethereum

On Sept. 6, Vitalik Buterin presented a long-term vision for how Ethereum could restructure its transaction model to improve parallel processing, reduce redundant verification, and open new paths for account abstraction and post-quantum readiness. The proposal centers on splitting transactions into two distinct parts — actions and dependencies — so that networks, clients and mempools can validate what matters independently and more efficiently.

Actions vs. Dependencies: the core idea

Buterin frames the redesign around two complementary concepts. "Actions" are the state-changing operations: transfers of ETH or ERC-20 tokens, contract calls that alter storage, and other effects that update the blockchain state. "Dependencies" are the conditions that must be true before those actions are safely executed: signatures, Merkle or state proofs, zero-knowledge validity checks, and any other authorization or precondition constraints.

Today, Ethereum transactions bundle authorization, fee payment and execution into a single flow. Nodes check a signature, confirm fee payment capability, and then execute the transaction. But many of those checks — especially pure cryptographic checks — do not depend on the final state and can be verified independently or ahead of time. By explicitly separating the two components, Ethereum could parallelize verification, compress repeated work, and provide cheaper paths for predictable operations.

Practical examples

• Signature verification: a cryptographic signature is typically independent of other transactions’ effects and can be checked in isolation.
• State proofs: Merkle proofs or other non-state-dependent validity checks can be validated once and reused.
• State-dependent checks: conditions tied to an account balance or storage slot must still consider ordering and potential conflicts.

EIP-8141: Frame Transactions and a programmable structure

A concrete step toward this vision is EIP-8141, a draft Core proposal that defines a new transaction format called the Frame Transaction. Instead of a single monolithic envelope, a Frame Transaction is a sequence of frames. Each frame can play a role: verify authorization, declare who pays fees, or execute a user operation. This modular structure aligns with the actions/dependencies split and enables more flexible account abstraction.

Key features proposed by EIP-8141 include:

• Programmable validation and fee rules: account code can define how authorization is proven and how gas is paid, allowing sponsored fees or payments in ERC-20 tokens.
• Support for account abstraction: externally owned accounts (EOAs) could gain richer authorization models without requiring identical contract deployments across networks.
• Interoperability across EVM chains: Frame Transactions provide a minimal, portable structure that different chains can adopt while applying their own precompiles or verification logic.

How frames map to dependencies and actions

Verification frames handle pure dependencies — signatures and static proofs — while execution frames perform state-changing actions. A transaction can also include flags marking each call as a pure dependency, a state-dependent verification, or an action. The transaction still carries origin, nonce and other standard metadata, but the internal organization enables differentiated handling by mempools and validators.

Why this matters for scaling and fees

Separating dependencies from actions unlocks several practical benefits for Ethereum scaling and transaction cost efficiency:

• Parallel verification: independent checks can be distributed across CPUs or machines so multiple validations run simultaneously.
• Reduced redundancy: pure dependencies may no longer need to be repeated by every validator at execution time.
• Fee differentiation: predictable, statically analyzable transactions could be cheaper because they require less run-time work; dynamic, unpredictable contract calls remain supported but could carry higher gas reflecting their resource cost.

Buterin estimates — as an informed assessment rather than a hard network measurement — that more than 90% of Ethereum activity by volume could fit simpler, less dynamic formats. If true, the network could gain efficiency by offering cheaper formats for the common case without restricting complex smart contracts.

Recursive STARKs: compressing verification work

Beyond EIP-8141, Buterin discussed using recursive STARKs (Scalable Transparent ARguments of Knowledge) to aggregate and compress dependency checks. In this model, pure dependencies verified in the mempool — such as signatures and validity proofs — are aggregated into a single recursive proof. Validators then verify the recursive STARK rather than re-executing each original check, potentially saving CPU cycles and reducing on-chain verification data.

What STARKs change and what remains challenging

STARKs let one party prove a computation was done correctly; recursive STARKs can prove that a set of proofs are all valid. Applied to transaction dependencies, the mempool would build an aggregated proof that all dependency checks passed. Validators would validate one compact proof before executing actions.

However, this introduces research and engineering questions that must be addressed before mainnet use:

• Proof generation cost and latency: creating recursive proofs is computationally intensive today and may require specialized tooling and coordination.
• Mempool coordination and incentives: who builds aggregated proofs, and how are they propagated and rewarded?
• Data availability and security: ensuring aggregated proofs are correct, non-censorable, and resilient to malformed aggregation attempts.

While the approach could also reduce on-chain verification payloads, such reductions are not baked into the current EIP-8141 spec and would need additional proposals and consensus.

Post-quantum readiness and signature evolution

One practical motivation for modular transaction design is post-quantum cryptography. Quantum-resistant signatures tend to be larger and costlier to verify than current ECDSA signatures. EIP-8141’s flexible authorization model would let accounts adopt alternative signature schemes without a network-wide signature standard replacement. Combined with recursive proof aggregation, networks could offset verification costs by compressing many heavy checks into succinct proofs.

That makes EIP-8141 an attractive long-term path to broaden authorization choices — including potential post-quantum schemes — while managing verification overhead.

Keyed nonces: removing sequential bottlenecks

Ethereum’s sequential nonces prevent replay and guarantee ordered execution from a single account, but they also create a throughput bottleneck. If a pending transaction blocks at nonce N, subsequent transactions at N+1 and N+2 stall even if they are independent.

Keyed nonces introduce multiple independent nonce domains per account. Transactions are assigned a nonce key, so unrelated workflows can progress in parallel. This helps smart accounts, batched or privacy-focused apps, and any scenario where multiple independent operations originate from the same account simultaneously.

By partitioning nonce space, keyed nonces reduce head-of-line blocking and improve UX for complex wallets and decentralized applications that submit concurrent sequences of transactions.

State models: UTXO ideas and hybrid approaches

Part of the conversation links Frame Transactions and keyed nonces to alternative state models. Bitcoin’s UTXO (unspent transaction output) model is predictably analyzable because transactions explicitly list outputs spent. Ethereum’s account model is more flexible but harder to analyze statically.

Buterin is not proposing to swap Ethereum’s account model for a pure UTXO system. Instead, he describes a spectrum where simple, declared operations can use UTXO-like predictability while complex contracts retain full account flexibility. That hybrid approach can deliver multi-tier processing: highly predictable operations are cheap and parallelizable; dynamic contract calls remain possible but require more resources and therefore command higher fees.

Developer concerns and implementation hurdles

EIP-8141 and the broader dependency/action architecture are still draft research. Core developers, client teams and wallet providers have raised technical questions that must be resolved before deployment:

• Denial-of-service vectors: new mempool logic and frame processing must avoid opening attack surfaces that increase gasless spam or resource exhaustion.
• Transaction replacement and pending limits: rules for replacing pending Frame Transactions and limits on per-account pending frames must be carefully designed to avoid unintended regressions in UX.
• Tooling complexity: wallets, RPCs, block builders and indexers will all need updates to produce, sign and relay Frame Transactions correctly.
• Mempool semantics: proposals like keeping only one pending Frame Transaction per sender raise compatibility questions for power users who submit multiple concurrent transactions.

These concerns are healthy: they reflect the amount of integration work required across clients (Geth, Besu, Erigon, Nethermind), wallet software, block builders and MEV-aware tooling.

FOCIL and censorship-resistance synergies

Separately, the FOCIL proposal aims to improve censorship resistance by enabling transaction inclusion lists. While EIP-8141 targets transaction structure and authorization, FOCIL addresses which transactions must be included by builders. Developers have suggested combining Frame Transactions with FOCIL to produce stronger native account abstraction while improving inclusion guarantees — though that combined package remains speculative and not part of an approved roadmap.

Adoption path and realistic timeline

EIP-8141 must traverse several stages before it affects users: community consensus among core devs, client implementations, testnet deployments, wallet support, integration with block builders, and formal security audits. Past discussions considered EIP-8141 for future upgrade scopes, but as of now it is under review rather than scheduled.

Key milestones to watch:

• Formal Core Dev endorsement of Frame Transactions as a preferred account-abstraction approach.
• Client merge and stable testnet implementations with complete mempool, RPC and gas-accounting behavior.
• Interoperability testing across EVM-compatible networks and public testnets.
• Wallet and developer tooling support for building, signing and streaming Frame Transactions.

Until those steps happen, EIP-8141 and recursive-STARK mempools remain research proposals rather than guaranteed upgrades. But the design direction — splitting dependencies and actions, using keyed nonces and exploring recursive aggregation — offers a coherent strategy for increasing parallelism and lowering redundant verification on Ethereum.

What this means for users, developers and validators

Users could see cheaper, faster confirmation for predictable transfers and routine contract calls if clients and builders optimize for frame-style transactions. Developers will need to adapt smart contract tooling and wallets to support the new frame structure and to declare dependencies where possible. Validators and block builders could benefit from reduced verification cost and improved throughput if mempool aggregation and recursive verification are implemented safely.

At the same time, specialized and dynamic dApps will retain the freedom to execute complex logic with the existing account flexibility. The goal is not to replace the expressive power of Ethereum’s EVM but to give the network a way to route simple operations into a cheaper, more parallel pipeline.

Conclusion: a pragmatic route to scaling and flexibility

Vitalik Buterin’s transaction redesign is an ambitious but pragmatic effort to reconcile Ethereum’s need for flexible smart contracts with the benefits of predictable, parallelizable transaction formats. EIP-8141’s Frame Transactions, keyed nonces and a potential path to recursive STARK aggregation form a stack of tools that could materially reduce redundant work, support post-quantum authorization choices, and enable differentiated fee structures.

However, significant research, engineering and cross-team coordination remain. The community must balance performance gains with tooling complexity and security risks. If the ecosystem can resolve those issues, Frame Transactions and mempool-level aggregation could become important building blocks for Ethereum’s next-generation transaction processing.

Until then, these ideas should be treated as forward-looking research: promising pathways rather than immediate protocol changes. The next verifiable steps will be developer consensus, reference client implementations and successful testing on public development networks.