What is ERC-721? All kinds of encrypted cats and dogs we see now are created based on ERC-721, each one is a unique ERC-721 token, but ERC-721 is far more than cats and dogs in the blockchain world , its greater imagination is to map the assets of the physical world to the blockchain. This article will analyze what is ERC721.
What is ERC721
In the creation of tokens , we talked about ERC20 tokens.
Like ERC20, ERC721 is also a token standard. The official brief explanation of ERC721 is Non-Fungible Tokens, abbreviated as NFTs, which are mostly translated as non-homogeneous tokens.
ERC721 was proposed by Dieter Shirley in September 2017. Dieter Shirley is the technical director of Axiom Zen, the company behind CryptoKitties. Therefore, Mystery Cat is also the first decentralized application to implement the ERC721 standard. Proposal ERC721 has been accepted as a standard by Ethereum, but the standard is still in a draft stage. The ERC721 standard introduced in this article is based on the latest (2018/03/23 official proposal.
So how do you understand non-fungible tokens?
Non-homogeneity means uniqueness. Take enigmatic cats as an example. Each cat is endowed with genes and is unique (a cat is an NFTs), and cats cannot be replaced. This uniqueness makes certain rare cats collectible and sought after.
ERC20 tokens are replaceable and can be subdivided into N shares (1 = 10 * 0.1), while the smallest unit of ERC721 tokens is 1, which cannot be further divided.
Two items of the same set are inhomogeneous if they have different characteristics, and homogeneity is that a certain part or quantity can be replaced by another equal part or quantity.
Inhomogeneity actually exists widely in our life, such as every book in the library, every pet in the pet store, the songs sung by the singer, the different flowers in the flower shop, etc. Therefore, the ERC721 contract must have a wide range of application scenarios. Through such a standard, a cross-functional NFTs management and sales platform can also be established (just like there are exchanges and wallets that support ERC20), making the ecology more powerful.
ERC721 standard
ERC721 is the most contract standard. It provides the protocols that must be followed when implementing ERC721 tokens. Each ERC721 standard contract needs to implement ERC721 and ERC165 interfaces. The interface definitions are as follows:
pragma solidity ^0.4.20;
interface ERC721 /* is ERC165 */ {
event Transfer(address indexed _from, address indexed _to, uint256 _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 _tokenId);
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}Interface description:
* balanceOf(): Returns the number of NFTs held by _owner.
* ownerOf(): Returns the tokenId token holder's address.
* approve(): Grant the address _to the control of _tokenId, and trigger the Approval event after the method is successful.
* setApprovalForAll(): Grants the address _operator control of all NFTs, and triggers the ApprovalForAll event after success.
* getApproved(), isApprovedForAll(): Used to query authorization.
- safeTransferFrom(): Transfer NFT ownership, a successful transfer operation must trigger the Transer event. The implementation of the function requires several checks:
- The caller msg.sender should be the owner of the current tokenId or an authorized address
- _from must be the owner of _tokenId
- _tokenId should be any of the NFTs the current contract is monitoring
- _to address should not be 0
- If _to is a contract it should call its onERC721Received method, and check its return value and
bytes4(keccak256("onERC721Received(address,uint256,bytes)"))throw an exception if the return value is not.
A contract that can receive NFTs must implement the ERC721TokenReceiver interface:
interface ERC721TokenReceiver {
/// @return `bytes4(keccak256("onERC721Received(address,uint256,bytes)"))`
function onERC721Received(address _from, uint256 _tokenId, bytes data) external returns(bytes4);
}- transferFrom(): Used to transfer NFTs, the Transfer event needs to be triggered after the method is successful. The caller confirms that the _to address can receive the NFT normally, otherwise the NFT will be lost. When this function is implemented, it needs to check the first 4 items of the above conditions.
ERC165 standard
The ERC721 standard also requires compliance with the ERC165 standard, and its interface is as follows:
interface ERC165 {
function supportsInterface(bytes4 interfaceID) external view returns (bool);
}ERC165 is also a contract standard, which requires the contract to provide which interfaces it implements, so that when interacting with the contract, you can first call this interface to query.
interfaceID is the function selector, and there are two calculation methods, such as: bytes4(keccak256('supportsInterface(bytes4)'));or ERC165.supportsInterface.selector, the interface ID of multiple functions is the XOR value of the function selector.
Regarding ERC165, there is no in-depth introduction here. Interested students can read the official proposal .
Optional implementation interface: ERC721Metadata
The ERC721Metadata interface is used to provide the metadata of the contract: name , symbol and URI (the resource corresponding to the NFT).
Its interface is defined as follows:
interface ERC721Metadata /* is ERC721 */ {
function name() external pure returns (string _name);
function symbol() external pure returns (string _symbol);
function tokenURI(uint256 _tokenId) external view returns (string);
}Interface description:
* name(): Returns the contract name, although it is optional, it is strongly recommended to implement, even if it returns an empty string.
* symbol(): Returns the contract token symbol, although optional, it is strongly recommended to implement, even if it returns an empty string.
* tokenURI(): Returns the URI of the external resource file corresponding to _tokenId (usually an IPFS or HTTP(S) path). The external resource file needs to contain the name, description, and image, and the format requirements are as follows:
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this NFT represents",
},
"description": {
"type": "string",
"description": "Describes the asset to which this NFT represents",
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
}
}
}The tokenURI is usually called by web3 for corresponding query and display at the application layer.
Optional implementation interface: ERC721Enumerable
The main purpose of ERC721Enumerable is to improve the accessibility of NTF in the contract, and its interface is defined as follows:
interface ERC721Enumerable /* is ERC721 */ {
function totalSupply() external view returns (uint256);
function tokenByIndex(uint256 _index) external view returns (uint256);
function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);
}Interface description:
* totalSupply(): returns the total amount of NFT
* tokenByIndex(): returns the corresponding tokenId by index.
* tokenOfOwnerByIndex(): The owner can own multiple NFTs at a time, this function returns the tokenId of the corresponding index in the NFT list owned by the _owner.
Supplementary Instructions
NTF IDs
NTF ID, namely tokenId, is identified by a unique uint265 in the contract, and the ID of each NFT is not allowed to change during the life cycle of the smart contract. The recommended implementation methods are:
1. Starting from 0, each time a new NFT is added, the NTF ID is incremented by 1
2. After using sha3, the uuid is converted to an NTF ID
Compatibility with ERC-20
The ERC721 standard follows the semantics of ERC-20 as much as possible, but due to the fundamental differences between homogeneous tokens and non-homogeneous tokens, it is not fully compatible with ERC-20.
Trading, Mining, Destruction
When implementing transter-related interfaces, in addition to meeting the above conditions, we can add our own logic as needed, such as adding blacklists.
Simultaneous mining and destruction, although not part of the standard, we can implement as needed.
reference implementation
The reference implementation is the exclusive benefit of subscribers, please subscribe to my small column: Blockchain Technology View.
references
Welcome to my knowledge planet to explain the blockchain in a simple way to discuss the blockchain. As a benefit of star friends, star friends can join the paid exchange group of blockchain technology.
Explain the blockchain in simple terms - learn blockchain systematically and create the best blockchain technology blog.