Support for batching individual RPC calls

[holic]

I am trying to add an option into MUD's logs fetching mechanism (used to sync data from chain) that turns an RPC request like eth_getLogs into [eth_getBlockByNumber, eth_getLogs] to help with issues related to load balanced RPCs: https://indexsupply.com/shovel/docs/#unsynchronized-ethereum-nodes

However, I am failing to find a good entry point into Viem to do this without creating a bunch of wrappers around Viem things (e.g. http transport or rpc client) or "prop drilling" options through the whole MUD stack.

For context, when using MUD's sync tooling, you provide a Viem client, which allows users to configure their transport in a way that suits them/their RPC best (http vs ws, fallbacks, retries, etc.).

Some ideas on the Viem side that could help with this (ordered by favorite to least favorite):

• Extend EIP1193RequestFn or offer an alternative that supports batched calls like request([body, body]). I realize the EIP-1193 spec doesn't account for this, so I'm not sure how best to model this on the Viem side. This could would likely require some refactoring of the batch scheduler and de-duping.

• Expose transport options or whether batching is enabled. If I can detect that batching is enabled, I could do the RPC calls in parallel like Promise.all([eth_getBlockByNumber, eth_getLogs]) and expect the batch scheduler to put this into a single RPC call.

  • Without a Viem change, I could wrap the http transport or construct my own http transport internally to achieve this. Or expose an option in MUD that indicates batching is enabled or that it's safe to perform these two requests in parallel, but it would be more of a "hopeful" option - it'd be nice to be able to ensure/enforce that these go out in the same request.

• Expose url in HttpRpcClient so I can take this as a type of client for fetching logs and be able to throw RpcRequestError using the url. Without this, I'd have to make my own createHttpRpcClient wrapper that either exposes url or internally throws the RpcRequestError with the provided url.

  • The downside of using HttpRpcClient as a client type means we miss out on retry logic, fallback handling, etc. that transports give. So although this would be a small hole to poke, it probably isn't a great overall solution.

• Allow onRequest and onResponse overrides inside EIP1193RequestFn options. This means I could write a transport wrapper that taps into the RPC request/response lifecycle to transform specific eth_getLogs requests into the desired [eth_getBlockByNumber, eth_getLogs].

  • The downside of this is I'd have to account for already-batched requests, potentially duplicate the de-duping logic, and parse then stringify JSON to reverse the RPC call transformation. Sounds hairy.