Add option to include transaction receipts in eth_getBlockByHash
medvedev1088 opened this issue · 16 comments
In some applications where performance is important it's convenient to query all receipts in a block in a single request.
Since receipts are part of a block, as defined in the yellowpaper, it makes sense to allow including them in the block response for eth_getBlockByHash and eth_getBlockByNumber by adding the boolean parameter to the request:
Parameters
- QUANTITY|TAG - integer of a block number, or the string "earliest", "latest" or "pending", as in the default block parameter.
- Boolean - If true it returns the full transaction objects, if false only the hashes of the transactions.
- Boolean - If true it returns the full receipts objects, if false the receipts objects are not returned.
Here is an analogous issue for go-ethereum ethereum/go-ethereum#17044
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 350.0 DAI (350.0 USD @ $1.0/DAI) attached to it.
- If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
- Questions? Checkout Gitcoin Help or the Gitcoin Slack
- $15,961.24 more funded OSS Work available on the Gitcoin Issue Explorer
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 4 weeks, 1 day from now. Please review their questions below:
- shamardy has started work.
- Q: Working on this
@shamardy Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
- warning (3 days)
- escalation to mods (6 days)
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@shamardy Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
- warning (3 days)
- escalation to mods (6 days)
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
@shamardy due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!
- warning (3 days)
- escalation to mods (6 days)
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
Still working on this. Will open an EIP for this soon.
@shamardy Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
- warning (3 days)
- escalation to mods (6 days)
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@medvedev1088 Sorry for the late reply. This ethereum/EIPs#1300 is closed. Should we open a new EIP PR with this issues functionality or get behind this ethereum/EIPs#1300 to reopen. What worries me in an EIP for this issue is backwards compatibility since adding a boolean parameter to the request will break anything that relies on existing behaviour. So there is 2 options here either introduce eth_getBlockReceiptsByHash and eth_getBlockReceiptsByNumber new methods as in here ethereum/EIPs#1300, or change the eth_getBlockByHash and eth_getBlockByNumber to accept either a boolean (which it is the old behavior), or a JSON dict with two optional fields { fullTransactions: bool, fullReceipts: bool } as suggested by @sorpaas here #9126 (comment). Which route do you think is better?
@shamardy I didn't realize it will break backward compatibility. Is it because optional parameters are not allowed?
@medvedev1088 Optional parameters are not implemented in rust which parity is written by. But I found a way that bypasses that in other RPC functions in parity using the Trailing struct from parity's Rust JSON-RPC implementation. So we can proceed with an EIP using the original solution where there is 2 booleans with the second one as optional without breaking anything that relies on the old implementation.
We can also use the parity_ namespace instead of eth_ to implement parity_getBlockByHash and parity_getBlockByNumber as suggested here #9404 (comment) without the need to wait for an EIP to be accepted. what do you think?
@shamardy I agree, we can proceed with the parity_ namespace, and once the EIP is accepted move it to the eth_ namespace.
⚡️ A tip worth 245.00000 DAI (245.0 USD @ $1.0/DAI) has been granted to @shamardy for this issue from @vs77bb. ⚡️
Nice work @shamardy! Your tip has automatically been deposited in the ETH address we have on file.
- $20148.55 in Funded OSS Work Available at: https://gitcoin.co/explorer
- Incentivize contributions to your repo: Send a Tip or Fund a PR
- No Email? Get help on the Gitcoin Slack
Hi @shamardy I closed this out on Gitcoin and paid you out 70% of the original bounty, as the work was completed + the EIP wasn't in the original scope. Good luck taking this forward to EIP and happy to pay out for the rest if it makes sense in the future 👍
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 7 months ago.
Please review their action plans below:
1) shamardy has started work.
Working on this
Learn more on the Gitcoin Issue Details page.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
The funding of 350.0 DAI (350.0 USD @ $1.0/DAI) attached to this issue has been approved & issued.
- Learn more on the Gitcoin Issue Details page
- Questions? Checkout Gitcoin Help or the Gitcoin Slack
- $19,815.05 more funded OSS Work available on the Gitcoin Issue Explorer