Allow to listen to multiple contract events at the same time

[liron-navon]

Describe the Feature

I can listen to contract events using "contract.on(filter, cb)", and I can get a filter using "contract.filters.MyEvent()".

But if I want to listen to multiple events on the same contract I have to call:

contract.on(filterA, cb)
contract.on(filterB, cb)
contract.on(filterC, cb)

What is the effect of these calls on performance and on the network? does each instantiate its own request?
is there a way to just make it work similarly to this?
Which will take fewer network calls, and should be simple to implement.

Code Example

contract.onAny([
   contract.filters.MyEventA(),
   contract.filters.MyEventB(),
   contract.filters.MyEventC()
],(index, ...event) => {
   console.log('called event', index, ...event)
})

[zemse]

Currently combining multiple general filters is not supported in ethers v5. And regarding the feature request, based on the current JSON RPC API (low-level requests to the node), it allows for specifying multiple values for address and each topic for matching anyone of them. Union of ethers Filters into an RPC filter would result in lot of unnecessary logs being matched which should not be. Though ethers could silently ignore them but it would cause unnecessary network overhead. That's why the FR would not make sense to be implemented.

For the short term, having the three listeners should be just fine if using the same provider as there would be a single block number tracker but still three eth_getLogs queries everytime block number change discovered. If your filter contains single topic (which seems from your code snippet), then you should be able to use the low level rpc API #473 (comment), this can reduce to a single getLogs query per block number change but that would add more logic to your code.

For long term, you may consider using indexing services like the graph instead of logs, that allow you to index things the way you want and query response time is faster. Also there are discussions that suggest removing the logs entirely from ethereum client, since external services like graph and more are getting matured and to reduce load on an eth node. Though I'm not sure if logs will be removed definitely from Ethereum protocol or when they would exactly.

[ricmoo]

I agree with @zemse description and explanation.

If you wish to optimize your getLogs query, it can be created on a case-by-case basis and the provider.on can be used, but the way bloom filters are combined is complex and non-obvious, so a simple high-level abstraction would likely result in unexpected results for most developers. So, the low-level API exists for people who wish to utilize it, but for most developers the high-level API will make more sense and probably won't change.