Proposal: eth_getCapabilities method

[s1na]

Summary

Add a discovery method eth_getCapabilities that lets clients advertise what historical coverage their node actually maintains, so users, middleware, and infra can route queries correctly instead of trial-and-error or out-of-band guesses.

This is about data coverage, not feature flags. It answers questions like:
• Which transaction-hash index do you keep (from block X to block Y)?
• Which logs/receipts range do you keep?
• Which canonical block history do you serve?
• Which historical state (world-state) ranges can you answer eth_call/eth_getBalance/eth_getStorageAt for?
• Which trie node history (for proofs/time-travel state) do you keep?

Motivation

Nodes now run with varied pruning/indexing modes (archive, partial archive, snap-pruned, custom log indexers, state diffs, etc.). Without a standard discovery mechanism:
• Clients spray RPCs that fail unpredictably.
• Load balancers can’t route by capability.
• Users infer coverage from client brand/mode, which is error-prone.

A single, cheap call that returns machine-readable coverage ranges fixes this.

[s1na]

This is how the method can look like:

Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getCapabilities",
  "params": [{
    "namespaces": ["tx", "logs", "history", "state", "trie"]
  }]
}

Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "retrievedAt": {
      "block": "0x<blockNumber>",
      "hash":  "0x<blockHash>"
    },
    "safeBlock": "0x<blockNumber>",
    "finalizedBlock": "0x<blockNumber>",
    "tx":      { "intervals": [ { "start": "0x...", "end": "0x..." } ] },
    "logs":    { "intervals": [ { "start": "0x...", "end": "0x..." } ] },
    "history": { "intervals": [ { "start": "0x...", "end": "0x..." } ] },
    "state":   { "intervals": [ { "start": "0x...", "end": "0x..." } ] },
    "trie":    { "intervals": [ { "start": "0x...", "end": "0x..." } ] }
  }
}

Possibly allow for different pruning strategies: fixed vs rolling.