Parity-ethereum: Add option to include transaction receipts in eth_getBlockByHash

Created on 9 Jul 2018 · 16Comments · Source: openethereum/parity-ethereum

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 https://github.com/ethereum/go-ethereum/issues/17044

F8-enhancement 🎊 M6-rpcapi 📣 P9-somedaymaybe 🌞

Source

medvedev1088

👍18

All 16 comments

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

gitcoinbot on 10 Jul 2018

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

gitcoinbot on 11 Jul 2018

@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!

[x] warning (3 days)
[ ] escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

gitcoinbot on 14 Jul 2018

from: https://github.com/paritytech/parity-ethereum/pull/9126/comment#issuecomment-412016764

Do we need proper EIPs for this eth_ namespace change?

This should definitely be an EIP fist. The issue was incorrectly labeled. Please open an EIP here and reopen the issue if accepted. I'm sorry @shamardy

debris on 10 Aug 2018

[x] warning (3 days)
[ ] escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

gitcoinbot on 10 Aug 2018

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!

[x] warning (3 days)
[x] escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

gitcoinbot on 13 Aug 2018

Still working on this. Will open an EIP for this soon.

shamardy on 13 Aug 2018

👍1

[x] warning (3 days)
[ ] escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

gitcoinbot on 19 Aug 2018

@medvedev1088 Sorry for the late reply. This https://github.com/ethereum/EIPs/pull/1300 is closed. Should we open a new EIP PR with this issues functionality or get behind this https://github.com/ethereum/EIPs/pull/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 https://github.com/ethereum/EIPs/pull/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 https://github.com/paritytech/parity-ethereum/pull/9126#issuecomment-410677143. Which route do you think is better?

shamardy on 21 Aug 2018

@shamardy I didn't realize it will break backward compatibility. Is it because optional parameters are not allowed?

medvedev1088 on 21 Aug 2018

@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 https://github.com/paritytech/parity-ethereum/pull/9404#issuecomment-415357669 without the need to wait for an EIP to be accepted. what do you think?

shamardy on 24 Aug 2018

🎉1

@shamardy I agree, we can proceed with the parity_ namespace, and once the EIP is accepted move it to the eth_ namespace.

medvedev1088 on 26 Aug 2018

⚡️ 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

gitcoinbot on 29 Aug 2018

👍1

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 👍