Open charles-cooper opened 2 months ago
I prefer either:
I prefer either:
- 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?
I prefer either:
- 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.
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.
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?
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 :)
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.