Make batch call size configurable

[MartinquaXD]

We introduced the option to execute eth_calls in batches for performance improvements in case we had to do many eth_calls at once.
But we are currently experiencing major problems with our node infrastructure and especially how dshackle handles batch calls. One idea to mitigate those issues is to execute smaller batches. For that we have to make that configurable because we are currently relying on a few constants sprinkled through the code base.

I see 2 options how to do that:

1. Every component that uses a batch calls gets another constructor argument batch_size and passes that to CallBatch::execute_all(). This is simple to implement but leaks the implementation detail that we are doing batch calls into the signatures of every one of those components.
2. Instead of passing a simple web3 instance to these components we pass an abstraction which knows how to execute a multiple eth_calls. Then the original component no longer needs to be aware of whether the abstraction uses batch calls or a series of "normal" calls under the hood.

I would prefer option 2 because it has better separation of concerns.

[MartinquaXD]

Also since we define Web3 as a type alias in the shared crate we might also simply create a new type which derefs to the old Web3 type which also has the capabilities to do batch calls. Then we probably would only have to update the code where we create the (then different) Web3 type for our components to use.

[nlordell]

I also prefer option 2, which would additionally allow us to dynamically chose whether or not to actually batch calls.

There is this "auto-batcher" transport that we can use everywhere.

If we go that route, we need to improve logging (since it loses its tracing_span as it runs in a separate fiber).

[fleupold]

One thing we could potentially do in that case is to implement batching using a single eth_call (which calls the multicall contract with all the subcalls). This way we would also avoid dshackle "unbatching" our requests.

[sunce86]

Mentioning just so it would be linked: Replace JSON RPC batch calls with Multicalls.

[nlordell]

One thing we could potentially do in that case is to implement batching using a single eth_call (which calls the multicall contract with all the subcalls).

Ideally, this "decision" is something that transport::Buffered component could do based on configuration. This would only work for batched eth_calls though (and a few others like eth_getBlockNumber(latest) which is supported by the Multicall contract).

I like the idea though!

[sunce86]

One idea to mitigate those issues is to execute smaller batches.

Would this solve the issue or just reduce the number of batch call failures?
Asking because if, for example, we need 50 eth_calls for some functionality, splitting it into two chunks of 25 would not help if one of those chunks fail, because we usually need full 50 eth_calls to continue further.

[vkgnosis]

Using Multicall makes sense to me for cases where you want to enforce same state, because BatchCall does not guarantee this at all.
BatchCall is a tool to make many requests in a more efficient manner by reducing the number of individual connections. On the other hand there are also ways in which it could be less efficient like the server not being able to respond to requests the moment they finish. Even if that wasn't the case the difference in 1 vs 10 tcp connections is probably small enough to not matter in comparison to what else happens to respond to a request.
Based on this it makes sense to me to move most code to use normal eth calls which can be optionally batched in the background by something like transport::Buffered.

[nlordell]

which can be optionally batched in the background by something like transport::Buffered.

We can also add logic to make the transport::Buffered batch eth_calls into a Multicall.

[fleupold]

Some node providers (e.g. Ankr) charge based on the number of top_level eth_calls (not the amount of computation the call creates). Therefore using multicall could also help us save a good amount of money for our node infra.

[nlordell]

One issue is that not all eth_calls are possible. Specifically, if you need to specify a from address, or a things like gas_price, then you can't necessarily always group eth_calls together into a Multicall.