Vitalik Buterin proposes a longer-term Ethereum transaction model, with the core idea of separating "actions" and "dependencies" in transactions. The former is responsible for changing the state on the chain, while the latter is used to prove that the transaction has met the conditions for signing, state verification, and validity before execution. Following this approach, some verification tasks have the opportunity to be completed before entering the block, and there will also be more room for parallel processing.
Transaction verification and execution are proposed to be handled separately.
In Ethereum's current transaction process, authorization, fee payment, and contract execution are typically handled within the same process chain. Nodes need to check simultaneously whether the signature is valid, whether the sender has the ability to pay the fees, and whether the transaction is successful after execution.
Buterin believes that some of these checks do not depend on changes in the final state, and in theory, they can be processed separately first. For example, digital signatures, zero-knowledge proofs, or certain types of validity proofs that do not rely on changes in the on-chain state can all be classified as part of the 'dependent' category.
If transactions can clearly state which states they will access, it becomes easier for the memory pool to determine which conditions will be affected by preceding transactions, and which checks can be completed in advance. This means that more predictable transactions may achieve higher verification efficiency.
EIP-8141 is still in the draft stage.
Corresponding to this approach is a draft proposal named EIP-8141. This proposal introduces a new type of transaction, referred to as Frame Transaction. It splits a single transaction into multiple call frames, which are used to handle authorization verification, fee payment, and user operation execution separately.
According to the draft design, the validity of transactions and the payment of fees no longer rely entirely on external standard signatures. Account codes can define their own authorization methods and payment rules. The verification frame is responsible for confirming whether the conditions are met, while the sending frame is responsible for actually modifying the status.
This structure is also considered to help different EVM networks adopt a more similar basic transaction format. However, EIP-8141 is still the core draft at present and has not been incorporated into the Ethereum mainnet upgrade, nor is there a clear deployment time.
During the developer discussions, a number of technical issues were also raised, including the risk of denial of service, transaction replacement rules, wallet and block builder compatibility, as well as the limitations on the number of pending transactions from the same sender within the public memory pool. These issues still need to be further resolved.
Recursive STARK or reduce duplicate verification
The long-term direction proposed by Buterin is not limited to EIP-8141. He also envisions that for those cases that do not require access to the on-chain state, a check can be performed at the memory pool layer first, rather than having each validator execute it repeatedly.
Under this model, the network can compress multiple completed verification tasks into a recursive STARK proof, which is then verified collectively by the verifiers. The goal of doing this is to reduce redundant calculations and alleviate some of the verification burden.
He also mentioned that this approach may in the future help Ethereum to adapt to post-quantum cryptography schemes. The reason is that quantum-resistant signatures are usually larger in size and require higher verification costs. If accounts can customize their authorization methods, combined with recursive proof aggregation, there is a chance that the related verification costs could be reduced.
However, this part of the content is still at the research stage and does not yet fall under the existing specifications of EIP-8141. To truly implement it, issues such as generation verification, memory pool coordination, data availability, and error aggregation protection need to be resolved.
