A common use case for developers is implementing some kind of blockchain follower. Logic would usually be written to index data into a local database (think block explorer). The developer would long poll the chain by number, then check the parent hash for forks etc. If the developer wants to get any information about the transactions in that block they need to subsequently call eth_getTransactionReceipt for each one.
Ideas/Proposals/Request for comments
*Add an additional optional flag parameter to `eth_getBlockBy` to indicate the desire for transaction receipt data.**
The problem I see with this is that these endpoints can return a pending block which can not return transaction receipt data, but validation could be put in place to reject that combination. The optional flag would default to false to maintain backwards compatibility. There's a danger of payload bloat so perhaps returning everything except logs (although I feel this negates some of the benefit of adding the parameter)?
A common use case for developers is implementing some kind of blockchain follower. Logic would usually be written to index data into a local database (think block explorer). The developer would long poll the chain by number, then check the parent hash for forks etc. If the developer wants to get any information about the transactions in that block they need to subsequently call
eth_getTransactionReceiptfor each one.Ideas/Proposals/Request for comments
*Add an additional optional flag parameter to `eth_getBlockBy` to indicate the desire for transaction receipt data.**
The problem I see with this is that these endpoints can return a pending block which can not return transaction receipt data, but validation could be put in place to reject that combination. The optional flag would default to false to maintain backwards compatibility. There's a danger of payload bloat so perhaps returning everything except logs (although I feel this negates some of the benefit of adding the parameter)?
It could be bundled as part of https://github.com/ethereum/execution-apis/issues/304, but I think they're addressing different issues.