Open bonustrack opened 8 months ago
We're talking about these multicalls, right? This Multicaller is part of snapshot.js. Does it make sense to open an issue in the Snapshot.js repo and reference it here or should the multicaller only be replaced here and snapshot.js stays untouched?
And should the deployless multicaller be a complete replacement or just a fallback for the chains with no multicaller deployed? I can't tell yet what makes most sense and what problems I'll run into but I think I'll just start with a fresh MulticallerReadOnlyAnyChain.ts file somewhere.
Good to know: The performance impact is negligible.
Multicall: 17.145s Deployless Multicall: 18.412s Multicall2: 15.716s Deployless Multicall2: 15.772s
For now it doesnt have to be within Snapshot.js or Multicaller, it can be a script. We just want to get a script that work and benchmark it against normal multicall. There is also a Multicall3 you may want to test see if there is better performance. In term of performance we need to test not only how fast it resolve but what is the limit in term of number of calls that we can send within a single multicall request with deployless vs normal one.
Depending on the performance it can be a replacement for all our multicall requests on all the network. That would simplify our system a bit.
I'm testing here:
I moved ethcall and abi-coder to avoid esm compatibility issues and added a forceDeployless flag for testing.
yarn test --strategy=erc20-balance-of --more=245
Looks like 245 is the maximum.
Here you could add bytecode from other contracts that act as strategies.
See more context https://twitter.com/DestinerX/status/1446849311959093257
Using such technique we wouldn't need multicall deployment on each chain.