feat: add returndata to tx receipts #542
Conversation
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.
| @@ -119,3 +119,7 @@ ReceiptInfo: | |||
| title: blob gas price | |||
| description: The actual value per gas deducted from the sender's account for blob gas. Only specified for blob transactions as defined by EIP-4844. | |||
| $ref: '#/components/schemas/uint' | |||
| returnData: | |||
| title: returndata | |||
| description: The returndata from the call. This is an optional field that the client is not required to return if the returndata is not available. If it is not available, it should return `nil`. | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
just want to include some points offline - asking for returndata in getTxReceipt may increase latency and/or pricing for infra providers
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
I prefer either:
|
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. |
Perhaps I would be for adding tx-boundary state to eth_call (e.g. Because of this |
what does |
Yep, that is the idea that Lukasz proposed. I just suggested a name :) |
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.