EIP-4341: Multi NFT Ordered Standard

[simontianx]

Abstract

This standard introduces a smart contract interface that can represent a batch of non-fungible tokens of which the ordering information shall be retained and managed. Such information is particularly useful if tokenIds are encoded with the sets of unicodes for logographic characters and emojis. As a result, NFTs can be utilized as carriers of meanings.

Motivation

Non-fungible tokens are widely accepted as carriers of crypto-assets, hence in both ERC721 and [ERC1155] https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md), the ordering information of multiple NFTs is discarded. However, as proposed in EIP-3754, non-fungible tokens are thought of as basic units on a blockchain and can carry abstract meanings with unicoded tokenIds. Transferring
such tokens is transmitting an ordered sequence of unicodes, thus effectively transmitting phrases or meanings on a blockchain.

This standard aims to combine the two and introduce the necessary functionalities for batch transfer and representation of logographic characters. As a result, a language system can be built on-chain for logograpic languages.

For non-logographic languages such as English, although the same standard can be applied, the marginal utility is minimal to be practically useful. However, for logographic languages, since a rich amount of meanings can be transmitted in just a few characters, this standard is therefore particularly valuable. Emojis are similar with logographs and can be included as well.

A motivating example is instead of sending the two Chinese characters of the Great Wall 长城, two NFTs with IDs #38271 and #22478 respectively can be transferred in a batch. The two IDs are corresponding to the decimal unicode of the two characters. The receiving end decodes the IDs and retrieves the original characters. A key point is the ordering information matters in this scenario since the tuples (38271, 22478) and (22478, 38271) can be decoded as 长城 and 城长, respectively, and both are legitimate words in the Chinese language. This illustrates one key difference between this standard and ERC1155.

In-game characters, weapons, items can be represented by very few characters. Examples include 关羽 (20851, 32701) a famous fighter, 剑 (21073) a sword, 药水 (33647, 27700) a potion, and etc. On-chain gaming dapps can be largely enriched with elements by simply adopting this standard for players using logographic languages.

Besides, in the eastern Asian culture, characters are sometimes considered or practically used as gifts in holidays such as Spring Feastival, and etc. The characters 恭喜发财 or (24685, 21916, 21457, 36001) can be literally sent as a gift to express the best wishes for financial prosperity. That said, logographs do possess the nature of an asset, which is well resembled by this standard.

What is even more interesting is in that culture, people consider ancient teachings as treasures which are usually written in a concise way such that a handful of characters can unfold a rich amount of meanings. Modern people now get a reliable technical means to pass down their words, poems and proverbs to the future generations by sending tokens.

Other practical and interesting applications include Chinese chess, wedding vows, family generation quotes and sayings, funeral commendation words, prayers, anecdotes and etc.

[abcoathup]

Instead of sending the Chinese letters of the Great Wall 长城, two EIP-3754 tokens with ID#38271 and ID#22478 are sent in order to represent the two letters. The receiving end decodes the IDs and retrieves the original logographic characters.

Transaction fees even on layer 2 wouldn't make this practical for sending tokens instead of characters.

Even with such a use case couldn't this be implemented using ERC1155?

[simontianx]

@abcoathup Hen Andrew, thanks for the question.

ERC1155 has URI and ERC20 support which do not seem to fit in this scenario. To say it is for communication is really just for illustration purposes. Logographic characters are very similar to Lego parts and pieces, which can be collected, reused, reordered, reorganized and resent. A standard should be tailored for this type of tokens.

Regarding gas fees, yes, it is ridiciously high on Ethereum, a possible solution is to build this on xDai, Polygon or even a dedicated sidechain.

The vision is for sure not for daily communication, nontheless, occasionally people do have the need of finding a more secure way, a more decentralized way, or a more censorship-resistent way of communicating. Besides, a logograph-based reward point system can also be built on top of this token system. This might be something unheard of in the English-speaking world, but we have been picturing this mentally for a while and there is a strong market need for this type of cross-business reward system. Imagine the points you earned on Amazon for buying books are logographs of books, which are then consumed for a discount in a book-themed park in Disneyland.

[abcoathup]

A Logographic use case could be implemented using ERC1155, so I don't see the need for a new EIP.

The metadata extension is optional in ERC1155.
https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions

[simontianx]

@abcoathup I can understand the sense that ERC1155 can transmit multiple tokens in a batch is similar to the business needs described above, but logographs are not merely tokens, whose orders and compartmentalization are meaningful and hence require functions and data structures to deal with these new features. Take the example given above, (#38271, #22478) 长城 and (#22478, #38271) 城长 are both legitmate words in that language and should be distinguished. ERC1155 is unable to make a distinction.

[lightclient]

It seems like what you want is "strict ordering of batched tokens". With that primitive you can build your unicode NFT token. It feels like that is what your EIP should be, unrelated to unicode.

[wschwab]

Hi! I wanted to get a better feel for what this ERC is looking to do. Is each tokenId in the contract tokenizing a Unicode value, and then they can be turned into a phrase, which can then be transferred. Is this the case?

One of the reasons I'm asking is to try and potentially focus the ERC more, or potentially split it out into more than one. At first glance it seems to me that there isn't a need to have an ERC specifically about tokenizing Unicode points, but the concept of a strictly ordered "NFT of NFTs" is very relevant. This might come from me misunderstanding the proposal, though. (This is pretty much an echo of @lightclient 's point immediately above.)

Cheers!

[simontianx]

Hi! I wanted to get a better feel for what this ERC is looking to do. Is each tokenId in the contract tokenizing a Unicode value, and then they can be turned into a phrase, which can then be transferred. Is this the case?

Essentially, yes. Thanks for pointing that out.

This was proposed with a specific scenario in mind, and yes, technically, as you put it, the new thing is a strictly ordered "NFT of NFTs".

[simontianx]

It seems like what you want is "strict ordering of batched tokens". With that primitive you can build your unicode NFT token. It feels like that is what your EIP should be, unrelated to unicode.

Yes, thanks for pointing this out. This was proposed with a specific scenario in mind.

[chee-chyuan]

Hi just wanting to know more about this too. afaik, the chinese characters have a few thousand letters and these needs to be stored on the blockchain?

also, whats your idea to allow user to search for a specific character?

[simontianx]

Hi just wanting to know more about this too. afaik, the chinese characters have a few thousand letters and these needs to be stored on the blockchain?

Actually there are more than ten thousand Chinese letters alone not including Korean and Japanese letters. Fortunately, those letters do not need to take additional storage on a blockchain at all. Currently, tokenIds are not utilized to carry meanings and unicodes can make use of this data field to represent logographical letters.

also, whats your idea to allow user to search for a specific character?

Events will be emitted if a batch of such tokens are being transferred. Searching can be easily done via the traditional database technologies.

This EIP is in the stage of collecting first round feedbacks. Suggestions and comments are more than welcome.

[daweth]

Why is logographic characters >> cryptography in this use case? If you want to represent data more concisely the best way to do it is using mathematics, no?

[simontianx]

@daweth Not sure if I'm understanding your questions clearly. I think cryptography is a low-level supporting technology to make the transfer of NFTs with unicoded tokenIds possible, and the net outcome is transmitting logographic characters on the high-level. They are at different levels of technical hierarchy and serve different purposes.

If you want to represent data more concisely the best way to do it is using mathematics, no?

I consider math as a way of representing logic which is more abstract than data which represents a concrete measurement of certain quantity. Not sure if they can be compared apple-to-apple.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[simontianx]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

Still believe there is great potential in this EIP. Expecting to have major updates in the coming week or two. Please do not move this EIP to stale.

[Pandapip1]

EIP-4341 is stagnant. If the authors would like to move it out, a new discussion link must be created on eth magicians