search

neo-project / proposals

NEO Enhancement Proposals
Creative Commons Attribution 4.0 International
136 stars 113 forks source link

Multi Token Standard #146

Open jastez opened 2 years ago

jastez commented 2 years ago

Neo is in need of a multi token standard. https://ethereum.org/en/developers/docs/standards/tokens/erc-1155/#:~:text=What%20is%20meant%20by%20Multi,both%20at%20the%20same%20time.

erikzhang commented 2 years ago

Ethereum needs it because an Ethereum transaction can contain only one invocation. Neo doesn't need it.

crzypatchwork commented 2 years ago

https://github.com/enjin/erc-1155/blob/678092281094b7cd5328b417c677be05338ea0d6/contracts/ERC1155Mintable.sol#L40 also wondering if it would be possible to achieve this "semi-fungible" behavior

erikzhang commented 2 years ago

https://github.com/neo-project/non-native-contracts/tree/master/src/AssetCombiner

Does this solve the issue?

jastez commented 2 years ago

Do you plan on making this a standard? There would need to be a standard interface for any project to adopt. Furthermore, this seems to be a Nep 11 that serves as a proxy to n number of Nep 11/17 tokens. It seems this is more of an escrow or holding type of behavior, as opposed to a true multi token standard.

Also, how would you dynamically create more tokens?

Please see https://eips.ethereum.org/EIPS/eip-1155#motivation 

It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.

I mentioned batch transfers but there are several more reasons, batch management in particular.

steven1227 commented 2 years ago

The dynamically token creation can be invoked by ContractManagement.Deploy. I do not think it is related to this standard issue?

EdgeDLT commented 2 years ago

The dynamically token creation can be invoked by ContractManagement.Deploy. I do not think it is related to this standard issue?

I believe this proposal is referring to the ability to manage multiple tokens (and token types) within a single contract, rather than deploying a contract for each token.

roman-khimov commented 2 years ago

I'm not an NFT or E-letter chain expert, but I've tried to take a look at this out of curiosity. The batching part of EIP-1155 really is irrelevant for Neo, but at the same time AssetCombiner and/or deploying more and more tokens doesn't give the same abilities it provides. Let me quote the motivational part of it:

Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them.

While Neo makes managing a number of interacting asset contracts much easier just due to the way calls are performed and features like contract groups, still this requires deploying and managing them. It costs GAS and makes development somewhat more complex.

In some ways ERC-1155 reminds of divisible NEP-11 (balanceOf, transfer with token ID and amount), but there is one key difference --- while NEP-11 has decimals the same for all tokens, so if it's 2 then every token can be split into 100 pieces that will be treated like pieces (one minted divisible token is 1 in totalSupply count even it has 100 pieces), ERC-1155 allows tokens to have individual divisibility and supply rules. That is one token ID can be absolutely unique and another one can have decimals of 18 with supply of more than 10^18. All of that in a single ERC-1155 token contract.

We can do this with some kind of "dynamically divisible" NFT standard, where there won't be a contract-level decimals() method, but decimals(tokenID) and maybe a totalSupply(tokenID) (if we're to support token supply going over 10^decimals), but otherwise looking pretty much the same as divisible NEP-11.