Use ERC-7746 for middleware hooks

[peersky]

noticed you guys are using extensively hooks in the enforcers.

It is very similar generic problem in the industry, e.g. Ironblocks and other companies implementing firewalls do same.

I’ve created https://ercs.ethereum.org/ERCS/erc-7746 to address this as generic industry problem so that we can have interoperable middleware hooks standard across industry.

I think you guys should contribute your ideas to it (and use it as a standard)!

[danfinlay]

Requires we pack all our gator-specific params into the bytes memory configuration, but otherwise we surely could. Given that it's still only compatible with usage that explicitly involves encoding for it, how big do we think the win of reusing this interface would be?

I tend to think using agnostic input types like that are mostly useful when someone else is composing them (like in ERC-7710 redeemDelegation(bytes authority, Action action), where the authority is flexible but the caller is not expected to compose it. Since in this case the caller will basically always be packing it, my first thought is that the usage doesn't end up being very easily intercompatible, it just looks the same on the surface.

[peersky]

@danfinlay I missed this in my notifications log, sorry for delayed response.

I agree that this adds encoding/packing difficulty, it would be much better if solidity/evm itself provided ways of type-safe middleware similarly as we can do in web2 frameworks.

But we don't have it, and using specific interfaces does not help interoperability at all.

The win I see is that anyone who is willing to use your contracts implemented as 7746 can just daisy chain in to same interface by adding your specific data.

E.g. configuration could decoded as address nextLayer, bytes nextLayerConfig, bytes yourLayerData so you can out of box allow anyone to compose further checks run from your contract, or vice versa.

Perhaps that standard would be more useful if such data appending mechanism would be also formalised?