RPC method to report what historical data the node actually has

[Termina1]

Hi Geth team,

I’m Viacheslav Shebanov, CTO at dRPC (drpc.org). We run an RPC marketplace and route traffic across many independent node operators. A key goal for us is to keep small and mid-size providers competitive by sending each request to a node that can answer it correctly.

One problem we keep running into is simple: an RPC endpoint usually does not tell you what historical data it actually has. So we don’t reliably know whether a node can answer things like state at an old block, old receipts/txs, or logs over a wide range. Today we try to guess with heuristics and probing, but that is expensive and still often wrong. It causes misrouting, retries, and a worse experience for users.

I think it also would be useful for a lot of different RPC providers, who want to do automatic routing based on nodes' actual settings.

We want to start with Geth because it is the most established and reliable client, and a small, clear capabilities API here could become a good reference for others.

Proposal: add admin_capabilities
A small RPC method in the admin namespace that returns two things:

• config: the retention/pruning-related settings
• effective: what data is actually available (oldest block) and how it is removed over time (deletion strategy) for state, tx, logs, and blocks (bodies/receipts)

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "config": {
      "state": { "scheme": "path", "gcMode": null, "historyState": 90000 },
      "history": { "transactions": 2350000, "logs": 2350000, "logsDisabled": false, "chain": "all" },
      "pruning": { "historyPruned": false, "historyPrunedUpToBlock": null }
    },
    "effective": {
      "state": { "disabled": false, "oldestBlock": "0x12ab34", "deleteStrategy": { "type": "window", "retentionBlocks": 90000 } },
      "tx": { "disabled": false, "oldestBlock": "0x0f00aa", "deleteStrategy": { "type": "window", "retentionBlocks": 2350000 } },
      "logs": { "disabled": false, "oldestBlock": "0x0f00aa", "deleteStrategy": { "type": "window", "retentionBlocks": 2350000 } },
      "blocks": { "disabled": false, "oldestBlock": "0x0", "deleteStrategy": { "type": "none" } }
    }
  }
}

What do you think? We also are willing to help with specification and implementation if necessary.

Thanks,
Viacheslav Shebanov
CTO, dRPC (drpc.org)

[rjl493456442]

I think it's a reasonable feature request, I will discuss it with team.

[Oguidan]

Hi @rjl493456442 , I am curious about how it will be done

[s1na]

Hi @Termina1 I think it makes sense. I have proposed a similar idea here: ethereum/execution-apis#697. Curious why you propose the method being in the admin namespace and not eth?

[MariusVanDerWijden]

I like the idea as well. I think it would be best to propose this idea to ethereum/execution-apis so other clients can also weigh in on the proposal

[Termina1]

I like the idea as well. I think it would be best to propose this idea to ethereum/execution-apis so other clients can also weigh in on the proposal

I can do that, but in general it looks like most of the time this spec lagging even for established features. For example, it still doesn't have state override feature, while it is already supported in most production versions of the clients. So I am not sure how well maintained it is.

[s1na]

I can do that, but in general it looks like most of the time this spec lagging even for established features. For example, it still doesn't have state override feature, while it is already supported in most production versions of the clients. So I am not sure how well maintained it is.

Once there is concrete use-case or problem behind a proposal clients take it seriously. I can offer to try and get some eyes on it once you make the proposal.

[0xjvn]

Hii created an issue here on execution-apis, Mentioning here for visibility

#33828

[Termina1]

@s1na created spec PR