Determine appropriate namespace for "address appearances" method

[perama-v]

eth_getAddressAppearances may not be the best endpoint name.

Nodes are started with flags (or similar) that determine which namespace to activate for JSON-RPC

admin, debug, eth, net, trace, txpool, web3, rpc

So if the eth namespace (eth_getAddressAppearances) was used, this implies that a node started with the eth namespace flag would support this method.

It is not clear which method is best, or even if a new namespace is best.

• eth_getAddressAppearances
  • Vibe: for "all node must be able to support these"
  • Clients have at times made extensions to this namespace, and nodes can opt in to those. Same could apply here.
• debug_getAddressAppearances
  • Vibe: for geth-style tracing
• trace_getAddressAppearances
  • Vibe: for "openethereum-style" tracing
• web3_getAddressAppearances
  • Vibe: for node metadata
• new namespace address_*, with method address_getAppearances
  • Vibe: for address-centric data
  • Upside: Makes it clear this is new node functionality. Can group similar methods if they emerge.
  • Downside: Might be more overhead to provide or use a new namespace

New namespace address_*

The "address appearances" method requires a node to create an additional table/db/index internally, rather than compute the results on-the-fly.

New method family

Once present, the index enables a new family of endpoints:

• new namespace address_*
  • address_getAppearances.
    • Purpose: Discovery of which transactions are relevant to an address
    • Params: address
    • Returns: Every transaction id (block_num, tx_index) that involves the address
  • address_getInteractions
    • Purpose: Discovery of which transactions are relevant to a user address and a protocol
    • Params: array of address (e.g., [wallet_address, dapp_entrypoint_contract])
    • Returns: Every transaction id (block_num, tx_index) that involves both addresses.
    • Rationale: The address_getAppearances enables interactions to be found by making separate calls (one for each address) and finding the set intersection. Hence, this work can be trivially done by the node to avoid unnecessary work.
    • Comment: This could also be in another namespace e.g,. eth_getAddressInteractions. It would however be less clear to implementers that one really needs the "get appearances" method first.

Explicit opt in

Thus, starting a node with this flag explicitly makes this burden opt-in by passing an address flag: (address, admin, debug, eth, net, trace, txpool, web3, rpc). If not passed, the node does not create the index.

If it was instead included as part of another namespace, the node would create the index by default.