Vitalik Buterin reveals Ethereum’s transaction redesign

Ethereum co-founder Vitalik Buterin outlined a longer-term transaction model on Sept. 6 that could allow the network to process some validation work in parallel.

His proposal separates the effects produced by transactions from the conditions that must be satisfied before those effects can occur.

Buterin described the two components as “actions” and “dependencies” in a detailed post. Actions change Ethereum’s state, such as transferring ETH or calling a contract. Dependencies cover the information required to establish that a transaction is valid.

A digital signature is one example of a dependency. Other examples include Merkle proofs showing that an unspent output exists, zero-knowledge proofs and state conditions that must remain true when a transaction enters a block.

Buterin argued that making this distinction explicit could help Ethereum scale without abandoning its flexible execution environment. However, the proposal remains part of continuing protocol research. Ethereum developers have not approved the full design for deployment.

Ethereum could process transaction dependencies in parallel

Ethereum transactions currently combine authorization, fee payment and execution within a common processing flow. Nodes check whether a transaction is properly signed, whether the sender can pay for it and whether its instructions execute successfully.

Some of these checks do not depend on the transaction’s final state changes. Buterin said such dependencies could be processed separately and, in many cases, simultaneously.

For example, a validator may need to confirm a signature before accepting a transaction. That verification does not necessarily need to wait for unrelated signatures attached to other transactions. If multiple independent checks are known in advance, clients can distribute the work across available processing resources.

State-dependent checks require greater care. A condition tied to an account balance or storage slot may become invalid if an earlier transaction changes the same state. Buterin said mempools could reason about these conditions more effectively when transactions declare which parts of the state they access.

The approach would reward predictable transactions. Operations that specify their dependencies clearly could receive lower gas costs because clients could verify them more efficiently. Transactions requiring dynamic calls and unpredictable state access would remain possible but could cost more.

Buterin estimated that more than 90% of Ethereum activity by volume does not require the network’s full level of dynamic flexibility. That figure is his assessment rather than a published network measurement within the post. The broader argument is that common transfers and routine contract interactions could use more restrictive formats without limiting specialized applications.

The proposed model would preserve Ethereum’s flexible account system for transactions that need it. More predictable activity could use statically analyzable structures resembling parts of Bitcoin’s transaction model.

Bitcoin uses an unspent transaction output model in which a transaction identifies the outputs it intends to spend. Ethereum normally uses accounts with balances, nonces and programmable contract storage. Buterin is not proposing that Ethereum replace its account model with Bitcoin’s architecture. He described a spectrum combining ideas from both systems.

EIP-8141 provides a general transaction framework

EIP-8141 is a draft Ethereum Improvement Proposal for a new transaction type known as a Frame Transaction. It divides a transaction into contract-call frames that can validate authority, approve gas payment and perform user operations.

The official proposal says transaction validity and fee payment would no longer depend solely on a standard signature attached to the outer transaction. Account code could instead define the necessary authorization and payment rules.

Frame Transactions could support sponsored fees, payments in tokens other than ETH, key rotation and transaction batching. They could also allow externally owned accounts to receive account-abstraction features without relying on the same contract deployment across every compatible network.

Under the proposed structure, verification frames would determine whether the sender authorized the transaction. Separate frames could establish who pays the fees and then execute the requested operations.

This structure aligns with Buterin’s division between dependencies and actions. Verification frames handle conditions that must be satisfied. Sender frames handle the operations that alter state.

The format could also improve interoperability between Ethereum Virtual Machine networks. Different chains could support the same minimal transaction structure while applying their own verification tools, precompiles or account features.

Buterin described the potential format as a basic list of calls with flags identifying their function. A call could be marked as a pure dependency, a state-dependent verification or an action. The transaction would also contain standard information such as its origin and nonce.

EIP-8141 remains classified as a draft Core proposal. Its current specification includes detailed rules for mempool admission, frame execution, receipts, signatures, gas accounting and transaction propagation. Those details can change during review.

Ethereum developers have also debated technical concerns. These include denial-of-service risks, transaction replacement rules, tooling changes, pending-transaction limits and restrictions placed on verification frames.

One discussion noted that the proposed public mempool would normally keep only one pending Frame Transaction for each sender. Developers have questioned how that rule would affect accounts that regularly submit several transactions within one block.

Other participants have examined whether the format introduces additional complexity for wallets, block builders and Ethereum’s remote procedure call interfaces. These questions must be resolved before client teams can implement a stable specification.

Recursive STARKs could remove repeated verification

Buterin’s longer-term model goes beyond EIP-8141. He suggested that dependencies requiring no state access could be checked once at the mempool layer instead of being repeated by every validator.

A pure dependency might include a cryptographic signature or proof whose validity does not change with Ethereum’s state. After checking it, the network could replace multiple pieces of verification work with a recursive STARK confirming that all checks were completed correctly.

A STARK is a cryptographic proof that allows one party to demonstrate that a computation was performed correctly. Recursive proofs can verify other proofs, making it possible to combine many checks into a smaller verification task.

The proposed mempool could aggregate transaction signatures, validity proofs and other dependencies before block execution. Validators would then verify the aggregated proof instead of independently repeating each original computation.

Buterin suggested that this approach might also reduce the amount of verification data placed on-chain. If the recursive proof establishes that all dependencies were valid, some of the original data could potentially be omitted.

That outcome is not part of the current EIP-8141 specification. It would require additional research covering proof generation, mempool coordination, data availability and protections against invalid aggregation.

The design also relates to Ethereum’s preparation for post-quantum cryptography. Quantum-resistant signatures are generally larger and more expensive to verify than the ECDSA signatures used by ordinary Ethereum accounts.

EIP-8141 could allow accounts to define new authorization schemes without waiting for Ethereum to replace a single fixed signature standard. Recursive proof aggregation could then reduce the cost of verifying large post-quantum signatures.

EIP-8141 could help Ethereum accounts adopt post-quantum authorization if practical signature systems become available. That remains a longer-term security path rather than an immediate response to an active quantum threat.

Keyed nonces could remove transaction bottlenecks

Ethereum accounts use sequential nonces to prevent transaction replay. If an account submits transactions numbered 10, 11 and 12, the network normally processes them in that order.

The sequence can create a bottleneck. If transaction 10 becomes stuck or invalid, later transactions from the same account may also wait, even when their operations are unrelated.

Keyed nonces would give an account several independent nonce sequences. Transactions assigned to different keys could proceed without waiting for another sequence to advance.

This could help smart accounts, privacy systems and applications that submit several independent operations simultaneously. Each workflow could receive its own nonce domain while retaining replay protection.

Crypto.news previously reported that keyed nonces could prevent independent private transactions from blocking each other. The feature is part of a broader effort to improve privacy transactions, flexible accounts and censorship resistance.

Buterin also connected the transaction work with alternative state models, including native UTXO designs and proof-based state structures. These projects explore whether some assets or operations can use predictable state rules while complex contracts retain Ethereum’s existing flexibility.

The approach could create several processing levels. Simple, declared operations would be easier to analyze and could receive lower fees. Dynamic contract calls would continue to work but would consume more resources because clients cannot prepare their execution in the same way.

Such differentiated pricing would attempt to align fees with the actual scaling constraints created by each transaction. It would not guarantee lower fees for every user or application.

EIP-8141 still requires developer approval and testing

EIP-8141 must pass several stages before it can affect Ethereum users. Core developers first need to agree that Frame Transactions offer a better path than competing account-abstraction designs.

The proposal would then require client implementations, development networks, interoperability testing, wallet support and security review. Developers would also need to test how Frame Transactions interact with block builders, mempools, fee markets and existing smart contracts.

Earlier developer discussions considered EIP-8141 for Ethereum’s future Hegotá upgrade. However, crypto.news reported that Frame Transactions remained under consideration rather than formally scheduled.

FOCIL, a separate proposal intended to improve censorship resistance through transaction inclusion lists, has also been discussed alongside EIP-8141. The two proposals address different problems. Frame Transactions concern authorization and execution structure, while FOCIL concerns the inclusion of eligible transactions in blocks.

Developers have argued that using them together could provide native account abstraction with stronger censorship resistance. That combination is still a proposed package, not an approved Ethereum roadmap commitment.

Buterin’s Sept. 6 comments therefore describe a possible direction for Ethereum transaction design. They do not announce a completed upgrade, activation date or confirmed change to mainnet gas fees.

The next verifiable milestones would be formal developer support, inclusion in an upgrade scope and working implementations on development networks. Until then, EIP-8141 and recursive STARK mempools remain active research and engineering proposals.

FAQs