8000 JSONRPC responses with cursor/paging · Issue #617 · ethereum/execution-apis · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
JSONRPC responses with cursor/paging #617
Open
@Kriys94

Description

@Kriys94

Motivation


Some JSONRPC methods return much data, like eth_getLogs, which will worsen as blockchains achieve more transaction throughput.

To overcome RPCs limitations, some Dapps/Indexers are doing eth_getLogs requests are made by chunks of blocks, but this is probably inefficient for the Dapps, as they have many useless requests to the JSONRPC endpoint.

Specification


Parameters:

  • Object
    • logLimit: [optional] Maximum number of logs to be returned
    • address: [optional] Contract address (20 bytes) or a list of addresses from which logs should originate.
    • fromBlock: [optional, default is "latest"] A hexadecimal block number, or one of the string tags latest, earliest, pending, safe, or finalized. See the default block parameter.
    • toBlock: [optional, default is "latest"] A hexadecimal block number, or one of the string tags latest, earliest, pending, safe, or finalized. See the default block parameter.
    • topics: [optional] Array of 32 bytes DATA topics. Topics are order-dependent.
    • blockhash: [optional] Restricts the logs returned to the single block referenced in the 32-byte hash blockHash. Using blockHash is equivalent to setting fromBlock and toBlock to the block number referenced in the blockHash. If blockHash is present in the filter criteria, then neither fromBlock nor toBlock are allowed.
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "eth_getLogsV2",
  "params": [
    {
      "logLimit": 10000,
      "address": [
        "0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907"
      ],
      "fromBlock": "earliest",
      "toBlock": "latest",
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
        "0x00000000000000000000000000b46c2526e227482e2ebb8f4c69e4674d262e75",
        "0x00000000000000000000000054a2d42a40f51259dedd1978f6c118a0f0eff078"
      ],
    }
  ]
}

Response:

  • nextBlockResult: Block Number to get the next batch of response
  • logs: List of logs matching the filter of the request
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [
    {
      "nextBlockResult": "0x429d3c",
      "logs": [ ... ]
    }
  ]
}

As such, the SDK could automatically make the following request for the next iteration

      "fromBlock": "earliest",
      "toBlock": "0x429d3c",

Technical notes:

  • If the limit is 10000 logs, and the number of logs between block N and N+I excluded is 9999. But in block N+I there are 10 logs. Then we would return 9999 logs and put nextBlockResult: N+I
  • To make old code compatible, we should create an eth_getLogsV2

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0