improve(ProviderUtils): Avoid redundant eth_chainId rpc calls #308
Conversation
Since ethers v5, all RPC requests have been preceed by an eth_chainId lookup. This is described by ethers as a safety feature to mitigate being "RPC rugged" - i.e. where a wallet silently changes RPC without notifying the provider. Inspecting the Across logs, eth_chainId is the second-most popular RPC call, after only eth_getLogs. Over the past 30 days, Infura usage has been: eth_getLogs 264M eth_chainId 30M eth_call 24M eth_getTransactionReceipt 11M eth_blockNumber 3M Total 336M Given that the Across bots maintain a 1:1 relationship between provider instance and back-end RPC provider, there's no obvious way for the chainId to ever change. The StaticJsonRpcProvider is therefore provided by ethers for this scenario. It should be noted that the 30 day figures might be lower than normal due to downtime for both Arbitrum Nitro and the merge. In any case, migrating to StaticJsonRpcProvider would reduce total requests by about 9% based on these figures, and would predominantly help reduce latency in the bots. See also: ethers-io/ethers.js#901 Ref: ACX-67
pxrl
requested review from
mrice32,
nicholaspai and
chrismaree
as code owners
|
Note I half suspect that the impact of this might be a little bit muted, since this is likely to be an extremely fast request for the RPC endpoint to service. Still, it is redundant and it accounts for a significant portion of our request load, so I think the arguments for using the StaticJsonRpcProvider are pretty favourable. |
We have reasonably good reporting via Infura so I was planning to keep an eye on the usage dashboard. Alchemy's reporting seems even better and more fine-grained, but we're using them less. If you have any other suggestions for where else to look then I'm happy to follow up on that too! |
Ah yes good point on watching Infura usage, LGTM! |
Since ethers v5, all RPC requests have been preceed by an eth_chainId lookup. This is described by ethers as a safety feature to mitigate being "RPC rugged" - i.e. where a wallet silently changes RPC without notifying the provider.
Inspecting the Across logs, eth_chainId is the second-most popular RPC call, after only eth_getLogs. Over the past 30 days, Infura usage has been:
Given that the Across bots maintain a 1:1 relationship between provider instance and back-end RPC provider, there's no obvious way for the chainId to ever change. It's therefore worth considering using StaticJsonRpcProvider instead, since it's intended for exactly this scenario.
It should be noted that the 30 day figures might be lower than normal due to downtime for both Arbitrum Nitro and the merge. In any case, migrating to StaticJsonRpcProvider would reduce total requests by about 9% based on these figures, and would predominantly help reduce latency in the bots.
See also: ethers-io/ethers.js#901
Ref: ACX-67