Content
@
0 reply
0 recast
0 reaction
Jay Brower (jaymothy.eth)
@jayb
didn't find a great solution to typed multicall in go, so i built one. multicall is critical for reducing RPC utilization and vendor bills. Geth unfortunately doesn't come with anything out of the box to support this, and existing solutions that I found weren't typed or were under-documented. If you write backend services or golang that touches an ETH node, you should probably be multicalling. Just the other day, we reduced the cost of a migration we did from like 3.9 ETH to <2ETH by batching our transactions and avoiding fixed cost. Hope people find this useful! J https://github.com/jbrower95/multicall-go
2 replies
2 recasts
4 reactions
vrohlfs
@vrohlfs
Nice! One caveat is depending on your applications RPS there is a point of diminishing returns when using multicall on shared infra of RPC providers, and it’s more performant to parallelize workloads of simple eth_calls
1 reply
0 recast
0 reaction
Jay Brower (jaymothy.eth)
@jayb
mind elaborating? curious what you mean here.
1 reply
0 recast
0 reaction
vrohlfs
@vrohlfs
Fwiw this is more of a performance take (rather than economics). Infra providers process multicalls concurrently (the good ones at least), but that means your effective RPS is much higher on multicalls, which could impact latency, and ultimately cause failures on your workflows. For example, if your eth_call rps is 100, but you have 10 calls batched, ultimately the nodes need to be able to handle 1000 rps for your application alone at that moment.
1 reply
0 recast
0 reaction
Jay Brower (jaymothy.eth)
@jayb
haven't seen any issues like this, but totally agree - you are pushing nodes and ethereum to its limits with multicall. incredible simple and powerful tech
1 reply
0 recast
0 reaction
vrohlfs
@vrohlfs
fair point, you would most likely only encounter this at “uniswap-like” volume scales
0 reply
0 recast
0 reaction
