jsonrpc: add eth_getBlockReceipt

[jsvisa]

Motivation

Currently, the way we obtain complete information about all transactions in a block is as follows:

1. Call eth_getBlockBy{Number,Hash} to retrieve all transaction data for a block;
2. Iterate through all the transaction data obtained above and call eth_getTransactionReceipt to retrieve the receipt data for each transaction.

This method is highly inefficient for obtaining large amounts of block and transaction data. To make it easier for users, we propose an RPC that returns all the receipt data for a block in one call.

Parity/OpenEthereum(DEPRECATED) has already implemented this method under the parity namespace(parity_getblockreceipts), and some node providers(eg: alchemy eth_getBlockReceipts) have provided similar solutions. If we can include this RPC in the standard, I believe it would be more consistent and user-friendly for users.

Spec

Here is the spec for eth_getBlockReceiptsBy{Number,Hash}

eth_getBlockReceiptsByNumber {#eth_getBlockReceiptsByNumber}

Returns information about a block receipts by block number.

Parameters

1. Quantity or Tag - integer of a block number, or the string 'earliest', 'latest' or 'pending', as in the default block parameter.

params: ["0x1234"]

Returns Array - The list of Receipt object of the given block:

eg:

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    {
      "blockHash": "0x64d67cf84d95f8dfa1e1c3b5a5260aaf801ac99529b4ec3ae19bb06ba78c7bd5",
      "blockNumber": "0x8d2b29",
      "contractAddress": null,
      "cumulativeGasUsed": "0x5208",
      "from": "0x4d6bb4ed029b33cf25d0810b029bd8b1a6bcab7b",
      "gasUsed": "0x5208",
      "logs": [],
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "root": null,
      "status": "0x1",
      "to": "0xe9c245293dac615c11a5bf26fcec91c3617645e4",
      "transactionHash": "0x1eba82fb5e8426b520c49a5d8dc6c24157e8f45fb9102aca4a99f5617c1539fc",
      "transactionIndex": "0x0"
    },
    {
      "blockHash": "0x64d67cf84d95f8dfa1e1c3b5a5260aaf801ac99529b4ec3ae19bb06ba78c7bd5",
      "blockNumber": "0x8d2b29",
      "contractAddress": null,
      "cumulativeGasUsed": "0x3fc28",
      "from": "0x0caf0d921b2bd24ca04e1f06344e976af223783b",
      "gasUsed": "0x3aa20",
      "logs": [],
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "root": null,
      "status": "0x1",
      "to": "0xf2bb17cb59746cae43d65eec233925b6584cddef",
      "transactionHash": "0x70a50d28db69e5c7a8686141f282530d52e7e3c625296dc53eb5684afa727886",
      "transactionIndex": "0x1"
    }
  ]
}

eth_getBlockReceiptsByHash {#eth_getBlockReceiptsByHash}

Returns information about a block receipts by block hash.

Parameters

1. DATA, 32 Bytes - hash of a block

params: ["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"]

Returns Array - The list of Receipt object of the given block:

eg:

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    {
      "blockHash": "0x64d67cf84d95f8dfa1e1c3b5a5260aaf801ac99529b4ec3ae19bb06ba78c7bd5",
      "blockNumber": "0x8d2b29",
      "contractAddress": null,
      "cumulativeGasUsed": "0x5208",
      "from": "0x4d6bb4ed029b33cf25d0810b029bd8b1a6bcab7b",
      "gasUsed": "0x5208",
      "logs": [],
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "root": null,
      "status": "0x1",
      "to": "0xe9c245293dac615c11a5bf26fcec91c3617645e4",
      "transactionHash": "0x1eba82fb5e8426b520c49a5d8dc6c24157e8f45fb9102aca4a99f5617c1539fc",
      "transactionIndex": "0x0"
    },
    {
      "blockHash": "0x64d67cf84d95f8dfa1e1c3b5a5260aaf801ac99529b4ec3ae19bb06ba78c7bd5",
      "blockNumber": "0x8d2b29",
      "contractAddress": null,
      "cumulativeGasUsed": "0x3fc28",
      "from": "0x0caf0d921b2bd24ca04e1f06344e976af223783b",
      "gasUsed": "0x3aa20",
      "logs": [],
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "root": null,
      "status": "0x1",
      "to": "0xf2bb17cb59746cae43d65eec233925b6584cddef",
      "transactionHash": "0x70a50d28db69e5c7a8686141f282530d52e7e3c625296dc53eb5684afa727886",
      "transactionIndex": "0x1"
    }
  ]
}

[alexqrid]

This is very important feature for many explorers as well. Erigon client has this method. It saves a lot of time to get receipts via this method and not exhaust the node resources with many api calls for every transaction:
For every transaction explorers need to get receipt, and this becomes a problem with geth clients.
As geth's fork is used for various chains, the problem exists in every chain that uses "geth".
At 3xpl we have during parsing EVM-like chains we have an option for erigon clients and a separate case for geth clients, which extremely slows down getting information from EVM-like chains that have no erigon implementation. This is also makes more sense while using node as a service provider (e.g. QuickNode) as every request is counted separately.

Sorry for the tag guys, but can we get more attention to this problem? @lightclient @holiman @fjl

[fjl]

I'm definitely in favor of adding this!

[fjl]

It should be called eth_getBlockReceipts because that's how Erigon calls it.

[jsvisa]

Thanks, @fjl, so I'll implement it similarly to Erigon's.

[jsvisa]

btw, Erigon has two RPCS

1. eth_getBlockReceipts: support params latest|safe|finalized|pending or block number
2. erigon_getBlockReceiptsByBlockHash: support params block hash

ref: cmd/rpcdaemon/README

So I propose to add ONE RPC(eth_getBlockReceipts), which both support block tag, block number or hash

[protolambda]

Because of the lack of a standard here, the OP-Stack currently has to support 6 different receipt-fetching methods, to efficiently retrieve receipts from a L1 Ethereum node.

See https://github.com/ethereum-optimism/optimism/blob/8087e2b939a9a6879411e8a4af934a3a55f8802c/op-node/sources/receipts.go#L187

+1 on requiring a blockhash argument. Erigon is a weird exception there currently we had to work around. Block-hash arguments allow RPC result caching of receipts. Note that individual receipts match a tx, but cannot be cached due to the block-inclusion metadata & tx-replay on reorgs. But full-block receipt fetching can be cached by blockhash very well.

👍 for defining a standard eth_getBlockReceipts here.

[alexqrid]

I think the issue can be closed, as the functionality implemented - ethereum/go-ethereum#27702

[fjl]

But was it added to the spec?