You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some thoughts on smart contracts in TON and NFT contracts in specific:
I think we need some kind of mechanic's to distinguish some contracts from others.
In other term i think we need some way to look at the contract code & data on blockchain and distinguish that it's an NFT contract (or some other contract implementing some other well-known interface).
In case of NFT's this stuff will be useful for marketplaces to find new NFT's deployed to network.
It's also useful for blockchain explorers, we can implement some UI to interact with contracts (just like etherscan did)
I see three possible solutions for this stuff:
1 - each contract that wats to follow introspection mechanics implements some well-known GET method which returns either TL-B schema of it's interface or hash of that schema or some other data which uniquely defines interfaces of contract.
This approach was also described in original paper on TON ( 4.3.14 at https://newton-blockchain.github.io/docs/ton.pdf )
Actually we already have some kind of proposal for this: https://github.com/tonwhales/specs/blob/master/specs/tws-0001.md
2 - instead of well-known GET method we can put information about contract interface at the beginning of smart contract data cell.
3 - We can use some indirect signs to distinguish contracts. For example we can locally run contract and test it against list of GET and internal methods that contract should implement.
Since 1-2 don't actually guarantee anything - we can use some sort of combination of 1/2 + 3.
This approach have some benefits too:
Lets say we are searching blockchain for new NFT's, in that case we can firstly invoke magical GET method on contract and weed out contracts that definitely do not implement NFT interface. After we found contract that claims to be NFT we can run test as described in p. 3 to be confident that it's a genuine NFT contract.
I have some thoughts on smart contracts in TON and NFT contracts in specific:
I think we need some kind of mechanic's to distinguish some contracts from others.
In other term i think we need some way to look at the contract code & data on blockchain and distinguish that it's an NFT contract (or some other contract implementing some other well-known interface).
In case of NFT's this stuff will be useful for marketplaces to find new NFT's deployed to network.
It's also useful for blockchain explorers, we can implement some UI to interact with contracts (just like etherscan did)
I see three possible solutions for this stuff:
1 - each contract that wats to follow introspection mechanics implements some well-known GET method which returns either TL-B schema of it's interface or hash of that schema or some other data which uniquely defines interfaces of contract.
This approach was also described in original paper on TON ( 4.3.14 at https://newton-blockchain.github.io/docs/ton.pdf )
Actually we already have some kind of proposal for this: https://github.com/tonwhales/specs/blob/master/specs/tws-0001.md
2 - instead of well-known GET method we can put information about contract interface at the beginning of smart contract data cell.
3 - We can use some indirect signs to distinguish contracts. For example we can locally run contract and test it against list of GET and internal methods that contract should implement.
Since 1-2 don't actually guarantee anything - we can use some sort of combination of 1/2 + 3.
This approach have some benefits too:
Lets say we are searching blockchain for new NFT's, in that case we can firstly invoke magical GET method on contract and weed out contracts that definitely do not implement NFT interface. After we found contract that claims to be NFT we can run test as described in p. 3 to be confident that it's a genuine NFT contract.
Originally posted by @Naltox in ton-blockchain/TIPs#62 (comment)
The text was updated successfully, but these errors were encountered: