Add primitives to support ERC165-like interface detection and other similar protocols

[leighmcculloch]

What problem does your feature solve?

ERC165 interface detection is well established protocol in the Ethereum ecosystem and EVM chains for doing a simple safety check that a protocol supports an interface at runtime.

Soroban does not contain the primitives for anyone wanting to replicate this pattern.

What would you like to see?

A primitive that provides for every element of the contract spec (function, type, event, error) an integer value, similar to the Solidity selector, that can be used in the same way that ERC-165 does for identifying if it is supported by a contract.

What alternatives are there?

If we explored the host understanding and learning about contract specs we could potentially introduce host functionality that could be used for introspecting the functions and types available on a contract. But this is a big lift, where a selector-like pattern would be much lower lift and constrained to contract-land allowing it to be something that gets innovated on independent of the Stellar protocol.

cc @mootz12 @marcelosalloum

[pedro-pelicioni]

Hopefully useful, and apologies if any of this is already on your radar. I spent some time on this one and found a couple of things that might help scope it.

The closest existing piece looks like the spec_id() in #1974. It is the first 8 bytes of SHA256 over an entry's own XDR.

It reaches types, errors and events, but not functions. generate_spec_id is called from derive_struct, derive_struct_tuple, derive_enum, derive_enum_int, derive_error_enum_int and derive_event, and never from derive_spec_fn.

I built the stack locally and compared the emitted wasm. #1965 and #1974 produce byte-identical wasm to main. #1970 does not, because it changes every type's name, which changes every entry's XDR, which in turn changes every spec_id.

That is what makes the scoping question concrete. If interface detection reuses the shaking id, any interface id published before #1970 lands would stop matching after it.

So, one id or two? Shaking needs the hash to cover the exact bytes in contractspecv0. Detection probably wants something stable across doc comments and module paths. Those two pull in different directions.

I would be glad to pick up a piece of this, but I do not want to cut across the #1965/#1970 stack. Is there a part you would want taken from outside?

[leighmcculloch]

That's a good observation about how old contracts upgraded to use the new sdk would result in new type ids. That'd have no negative impact in this case because the type id would just be a concept and not concrete in any old SDK contract. It would be important for the id to stay stable once released, so likely type ids will be rolled out as an experimental feature for sometime.

Not seeking code contributions for this as this time. I have a prototype built already that you referenced. It'll be revisited in the near future once I get a few other major changes that are touching the same code merged.

[pedro-pelicioni]

That's a good observation about how old contracts upgraded to use the new sdk would result in new type ids. That'd have no negative impact in this case because the type id would just be a concept and not concrete in any old SDK contract. It would be important for the id to stay stable once released, so likely type ids will be rolled out as an experimental feature for sometime.

Not seeking code contributions for this as this time. I have a prototype built already that you referenced. It'll be revisited in the near future once I get a few other major changes that are touching the same code merged.

Makes sense, and good point that nothing is published yet so there is nothing to break. Thanks for the context. I will keep an eye out for when it comes back around 🙏