Ethereum Simulations​ are getting better with eth_simulateV2

Ethereum developers heavily rely on transaction simulations to test and debug smart contracts before deploying them on-chain. These simulations allow them to estimate gas usage, validate execution paths, and prevent costly errors. However, the current tools—such as eth_simulate, eth_call, and estimateGas—come with several limitations that make accurate transaction testing difficult.

As Ethereum continues to evolve, the demand for more advanced simulation features is growing. Developers need better debugging tools, more reliable gas estimation, and improved transaction validation. This is where eth_simulateV2 comes in—a potential upgrade that could introduce new capabilities to make simulations more robust and developer-friendly.

This blogpost explores the key issues with Ethereum’s current transaction testing methods and suggests how eth_simulateV2 can address them.

Challenges in Ethereum Transaction Testing

• Detecting Contract Creations: One of the major shortcomings of eth_simulate is its inability to detect when a transaction creates a contract. Right now, unless the transaction follows the standard contract creation path, developers cannot easily determine if a contract was deployed.

This limitation makes it difficult to analyze transactions that spawn multiple contracts. Developers are often left guessing or manually inspecting logs to figure out what happened.

A possible solution for eth_simulateV2 is to emit an event every time a contract is created. This would provide clear visibility into contract deployments and make it easier to track newly created contracts during simulations.

• Inaccurate Gas Estimation: Gas estimation is another major pain point in Ethereum transaction testing. The current estimateGas function often underestimates or overestimates the actual gas needed for execution. This can result in unexpected transaction failures or wasted gas fees.

A related issue arises when overriding the ecrecover function. In its current form, this override consumes more gas than it should. Ideally, eth_simulateV2 should allow gas consumption to accurately reflect execution costs, while still enforcing the correct gas limits for the overall transaction.

By implementing multi-gas calculation improvements, eth_simulateV2 can ensure that gas estimation is more precise, reducing both failures and unnecessary costs.

• Lack of Stack Traces for Errors: When a transaction fails, eth_simulate currently returns only a generic error message without details on what went wrong. This makes debugging extremely difficult, as developers have no insight into the sequence of operations leading up to the failure.

A useful addition to eth_simulateV2 would be full stack traces. Instead of just showing an error, it should provide a detailed execution path, helping developers pinpoint exactly where and why the transaction failed.

• Limited Transaction Tracing Capabilities: Tracing transactions is essential for understanding internal contract interactions. However, not all Ethereum clients fully support transaction tracing, making it difficult to analyze complex contract behavior.

A future version of eth_simulate should include comprehensive full tracing support, allowing developers to track every single operation executed within a transaction. This would make debugging and contract analysis significantly more effective.

• Simulating Future Blocks with Phantom Blocks Currently, Ethereum does not support creating blocks far into the future for testing purposes. This is a major issue when working with time-dependent smart contracts, where developers need to simulate transactions happening in later blocks.

A workaround exists, but it involves querying the latest block, manually adjusting timestamps, and making a rapid eth_simulate call before the block updates. This is prone to race conditions, where the block number changes before the simulation is processed.

A better approach would be to introduce phantom blocks — a concept that allows developers to simulate blocks far into the future. These phantom blocks would pad missing blocks automatically, preventing race conditions and making it easier to test future transactions.

Additionally, developers should be able to specify block timestamps using relative values such as latest + 10 instead of manually fetching block numbers. This would streamline testing and reduce the need for extra queries.

• Lack of Witness Creation for Simulation Results: Currently, eth_simulate does not generate cryptographic proofs (witnesses) for its results. This means there is no way to verify that the simulated outcome accurately represents how the transaction would behave on-chain.

Adding witness creation to eth_simulateV2 would enable developers to validate simulation results cryptographically. This would be particularly useful for cross-checking transaction behavior before execution.

• Improving Gas Simulation Flexibility: Gas estimation in Ethereum is not always straightforward. Some transactions require fine-tuned gas limits, but the current system does not offer much flexibility.

A possible solution for eth_simulateV2 is to introduce new gas simulation parameters, such as:

{
  "gasLimit": number | null | "estimate",
  "estimatePlease": true
}

This would allow developers to automatically adjust gas limits based on the simulation results. By making gas handling more dynamic, transactions could fail less often due to incorrect gas estimates.

• Removing Unnecessary Fields from Simulation Results: Ethereum’s simulation outputs often contain fields that are not relevant to most use cases. For example, the size field in the return value does not provide much value for transaction testing.

eth_simulateV2 could streamline simulation outputs by removing redundant fields, making the responses cleaner and easier to interpret. This would also improve performance by reducing unnecessary data processing.

eth_simulateV2 Advantages

Ethereum’s current transaction testing tools provide essential functionality, but they are far from perfect. The introduction of eth_simulateV2 could solve many of these issues by adding better debugging, accurate gas estimation, full transaction tracing, and flexible simulation features.

Gas estimation would also become more accurate, reducing the risk of unexpected transaction failures and preventing unnecessary fees. Additionally, transaction validation would be strengthened with the introduction of contract creation events and cryptographic witnesses, ensuring that simulations reflect real execution behavior.

Testing time-sensitive contracts would also become easier with the inclusion of phantom blocks and dynamic timestamp adjustments, eliminating the need for manual workarounds. These changes would make Ethereum simulations more reliable, efficient, and developer-friendly, ultimately enhancing the quality and security of smart contracts.

By implementing these improvements, Ethereum developers will have a more powerful and reliable simulation environment, reducing on-chain failures and improving smart contract security.

As Ethereum continues to evolve, better simulation tools will be crucial in helping developers build efficient, secure, and optimized smart contracts.

References: Eth Simulate Feb 10, 2025

Related Articles

1. Ethereum’s Institutional & Government Adoption
2. Solving the Puzzle of Duplicate Blocks in Ethereum
3. Ethereum Developers are Rethinking Transaction Signatures & Authority
4. The Debate Over Freezing Ethereum's Core for Good
5. Fixing Ethereum’s Message Signing Chaos