Open kumavis opened 7 years ago
It would be really great if we could also include https://github.com/ethereum/EIPs/issues/144 in this change, i.e. specify a piece of code that is simulated in a DELEGATECALL fashion.
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
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.
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, ...}
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
.
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.
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
JUMPDEST
present)INVALID
instruction could have its own codeREVERT
Though a client could decide not to support all these, but only use out of gas.
@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?
eth_call
is insufficient to determine throw/OOGs from genuine gas usage. results in user experience like this:
https://github.com/MetaMask/metamask-plugin/issues/1400#issuecomment-300277102
Hi, will this continue?
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.
I'd like to bump this as well, and I'm available to help however possible; with this proposal over 17 months old, I'd like to reiterate @benjamincburns on how to get this moving towards a solution.
this is a good idea
summary
eth_simulateTransaction
should be introduced to replaceeth_call
andeth_estimateGas
eth_simulateTransaction
can provide information including:This helps solve the problem of trying to differentiate between correct response and error response with
eth_call
andeth_estimateGas
spec
eth_simulateTransaction
Executes a new message call without creating a transaction on the block chain.
Parameters
Object
- The transaction call objectfrom
: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 gasvalue
:QUANTITY
- (optional) Integer of the value send with this transactiondata
:DATA
- (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABIQUANTITY|TAG
- integer block number, or the string"latest"
,"earliest"
or"pending"
, see the default block parameterReturns
Object
- A transaction summary objectreturnValue
: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, otherwisenull
.logs
:Array
- Array of log objects, which this transaction generated.errorCode
:null
orstring
- (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:Example