eth_simulateTransaction

[kumavis]

summary

eth_simulateTransaction should be introduced to replace eth_call and eth_estimateGas

eth_simulateTransaction can provide information including:

• return value
• gas consumption
• if an error was thrown

This helps solve the problem of trying to differentiate between correct response and error response with eth_call and eth_estimateGas

spec

eth_simulateTransaction

Executes a new message call without creating a transaction on the block chain.

Parameters

1. Object - The transaction call object

• from: DATA, 20 Bytes - (optional) The address the transaction is sent from.
• to: DATA, 20 Bytes - The address the transaction is directed to.
• gas: QUANTITY - (optional) Integer of the gas provided for the transaction execution. eth_call consumes zero gas, but this parameter may be needed by some executions.
• gasPrice: QUANTITY - (optional) Integer of the gasPrice used for each paid gas
• value: QUANTITY - (optional) Integer of the value send with this transaction
• data: DATA - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI

2. QUANTITY|TAG - integer block number, or the string "latest", "earliest" or "pending", see the default block parameter

Returns

Object - A transaction summary object

• returnValue: DATA, 32 Bytes - hash of the transaction.
• gasUsed : QUANTITY - The amount of gas used by this specific transaction alone.
• contractAddress : DATA, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise null.
• logs: Array - Array of log objects, which this transaction generated.
• errorCode: null or string - (needs spec) Whether or not an error such as a top-level OOG, invalid jump, or other vm-halting error occurred. Code should indicate the status in this way:
  • (successful)
  • out of gas
  • stack overflow
  • stack underflow
  • invalid jump (no JUMPDEST present)
  • invalid instruction
  • possibly the INVALID instruction could have its own code
  • stop by REVERT

Example

// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_simulateTransaction","params":[{"to": "0xCD111aa492a9c77a367C36E6D6AF8e6f212E0C8E"}],"id":1}'

// Result
{
  "id":1,
  "jsonrpc": "2.0",
  "result": {
    "returnValue": "0x4242",
    "gasUsed": "0x5208",
    "contractAddress": null,
    "logs": [],
    "errorCode": null
  }
}

[chriseth]

It would be really great if we could also include ethereum/EIPs#144 in this change, i.e. specify a piece of code that is simulated in a DELEGATECALL fashion.

[kumavis]

yeah thats an interesting one -- currently you can do this by using ethereumjs-vm/hooked which will run the EVM locally and do state lookups via RPC

[gavofyork]

i would rename to simulateTransaction (to be consistent with sendTransaction).

for additional RPCs, especially non-finalised ones, we might consider an arb_ prefix similar to that of opengl, where new RPCs go for a few months while their APIs are being finalised.

[kumavis]

Updated the proposal with a potential spec. Looking for feedback on what to include on the result. I think more information on vm-halting errors would be useful. I tried to match the eth_getTransactionReceipt results but omitted some irrelevant entries {block data, tx hash, ...}

[Georgi87]

Great initiative. Especially knowing if an error was thrown is important. As @chriseth pointed out, it would be great if ethereum/EIPs#144 could be included to reduce contract complexity. This would require one additional property in the transaction object code.

[pipermerriam]

I don't know if this belongs here but this new method could address another issue with gas estimates. It would be nice if the receipt contained both the net gas consumption and the gross gas consumption. Gross consumption is defined as the total_gas_refunded + gasUsed. Net consumption is just the gasUsed is the standard value from transaction receipts.

My understanding is that transactions which involve gas refunds for clearing state can require higher gas values to successfully execute than what is actually consumed.

[axic]

didError: Boolean - Whether or not an error such as a top-level OOG, invalid jump, or other vm-halting error occurred.

It would be nice making this an error code instead and include

• (successful)
• out of gas
• stack overflow
• stack underflow
• invalid jump (no JUMPDEST present)
• invalid instruction
• possibly the INVALID instruction could have its own code
• stop by REVERT

Though a client could decide not to support all these, but only use out of gas.

[kumavis]

@axic updated the proposal to include this -- we need to tighten the spec up a bit. will we want a stack trace or something like this?

[kumavis]

eth_call is insufficient to determine throw/OOGs from genuine gas usage. results in user experience like this:
MetaMask/metamask-extension#1400 (comment)

[lisuyong]

Hi, will this continue?

[benjamincburns]

We field a lot of questions in the Truffle Gitter about transactions failing in spite of calling eth_estimateGas first and using the returned value to set the gasLimit. I came here to write up a proposal that eth_estimateGas be deprecated in favor of eth_estimateGasUsed and eth_estimateGasLimit, however given that this proposal is already here, I'd rather throw my support behind it, provided that it can be extended to cover this case.

What's needed to get this moving forward? I'd be happy to provide a reference implementation in Ganache (formerly testrpc), if necessary. However I don't want to release it until it's clear that major clients will support it.