Standard Interface Detection PSP

[varex83]

Summary

A standard for a standard interface detection for WebAssembly smart contracts which run on Substrate's contracts pallet.

This proposal aims to define the interface detection standard for WebAssembly smart contracts, inspired by EIP-165 for the Ethereum ecosystem.

Motivation

Motivation of this proposal is to provide a standard way for smart contracts to detect the interface of the smart contract they are interacting with. This is useful for smart contracts which interact with other smart contracts, as it allows them to detect the interface of the smart contract they are interacting with and adjust their behavior accordingly, without having any ABI of that contracts.

[DamianStraszak]

Thanks for preparing the proposal.

I would love to see some example for which PSP61 is useful to have and has benefits over not having it.

What we need to keep in mind is that a malicious contract can implement PSP61 and return whatever it wants for supports_interface and supported_interfaces.

[Artemka374]

Hey @DamianStraszak! It is useful in case of cross-contract interactions. For example, there is some amount of contracts, and one should call another, but there exists some predefined behaviour if called contract implements some trait, for example in terms of security to call something like before_received method to be able to deny transferring of tokens. This standard can be used to determine whether the contract implements demanded interface and to call methods from it using predefined selectors. It can be used in governance contracts where there should be some transaction executed in other contract. That is true, that contracts can implement the standard and return whatever they want, but that just means, that the contract will try to call non-existing method, which should be protected on caller's side to prevent something like reentrancy attacks.

[DamianStraszak]

That is true, that contracts can implement the standard and return whatever they want, but that just means, that the contract will try to call non-existing method, which should be protected on caller's side to prevent something like reentrancy attacks.

Yes, so what's the point of implementing the interface if you anyway can't trust the results you get from it. That's why I'm looking for a concrete example...

[Artemka374]

That is true, that contracts can implement the standard and return whatever they want, but that just means, that the contract will try to call non-existing method, which should be protected on caller's side to prevent something like reentrancy attacks.

Yes, so what's the point of implementing the interface if you anyway can't trust the results you get from it. That's why I'm looking for a concrete example...

I would like to copy here a point from our audit of OpenBrush, where the abscense of such standard was mentioned as an issue.

Some advantages of having standardized interface detection are:

1. Interoperability: It ensures that contracts can communicate and interact efficiently by checking for compatible interfaces. This is crucial in the decentralized ecosystem, where smart contracts interact with each other without relying on a central authority.

2. Efficient Function Calls: Provide a computationally efficient and standardized method to check for function signature support, which reduces the risk of unexpected errors and makes function calls more reliable.

3. Security: Prevents erroneous interactions between contracts by allowing them to check whether an interface is implemented before invoking specific functions. This can help prevent costly mistakes and potential security vulnerabilities.

4. Upgradeability: Since in the ink! programming language smart contracts can be upgraded, and new functionality can be added to existing contracts, this standardization would allow new versions of contracts to indicate support for the same interfaces as the previous versions, ensuring backward compatibility and smooth upgrades.

[DamianStraszak]

These are all generic and very vague, and most are not valid in the presence of malicious contracts. It would really help if you suggested at least one concrete example on how is this used.

I would even make a stronger point: I think it's dangerous to have contracts implement such interfaces. That's because developers don't understand that a particular response from a contract they get using such an interface cannot be trusted, and that's where they can make mistakes. Also implementing such interfaces makes everything more expensive gas-wise.