Create 0180-ton-standard-interface-detection

[awesome-doge]

A new TON Enhancement Proposal (TEP) has been added, proposing a standard interface detection mechanism for the TON blockchain. This is inspired by Ethereum's EIP-165 and aims to standardize methods for detecting and confirming the implementation of interfaces in smart contracts using FIFT, FUNC, and TACT languages. The proposal includes detailed specifications, example implementations, rationale behind the proposal, implementation steps, backward compatibility considerations, test cases and security considerations.

[mr-tron]

2 bytes ID it's only 65535 variants and can give a lot of collisions.

for NFT collection royalty_params and get_collection_data are not both part of NFT standard. roaylty it's standard extension and there are a lot of collections without royalty. so we need to check them separately. and because 2 bytes give a lot of collisions we should check is this method really works. so it's not better than just calling get_collection_data and royalty_params

[a2468834]

(1-1)
I agree that choosing a 2-byte function ID might face collisions. Originally, I used 32 bits as the function selector just like the convention we use in the internal message body OpCode. But the bit length of querying get-methods in the lite-client uses CRC16 checksum, I thought it's better to be compatible with this design and then turn function ID from 32 bits into 16 bits.

Currently, I'm on the fence that selecting a function ID to be consistent with 16-bit lite-client style or use 32-bit length. However, if you support the perspective not following the lite-client style in this topic, I think it's good to adopt the request flag 0x7fffffff and response flag 0x80000000 in this TEP.

(1-2)
There are two scenarios of this TEP: one is off-chain querying contracts through lite-client, and the other is on-chain sending an internal message to a specific contract.

The former will not get significant benefits (we can call lite-client simultaneously). However, the latter scenario will benefit from this TEP. I believe that it's not an efficient way to send several internal messages to the contract asking whether it supports a specific interface.

(2)
According to TEP-62, get_royalty_params() is the only one not included in the content. I admit this is a point that I wrote the example inaccurately. I will change the terminology in the example to NFT_ROYALTY_INTERFACE_ID() later.