search

neo-project / neo

NEO Smart Economy
MIT License
3.47k stars 1.03k forks source link

Extend supported standards in manifest #2355

Closed fyrchik closed 1 month ago

fyrchik commented 3 years ago

Summary or problem description Currently supportedStandards field in manifest specifies standards which manifest supports. However, for example, NFT PR https://github.com/neo-project/proposals/pull/130/files actually defines 3 interfaces:

  1. Divisible NFT
  2. Non-divisible NFT
  3. Method for receiving NEP-11 tokens, which can be present in any contract, not only 1 or 2.

Do you have any solution you want to propose? Be more specific (may be change supportedStandards to supportedInterfaces). Something like NEP-11/Divisible or NEP-11/Payable etc. This way it is more descriptive and checks can be easily enforced during compilation or contract deployment.

Neo Version

roman-khimov commented 3 years ago

Related to #1883. It'd be nice for SupportedStandards to have some meaningful interpretation, a contract specifying "NEP-11" there could actually mean any of the three interfaces mentioned above (or combination of them), so some kind of convention is needed for various subsets of standards (that should probably also be specified in NEPs, like "contract implementing non-divisible NFT interface SHOULD specify NEP-11/Non-divisible in its SupportedStandards).

erikzhang commented 3 years ago

Divisible NFT Non-divisible NFT

They should be checked by calling decimal() of the contract.

Method for receiving NEP-11 tokens

The receiver contract should not add NEP-11 to its manifest. We can check whether a contract contains the onNEP11Payment method to determine whether it supports receiving NEP-11 assets.

roman-khimov commented 3 years ago

They should be checked by calling decimal() of the contract.

It's easy for a node to do that (as in #1883), but can be non-trivial for compiler. Compiler is not supposed to execute the contract, yet it can (and in case of neo-go does) check for standard compliance.

We can check whether a contract contains the onNEP11Payment

This works, but at the same I think it can be useful to have this specified in SupportedStandards.

erikzhang commented 3 years ago

Compilers don't care about SupportedStandards. They should use the abi of the contract.

roman-khimov commented 1 month ago

I doubt we'll ever solve divisible/non-divisible (at least if we're not replacing NEP-11), but we are much better now with receiver methods defined in NEP-26 and NEP-27, so closing this one.