Take A Moment and Dig Into Our Comprehensive Guide To CID NFTs!
Introduction
The C-Card is the default attribute display interface of ComingIDs (CID), and all CIDs come with NFT attributes (uniqueness and ownership transferability). Let’s begin to understand the functions of C-Card NFTs based on Coming IDs.
ERC721
The exploration of NFTs is fundamentally inseparable from the ERC721 standard. ERC721 defines “what an NFT can do” when it comes to the abstraction of sets of NFT operations.
Let’s analyze the composition of the ERC721 standard:
The main body of the ERC721 standard consists of the following four parts:
(1) ERC721 interface that must be implemented
a) 2 NFT Query Functions
// 查询账户拥有NFT的数量
function balanceOf(address _owner) external view returns (uint256);
// 查询NFT的属主
function ownerOf(uint256 _tokenId) external view returns (address);
b) 3 个 NFT Ownership Transfer Function
// NFT所有权转移(接收者为合约,并附带指定data)
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
// NFT所有权转移(接收者为合约)
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
// NFT所有权转移(接收者为普通账户)
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
c) 4 NFT Ownership Agent Functions
// 指定NFT所有权代理给_approved
function approve(address _approved, uint256 _tokenId) external payable;
// 指定账户下所有NFT所有权代理给_approved
function setApprovalForAll(address _operator, bool _approved) external;
// 查询指定NFT的代理账户
function getApproved(uint256 _tokenId) external view returns (address);
// 查询指定账户的代理账户是否匹配
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
(2) Must Achieve ERC721TokenReceiver Interface
// 处理safeTransferFrom传递过来的参数, 并返回4字节ERC165标识符
function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
In the world of Ethereum, an address may be a normal account or a contract account. In order to prevent the NFT from being permanently locked in the contract, the receiving contract can implement the ERC721TokenReceiver interface. When calling safeTransferFrom, the ERC721 contract will check whether the receiver is ERC721TokenReceiver, this means that the receiver knows how to handle ERC721Tokens.
(3) Optional ERC721Metadata interface
3 query functions
// NFT名称
function name() external view returns (string _name);
// NFT缩写
function symbol() external view returns (string _symbol);
// NFT属性链接
function tokenURI(uint256 _tokenId) external view returns (string);
(4) Optional ERC721Enumerable interface
3 query functions
// NFT总量
function totalSupply() external view returns (uint256);
// 查询NFT列表中指定索引的NFT
function tokenByIndex(uint256 _index) external view returns (uint256);
// 查询指定账户和NFT列表索引的NFT
function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);
How To Minimize ERC721 In The Substrate?
By deconstructing the ERC721 standard, we choose the core part of ERC721.
· First exclude the two optional implementation interfaces ERC721Metadata and ERC721Enumerable
· Then exclude a cross-contract call security interface ERC721TokenReceiver
· Then there is only one ERC721 interface left. In this interface, the two safeTransferFrom are also related to cross-contract calls, so safeTransferFrom is excluded.
Now there are balanceOf, ownerOf, transferFrom and 4 NFT ownership agent related functions.
In Ethereum and the world, cross-contract calls cannot directly change the internal storage of the called contract, and can only call the interface provided by the called contract.
Imagine a scenario without approval (ownership agent):
The user account holds a certain NFT and intends to auction this NFT. At this time, the owner of this NFT is account. Then when the auction contract produces a winner, can the Auction contract call the transfer of the ERC721 contract to complete the transfer of NFT ownership from account to winner?
If you can, you can write a contract to transfer the NFT managed by ERC721.
Obviously it cannot. Auction is not the owner of this NFT and has no right to transfer ownership.
Functions such as approve are designed to solve such problems.
The account can delegate the ownership of this NFT to the Auction contract to complete the transfer of ownership of the NFT.
Unlike Ethereum cross-contract calls (the deployer of the contract may not be the same), all substrate pallets are deployed by the same chain project party, making it safe and efficient to directly change the internal storage of the called pallet, and naturally it is not Need proxy functions like approve. Therefore, under the premise of ensuring the uniqueness of the NFT source, the smallest interface that implements ERC721 in the substrate pallet should include balanceOf, ownerOf, and transferFrom.
Realize C-Card NFT Function Based On Coming ID
Although the ERC721 standard explains “what can NFT do”, it does not explain the question of “what is NFT”.
Let’s try to define NFT: According to the related implementation of ERC721, we can find that the NFT operated from beginning to end is u256, which is 32 bytes of transparent data.
In the related ERC721 implementation, NFT -> Address guarantees the uniqueness of NFT and the transferability of ownership.
In summary, an NFT can be data of any format and size. More importantly, in the NFT function set, NFT should have uniqueness and transferability of ownership.
The existing CID implementation makes the CID unique and transferable. Therefore, CID stands for NFT.
What needs to be expanded at present is the C-Card.
Based on the above analysis, a C-Card exists as the default attribute of CID, in the existing CidDetails data structure.
pub struct CidDetails<AccountId> {
pub owner: AccountId,
pub bonds: Vec<BondData>,
// add the card
pub card: Vec<u8>,
}
A card field can be added, and various properties of C-Card can be converted into byte streams and stored in the card through simpler and commonly used json serialization methods.
On the basis of pallet-coming-id, NFT-related traits are stripped out and pallet-coming-NFT is implemented, so as to realize the decoupling of decentralized identity and NFT business.
pub trait ComingNFT<AccountId> {
fn mint(
origin: &AccountId,
cid: Cid,
card: Vec<u8>
) -> DispatchResult;
fn transfer(
origin: &AccountId,
cid: Cid,
recipient: &AccountId
) -> DispatchResult;
}
In summary, by binding the C-Card to the CID one-to-one, the NFT function of the C-Card is completed.
Reference Link
ERC-721 Non-Fungible Token Standard：https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.mdAn
Implementation of ERC-721：https://github.com/0xcert/ethereum-erc721
_______________________________________
Join the ChainX community!
ChainX official website https://chainx.org
ChainX online wallet https://wallet.chainx.org
Online browser: https://scan.chainx.org
Telegram group https://t.me/chainx.org
Development documentation https://github.com/chainx-org/ChainX/wiki
______________________________________
