feat: add returndata to tx receipts

[charles-cooper]

right now, returndata is not part of the tx receipt. this means that consumers of the API need to find alternative ways to fetch the returndata from a transaction, the most common being debug_traceTransaction. however, this is non-standard and not universally supported. it would be helpful if the returndata were simply part of the transaction receipt.

[mattsse]

the return data is usually not stored because it can retrieved by re-executing the tx again, hence it's only part of the trace responses.

if this is an option, then it's ambiguous what the client impl should do, always re-execute or always return null

but having a standard call for obtaining the returndata would be very useful, so maybe this should be a standalone function instead?

[charles-cooper]

i left it optional exactly for this reason, clients probably do not have the returndata stored, so in the short-term they can keep doing exactly what they have been doing. it is preferred by consumers that the returndata is there, but if it is nil then they can fall back to workaround (as they currently do).

[charles-cooper]

a standardized eth_getReturnData would also work for this purpose, although it seems inefficient since in the (very common) case that you want to inspect the returndata, you need to make two calls instead of just one.

[charles-cooper]

just want to include some points offline - asking for returndata in getTxReceipt may increase latency and/or pricing for infra providers

[charles-cooper]

you need to make two calls instead of just one.

by the way, having two calls is pretty problematic because there are race conditions when you have to call the node twice (there could be a reorg or the node provider could switch clients and the second call returns null or a different value). the ideal state of affairs is to get the result back in one call.

[charles-cooper]

another issue in practice is that RPC providers fail all the time, so a very common case is that you get the result of eth_getTransactionReceipt but then the node fails, and the following call to grab the trace (or alternatives like the above proposed eth_getReturnData) fails. it's not a showstopper, you can do a second retry loop or failover to another RPC. but it's more ideal -- just simpler and less prone to failure -- to get the returndata back in a single call.

[LukaszRozmej]

I prefer either:

1. mandatory storage of this data and changing eth/XX protocol to be able to sync it OR
2. separate method as it allows for better separation of optional and mandatory data and better balance load of the calls as re-runing transaction is more costly than reading from receipt database.

[charles-cooper]

I prefer either:

1. mandatory storage of this data and changing eth/XX protocol to be able to sync it OR

how feasible is it to change the receipt database?

[LukaszRozmej]

I prefer either:

1. mandatory storage of this data and changing eth/XX protocol to be able to sync it OR

how feasible is it to change the receipt database?

way less than the alternative, it would have to be hardforked and wouldn't apply to previous receipts.
So am for adding new method like eth_call but for historical transactions only.

[s1na]

So am for adding new method like eth_call but for historical transactions only.

Perhaps eth_replayTransaction.

I would be for adding tx-boundary state to eth_call (e.g. eth_call({}, "latest", 2) where 2 is the tx index). The challenge is that geth has extra optional parameters to override state and block fields. So to make this tx index compatible across clients we'd first need to standardize those 2 fields.

Because of this eth_replayTransaction seems the path of least resistance.

[charles-cooper]

So am for adding new method like eth_call but for historical transactions only.

Perhaps eth_replayTransaction.

what does eth_replayTransaction do? basically eth_call but with a transaction hash?

[s1na]

what does eth_replayTransaction do? basically eth_call but with a transaction hash?

Yep, that is the idea that Lukasz proposed. I just suggested a name :)

[fjl]

I don't think this should be added. In the Ethereum protocol, transactions exist in order to write to the state, and transactions do not have a returned value. The 'output' of a transaction are the logs, and they go into the receipt. Relying on transaction return data for any use case is just wrong.