8000 Create 0180-ton-standard-interface-detection by awesome-doge · Pull Request #180 · ton-blockchain/TEPs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Create 0180-ton-standard-interface-detection #180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Create 0180-ton-standard-interface-detection #180

wants to merge 4 commits into from
+108 −0

Conversation

awesome-doge
Copy link
Contributor

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.

@awesome-doge
Introduced TON Standard Interface Detection
0e47158 
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.
@awesome-doge awesome-doge changed the title Create 0180-ton-standard-interface-detection.md Create 0180-ton-standard-interface-detection Jul 29, 2024
@mr-tron
Copy link
mr-tron commented Aug 14, 2024

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
Copy link
a2468834 commented Aug 26, 2024 •
edited
Loading

(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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@MrG9090 MrG9090 MrG9090 approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@awesome-doge @mr-tron @a2468834 @MrG9090
0