Feature: custom rpc method eth_simulateTransaction

[sambacha]

Component

Anvil

Describe the feature you would like

quoting the spec, ethereum/EIPs#2560

Motivation

When transaction signing is requested and presented to the user, wallet/DApp browser software ("wallets") should attempt to inform the user of what the transaction entails and what the side effects may be.

Currently, most wallets simply show basic transaction parameters such as the recipient address, the value of ETH being transferred, the gas price/limit, and the encoded data. For well-known transaction types such as ERC20 approve() and transfer(), some wallets decode the call data and present additional information.

For most smart contract transactions, however, what the transaction entails is completely opaque to average users, and a malicious transaction may even appear completely harmless (a smart contract transaction will show the value being transferred as zero as if no ETH is moved, but may nevertheless be moving other types of assets such as ERC20 tokens if an allowance was set previously).

This is terrible for the user experience as it encourages users to be accustomed to signing transactions blindly, which may have adverse consequences such as loss of funds.

A new JSONRPC method eth_simulateTransaction aims to improve the situation by providing a way for wallets to perform a dry run and read events emitted (such as the ERC20 Transfer events), thereby enabling the user to make a more informed decision about whether to sign a transaction that is requested.

---

Rationale

The request parameters are the same as eth_sendTransaction, and the response is a subset of a transaction receipt object you can obtain using eth_getTransactionReceipt, for consistency and familiarity.

Note that it does not require a signed transaction (raw tx), as the motivation is to provide more information to the user before signing happens.

Implementation

There is an existing method eth_estimateGas that already performs transaction dry runs, but the method only returns the amount of gas used by the transaction. The code for eth_estimateGas may be reusable for the implementation of eth_simulateTransaction.

Additional context

part of #2396

[onbjerg]

This should already covered by the tracing RPC calls (when implemented) and so should not really be needed?

[sambacha]

This should already covered by the tracing RPC calls (when implemented) and so should not really be needed?

Can you be more specific as to which tracing RPC calls when implemented would cover this?

[onbjerg]

This one #1737

I don't think adding a dedicated RPC method geared towards wallets (as outlined in this issue) makes a lot of sense for a development node

[sambacha]

This one #1737

I don't think adding a dedicated RPC method geared towards wallets (as outlined in this issue) makes a lot of sense for a development node

People use Ganache currently as a backing mock instance to test frontend implementations for contracts. It would be helpful also to verify such behavior is reproducible when contracts are deployed and in usage with a GUI as to what is being presented to the user vs what the developer intended to display to the user

[onbjerg]

But using a custom RPC will not aid you in front-end development if you have to replace the custom RPC endpoint with something else entirely, so I'm not sure this is a high value add considering the extra maintenance burden (and as mentioned previously, similar results can be achieved with more standard RPC methods)

[sambacha]

But using a custom RPC will not aid you in front-end development if you have to replace the custom RPC endpoint with something else entirely, so I'm not sure this is a high value add considering the extra maintenance burden (and as mentioned previously, similar results can be achieved with more standard RPC methods)

Tenderly offers such RPC method, and its in use for the Sushi frontend as an example

[sambacha]

I completely agree @onbjerg bout the maintenance concerns with any additional features, but hey, just laying out all these things for consideration

[onbjerg]

Closing this as out of scope since no production node supports this, and I think it is reasonable to assume that people write their front-ends targetting production RPC methods. We can revisit this if something similar is implemented in a production node

[sambacha]

Closing this as out of scope since no production node supports this, and I think it is reasonable to assume that people write their front-ends targetting production RPC methods. We can revisit this if something similar is implemented in a production node

Did not notice this was closed, this is how it works:

Logic

The request parameters are the same as eth_sendTransaction, and the response is a subset of a transaction receipt object you can obtain using eth_getTransactionReceipt, for consistency and familiarity.

Note that it does not require a signed transaction (raw tx), as the motivation is to provide more information to the user before signing happens.

Implementation

There is an existing method eth_estimateGas that already performs transaction dry runs, but the method only returns the amount of gas used by the transaction. The code for eth_estimateGas may be reusable for the implementation of eth_simulateTransaction.

#2191 would be an additional use case