fallback provider / better error handling

[sakulstra]

Hello,

i've been using viem for a while now and one thing that (to me) feels really complicated is rpc error handling.
There#s a lot of cases that need manual intervention, but imo should be somewhat automatic.

Errors i faced in the past that are not handled by fallback:

• method not supported errors (e.g. calling getProof on a rpc that does not support it will just return the error but not retry)
• getLogs: the sad reality is that a lot of rpcs have certain, but different limitations on how many blocks you can query (saw 800, 10_000 and 100_000 in the wild). With a normal provider you usually know which limitations your call will have - with a fallback provider it's not so trivial as every rpc might have different ones and you don't know which one will resolve the request.

I guess one option could be to have a per rpc config where you can specify methods that are not supported (kind of a filter), so that for operation x, always a rpc supporting operation x is chosen.
For getLogs limitations, perhaps sth similar could work. You specify a maxBlockRange and the fallback would throw some sort of error if non of the provided rpcs support that range? Idk.

Would be curious if anyone has been able to "properly" solve this as it's a quite annoying issue with viem (same is true for ethers).

[sambacha]

There are two issues really we are dealing with: One is RPC related, the Second is the nature of events themselves. We maintain an extensive test suite against every worthwhile RPC provider for Ethereum (we use it for securerpc.com conformance testing). Here are some of the more notable provider quirks as it relates to eth_getLogs

Warning

The most restrictive RPC endpoint I have seen for eth_getLogs is QuickNode. They limit public queries to only 5 blocks from latest.

Quicknode

Errors

-32002,
message: request timed out

Infura

see https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_getlogs#constraints

-32005
Standard: EIP-1474,
message: query returned more than 10000 results

code: -32005
Standard: EIP-1474: Request limit exceeded
message: query timeout exceeded

AlchemyAPI

eth_getLogs requests on any block range with a cap of 10K logs in the response OR a 2K block range with no cap on logs in the response and 150MB limit on the response size¹

Other Encountered Errors

code: -3200
Standard: EIP-1474, EIP-1898
Server error: Invalid input, unable to locate canonical block

Code: 4200
Standard: EIP-1193: Unsupported Method
The requested method is not supported by this Ethereum provider.

Code: -32601
Method Not Found
JSON RPC Standard
Server error: Invalid input, unable to locate canonical block

indexed vs non-indexed signature collisions²

This one is quite problematic. Let's examine again the ubiquitous ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef signature. It corresponds to ERC20 Transfer(address indexed from, address indexed to, uint256 value).

However it also corresponds to the nowadays popular ERC721 Transfer(address indexed from, address indexed to, uint256 indexed tokenId) NFT transfer event. The issue is that the indexed parameter attribute also gets erased from the event signature before applying the keccak256.

It is not possible to guess which signature is the "correct" by just looking at the hash. The consequences are catastrophic, because the indexed attribute determines where you should look at when decoding the value.

safeBlockInThePast

We set this as the furthest block you could possibly query for our own services. Its a sane value. We have had issues where DApps (notably Sushiswap frontend) where they would erroneously query from genesis block to latest. This value

/**
* @export safeBlockInThePast
* @summary This is UniswapV2 Initial Deployment Block. Note that there is a gap between when it was deployed and when it saw any sort of meaningful use.
* @link https://github.com/NomicFoundation/hardhat/blob/master/packages/hardhat-core/test/internal/hardhat-network/provider/interval-mining-provider.ts#L15
*/

export const safeBlockInThePast = 11_200_000;

TLDR:

Really restrict getLogs to an epoch's worth of blocks IMHO.

fromBlock = `finalized`; toBlock = `latest`

Footnotes

1. source: https://docs.alchemy.com/docs/deep-dive-into-eth_getlogs#what-is-eth_getLogs-used-for? ↩

2. ref: https://github.com/otterscan/topic0/blob/main/docs/gotchas.md#indexed-vs-non-indexed-signature-collisions ↩

[jxom]

FWIW, consumers can control the strictness of event signature matching (ie. ambiguous selectors) via the strict property: https://viem.sh/docs/actions/public/getLogs#strict-mode

Can think more about how to better handle RPC provider log limits, etc.