forked from DecentralizedClimateFoundation/DCIPs
125 lines
6.0 KiB
Markdown
125 lines
6.0 KiB
Markdown
---
|
|
eip: 4341
|
|
title: Ordered NFT Batch Standard
|
|
description: The ordering information of multiple NFTs is retained and managed
|
|
author: Simon Tian (@simontianx)
|
|
discussions-to: https://github.com/ethereum/EIPs/issues/3782
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: ERC
|
|
created: 2021-10-01
|
|
---
|
|
|
|
## 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 `tokenId`s 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
|
|
[ERC-721](./eip-721.md) and [ERC-1155](./eip-1155.md), the ordering information of
|
|
multiple NFTs is discarded. However, as proposed in [EIP-3754](./eip-3754.md),
|
|
non-fungible tokens are thought of as basic units on a blockchain and can carry
|
|
abstract meanings with unicoded `tokenId`s. Transferring such tokens is transmitting
|
|
an ordered sequence of unicodes, thus effectively transmitting phrases or meanings
|
|
on a blockchain.
|
|
|
|
A **[logograph](https://en.wikipedia.org/wiki/Logogram)** is a written character
|
|
that represents a word or morpheme, examples include _hanzi_ in Mandarin, _kanji_
|
|
in Japanese, _hanja_ in Korean, and etc. A [unicode](https://en.wikipedia.org/wiki/Unicode)
|
|
is an information technology standard for the consistent encoding, representation, and
|
|
handling of texts.
|
|
|
|
It is natural to combine the two to create unicoded NFTs to represent logographic
|
|
characters. Since a rich amount of meanings can be transmitted in just a few
|
|
characters in such languages, it is technically practical and valuable to create
|
|
a standard for it. Emojis are similar with logographs and can be included as well.
|
|
For non-logographic languages such as English, although the same standard can be
|
|
applied, it is tedious to represent each letter with an NFT, hence the gain is
|
|
hardly justifiable.
|
|
|
|
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 the key difference between this standard and [ERC-1155](./eip-1155.md).
|
|
|
|
Besides, in the eastern Asian culture, characters are sometimes considered or
|
|
practically used as gifts in holidays such as Spring Feastival, etc.
|
|
`(24685, 21916, 21457, 36001)` `恭喜发财` can be used literally as a gift to
|
|
express the best wishes for financial prosperity. It is therefore cuturally
|
|
natural to transfer tokens to express meanings with this standard.
|
|
|
|
Also in logographic language systems, ancient teachings are usually written in
|
|
concise ways 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.
|
|
|
|
## Specification
|
|
```
|
|
pragma solidity ^0.8.0;
|
|
|
|
/**
|
|
@title EIP-4341 Multi Ordered NFT Standard
|
|
@dev See https://eips.ethereum.org/EIPS/eip-4341
|
|
*/
|
|
interface ERC4341 /* is ERC165 */ {
|
|
event Transfer(address indexed from, address indexed to, uint256 id, uint256 amount);
|
|
|
|
event TransferBatch(address indexed from, address indexed to, uint256[] ids, uint256[] amounts);
|
|
|
|
event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
|
|
|
|
function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes calldata data) external;
|
|
|
|
function safeBatchTransferFrom(address from, address to, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata data) external;
|
|
|
|
function safePhraseTransferFrom(address from, address to, uint256[] calldata phrase, bytes calldata data) external;
|
|
|
|
function balanceOf(address owner, uint256 id) external view returns (uint256);
|
|
|
|
function balanceOfPhrase(address owner) external view returns (uint256);
|
|
|
|
function balanceOfBatch(address[] calldata owners, uint256[] calldata ids) external view returns (uint256[] memory);
|
|
|
|
function retrievePhrase(address owner, uint256 phraseId) external view returns (uint256[] memory);
|
|
|
|
function setApprovalForAll(address operator, bool approved) external;
|
|
|
|
function isApprovedForAll(address owner, address operator) external view returns (bool);
|
|
}
|
|
```
|
|
|
|
## Rationale
|
|
In [ERC-1155](./eip-1155.md) and [ERC-721](./eip-721.md), NFTs are used to represent
|
|
crypto-assets, and in this standard together with [EIP-3754](./eip-3754.md), NFTs
|
|
are equipped with utilities. In this standard, the ordering information of a batch
|
|
of NFTs is retained and managed through a construct `phrase`.
|
|
|
|
### Phrase
|
|
A `phrase` is usually made of a handful of basic characters or an orderred sequence
|
|
of unicodes and is able to keep the ordering information in a batch of tokens.
|
|
Technically, it is stored in an array of unsigned integers, and is not supposed
|
|
to be disseminated. A phrase does not increase or decrease the amount of any NFT
|
|
in anyway. A phrase cannot be transferred, however, it can be retrieved and
|
|
decoded to restore the original sequence of unicodes. The phrase information
|
|
is kept in storage and hence additional storage than [ERC-1155](./eip-1155.md) is required.
|
|
|
|
## Backwards Compatibility
|
|
[EIP-3754](./eip-3754.md) is the pre-requisite to this standard.
|
|
|
|
## Reference Implementation
|
|
https://github.com/simontianx/ERC4341
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|