Get sig / topic hash directly from Fragment without an Interface instance?

[aspiers]

I know I can get an event's topic hash like this:

signature = "Transfer(address, address, uint)"  // not normalized
fragment = ethers.utils.EventFragment.from(signature)
emptyIface = new ethers.utils.Interface([])
topicHash = emptyIface.getEventTopic(fragment)

or like this:

normalized = fragment.format(ethers.utils.FormatTypes.sighash)
topicHash = ethers.utils.id(normalized)

or even:

iface = new ethers.utils.Interface([fragment])
iface.getEventTopic('Transfer')

but if I already have the fragment without an Interface, it seems crazy to me that I can't simply get it with something like fragment.topicHash or fragment.getTopicHash(). That would make the API so much friendlier, without requiring the developer to know specific aspects of EVM internals, i.e.:

1. that the topic hash is the keccak256 hash of the normalized event signature
2. how to normalize an event signature (trimming space / parameter names etc.)

This seems to me like such an obvious feature for the API to provide, that the fact I can't find it makes me suspect I'm missing something. But if I'm not, please consider this a feature request to add .topicHash or .getTopicHash() or similar to EventFragment.

And while I'm at it, presumably the same thing applies to sighashes of functions? I.e. adding FunctionFragment.sighash rather than requiring the use of an Interface or ethers.utils.id and knowledge of EVM internals.

Here are some architectural API design thoughts which I think justifies this feature request. Bearing in mind the benefits of clean abstraction layers / modularity / separation of concerns:

• An event's topic hash is only dependent on the event itself, not the interface(s) it belongs to.
• A function's sighash is only dependent on the function itself, not the interface(s) it belongs to.

So by this logic, the method or property providing access to a topic hash naturally belongs with the EventFragment, not with the interface. And similarly for function sighashes.

The fact that this example given above works:

topicHash = emptyIface.getEventTopic(fragment)

suggests to me that the separation of concerns is currently not quite right, because if an event's fragment is not contained in that interface, why should it be possible to get that event's topic via the interface? Indeed, emptyIface.getEventTopic('Transfer') throws an error (as expected, since the event signature is not known).

Of course, if the interface does contain the event, then it makes perfect sense for things like iface.getEventTopic('Transfer') to work. But that is a different situation where there is a direct link between the interface and the event.

Thanks!

[ricmoo]

So, ethers used to support chains that computed Event hash and Function selectors differently, which is why that logic lived in the Interface; so that the parsing logic for Human-Readable ABI and for fully populating JSON ABIs was isolated from the thing that actually needs to speak "blockchain". It also helps keep the lexer and parser from depending on keccak256, which would add a lot of extra code to those classes if not necessary (those chains used Blake instead of Keccak).

This meant for "weird" chains, I could just sub-class Interface and swap out a few static methods on in, and keep the library compact and flexible. And similarly, this is why ContractFactory has a static method for getting a Contract; the Contract class could be sub-classed and the custom Interface shoved in.

I do agree, this no longer makes sense since those chains have long since vanished, and I have been considering refactoring the Interface and Fragments for v6. This discussion may tip me over the edge to commit to it and re-write a bunch of stuff.

I'll add it to my @todo list to investigate for v6. :)

[aspiers]

Ahah, I see! I was pretty sure I'd be missing some good reasons ;-) Thanks a lot for the explanation!