Event Filter Flexibility: Constrain only some topics to a specific contract address when multiple topics are specified.

[RyanCross]

Describe the Feature

Disclaimer, I know this can be accomplished with two separate filters, but it would be the bee's knees if this could be done with a single ethers Filter.

Let's say I want to create a single filter that retrieves the event history of a company's smart contracts. I can easily create a filter for getting all contract-specific defined events because I can just specify the topics and leave the address as undefined. I run into an issue when I also want to capture a common ERC event like Transfer, which are also emitted from several of our ERC-721 compliant contracts. I can't specify that I just want the transfers from the address or (addresses) of the contracts I care about) in that same filter.

Not sure how reasonable of an ask this is, but it would be great for code simplicity on the consumer end and help with scaling to have a flexible filter that can accommodate the use case above.

Code Example

//here's a very rough example of what it might look like on the consumer end

 // some array of event topics 
const eventTopics = {
  MetadataChanged: "0x1111",
  BidAccepted: "0x2222,
  Transfer: "0x3333" // ERC Transfer event 
}

const filter: Filter = {
    address: undefined
    topics: [ [ eventTopics.MetadataChanged, eventTopics.BidAccepted, eventTopics.Transfer ] ],
    // all other events can come from any contract, but transfer must have been emitted by "0x1234"
    constraints: [ { eventTopics.Transfer: ["0x1234"] } ]
    fromBlock: 12562655,
    toBlock: latestBlock,
  };

  const logs = await provider.getLogs(filter);
  const parsedLogs = logs.map((log) => {
    const interface = eventToParserInterface[log.topics[0]];
    const parsedLog = interface.parseLog(log);
    return parsedLog;
  });

[RyanCross]

@ricmoo any chance this feature could be implemented in the future?

[ricmoo]

This is not something a bloom filter can handle, which is how Ethereum is able to efficiently filter and return a subset of events from the entire history of the blockchain, so it would have to happen in the client anyways (over asking for events, and then dropping the uninteresting ones one the floor).

I think rather than the library having complex descriptions of thing s to drop, this is more easily handled by using two filters to use minimal bandwidth or let the receiver use .filter and .map on the returned Array, you have above.