NFT 标准 ERC1155 和 ERC721 比较说明

EIP 与 ERC 概念

EIP ( Ethereum Improvement Proposals )，EIP 是一个为 Ethereum 社群提供信息的设计文件，或是用来为 Ethereum描述一些新的功能或环境，类似互联网上IETF的RFC，在设计EIP的文件里面，应提供该功能的简明技术规范，和该功能的基本原理，而EIP的作者需要自行负责文件，在社群里面的共识。

ERC全名为Ethereum Request for Comments，ERC是在Standard Track EIP里面中的其中一个项目，由于ERC所要讨论的范围是"应用程序层级的标准和协定"，这个协定发布出来后有些开发者就会遵循这个标准来开发程序。开发人员可以通过提交EIP，来向以太坊社群，提出新的ERC标准提案，提交的内容包括协议规范和合同标准。一旦EIP得到以太坊委员会的批准并最终确定后，它将成为新的ERC，新的ERC提供了一套可以为以太坊开发人员实施的标准，开发人员可以使用这些标准来构建智能合约。

简言之，EIP 是一些改进的建议，ERC 是针对 EIP 实现的标准、协议说明和代码实现，EIP 是建议文本，ERC 已经进入可执行的代码和协议层面了。

ERC721 vs ERC1155

ERC721 与 ERC1155 是 Ethereum 以及所有 EVM 兼容链生态最重要的 NFT（ Non-Fungible Token ）标准协议。其他与 NFT 有关的标准有 ERC721A（ ERC721 扩展协议）、 ERC2981（版税标准协议）、ERC4907（ NFT 借贷标准协议）。其他非 EVM 兼容链大多也参考 ERC721 和 ERC1155 定义了相关的智能合约标准，或是链上的原生 NFT 标准。链上原生 NFT 标准会有比较多的功能限制，扩展能力有限，大多数场景还是会考虑使用智能合约的实现方式。

ERC721

• Non-Fungible Token Standard，A standard interface for non-fungible tokens, also known as deeds.

• 详细说明参看 EIP 说明文档 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

• 一个 ERC721 合约只实现一个系列的 NFT

• 一个标准的 ERC 721 NFT 通常包含

￮名字，name

￮缩写符号，symbol

￮ tokenID，一般是自增长的 ID，每一个 NFT 都需要有一个唯一的 tokenID

￮属性描述文件，一般是一个 JSON 文件可以存在网络文件中，也可以直接写到链上，NFT 的介绍、属性、媒体文件链接存在描述文件中

￮媒体文件，可以存储在网络文件中，也可以直接写在链上，写入链上的数据大小有限，大多数都是存储在网络文件中，并将媒体文件链接存在描述文件中

￮以下是一个常见的 Json 描述文件的例子

{
  "name": "Seven-step poem.",
  "description": "This is a nft generate by Come Social.",
  "external_url": "https://yourdomain.io",
  "image": "ipfs://QmTsMtab9kzXc72L8LNMvtZRp3Rfd8YLdujtsnvTTBZSMx",
  "attributes": [
    {
      "trait_type": "Author", 
      "value": "Artist"
    }, 
    {
      "trait_type": "Creation Date", 
      "value": "2022-05-01"
    }, 
    {
      "trait_type": "Work Type", 
      "value": "Ink on rice paper"
    },
    {
      "trait_type": "Origin Size", 
      "value": "68x68cm"
    },
    {
      "trait_type": "Mint Quantity", 
      "value": "1"
    }
  ]
}

• ERC721 合约中存储的数据可以理解为是一个一维的 KV 数组

• 一个常见的 ERC721 标准合约一般需要实现以下的标准接口

pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all NFTs of the owner.
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    function ownerOf(uint256 _tokenId) external view returns (address);

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT. When transfer is complete, this function
    ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
    ///  `onERC721Received` on `_to` and throws if the return value is not
    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @param data Additional data with no specified format, sent in call to `_to`
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of `msg.sender`'s assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if `_operator` is an approved operator for `_owner`, false otherwise
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

interface ERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

• 实际的 ERC721 NFT 合约，在保证实现了标准的接口前提下，其他功能以及 NFT 的行为可以完全自定义，这就决定了 NFT 可以有非常多的自定义特性、功能或行为。NFT 不仅仅是收藏品，可以有很多的应用空间。

ERC1155

• Multi Token Standard，A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens).

• 详细说明参看 EIP 说明文档 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md

• 一个标准的 ERC1155 Token 通常包含

￮名字，name

￮缩写符号，symbol

￮ Token ID，可能是唯一，也可能非唯一

￮ Fungible Token，包含名字、发行量、拥有数量等信息、也可能包含媒体文件链接

￮ Non-Fungible Token，包含名字、描述、属性、发行量、编号、媒体文件链接

• ERC1155 是组合型 Token 标准，一个ERC1155 Token 可以同时包含 Fungible Token 、 Non-Fungible Token、Semi-Fungible Tokens

• 一个ERC1155 合约可以同时实现多组 Non-Fungible Token

• 最早由新加坡游戏及区块链公司 Enjin 提出，后成为 Ethereum 标准 ERC

• 理论上 ERC1155 合约可以同时涵盖 ERC20 和 ERC721 的功能，但与独立的标准实现相比，灵活度有所降低，其中的 FT 的功能不完全等同于 ERC20 的代币，如不能带有小数的定义

• 对于 ERC1155 合约中的 Fungible Token 和 Semi-Fungible Tokens，可以实现批量铸造，可大量节约 Gas，但对于具备唯一性的 Non-Fungible Token，铸造的 Gas 成本取决于代码实现及写入的链上数据，与 ERC721 NFT 铸造成本基本一致。

• ERC1155 NFT 中的不同 Token，可以单独转账，单独交易

• 特别适合于游戏道具的应用场景

• 对于同时包含多个 FT 及 NFT 的ERC1155 合约，其中的 tokenID 计算逻辑需要经过重新设计，这方面没有统一的标准，EIP 网站只是提供了实现建议，这导致可能存在不同的合约实现方式，一些交易平台暂时不能很好的支持。

• 功能灵活但实现较为复杂

• ERC1155 的 Json 描述文件的形式与 ERC721 基本相同

• ERC1155 合约中的数据可以理解为是一个二维的 ID-KV 数组

• 一个标准的 ERC1155 合约需要实现的方法

pragma solidity ^0.5.9;

/**
    @title ERC-1155 Multi Token Standard
    @dev See https://eips.ethereum.org/EIPS/eip-1155
    Note: The ERC-165 identifier for this interface is 0xd9b67a26.
 */
interface ERC1155 /* is ERC165 */ {
    /**
        @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).
        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
        The `_from` argument MUST be the address of the holder whose balance is decreased.
        The `_to` argument MUST be the address of the recipient whose balance is increased.
        The `_id` argument MUST be the token type being transferred.
        The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.
        When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).
        When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address).        
    */
    event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);

    /**
        @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).      
        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
        The `_from` argument MUST be the address of the holder whose balance is decreased.
        The `_to` argument MUST be the address of the recipient whose balance is increased.
        The `_ids` argument MUST be the list of tokens being transferred.
        The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.
        When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).
        When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address).                
    */
    event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);

    /**
        @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled).        
    */
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /**
        @dev MUST emit when the URI is updated for a token ID.
        URIs are defined in RFC 3986.
        The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema".
    */
    event URI(string _value, uint256 indexed _id);

    /**
        @notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified (with safety call).
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard).
        MUST revert if `_to` is the zero address.
        MUST revert if balance of holder for token `_id` is lower than the `_value` sent.
        MUST revert on any other error.
        MUST emit the `TransferSingle` event to reflect the balance change (see "Safe Transfer Rules" section of the standard).
        After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard).        
        @param _from    Source address
        @param _to      Target address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @param _data    Additional data with no specified format, MUST be sent unaltered in call to `onERC1155Received` on `_to`
    */
    function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;

    /**
        @notice Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call).
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard).
        MUST revert if `_to` is the zero address.
        MUST revert if length of `_ids` is not the same as length of `_values`.
        MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient.
        MUST revert on any other error.        
        MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "Safe Transfer Rules" section of the standard).
        Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc).
        After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard).                      
        @param _from    Source address
        @param _to      Target address
        @param _ids     IDs of each token type (order and length must match _values array)
        @param _values  Transfer amounts per token type (order and length must match _ids array)
        @param _data    Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_to`
    */
    function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;

    /**
        @notice Get the balance of an account's tokens.
        @param _owner  The address of the token holder
        @param _id     ID of the token
        @return        The _owner's balance of the token type requested
     */
    function balanceOf(address _owner, uint256 _id) external view returns (uint256);

    /**
        @notice Get the balance of multiple account/token pairs
        @param _owners The addresses of the token holders
        @param _ids    ID of the tokens
        @return        The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair)
     */
    function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);

    /**
        @notice Enable or disable approval for a third party ("operator") to manage all of the caller's tokens.
        @dev MUST emit the ApprovalForAll event on success.
        @param _operator  Address to add to the set of authorized operators
        @param _approved  True if the operator is approved, false to revoke approval
    */
    function setApprovalForAll(address _operator, bool _approved) external;

    /**
        @notice Queries the approval status of an operator for a given owner.
        @param _owner     The owner of the tokens
        @param _operator  Address of authorized operator
        @return           True if the operator is approved, false if not
    */
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

• 一个简易的 ERC1155 的合约例子

// contracts/GameItems.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract GameItems is ERC1155 {
    uint256 public constant GOLD = 0;
    uint256 public constant SILVER = 1;
    uint256 public constant THORS_HAMMER = 2;
    uint256 public constant SWORD = 3;
    uint256 public constant SHIELD = 4;

    constructor() public ERC1155("https://game.example/api/item/{id}.json") {
        _mint(msg.sender, GOLD, 10**18, "");
        _mint(msg.sender, SILVER, 10**27, "");
        _mint(msg.sender, THORS_HAMMER, 1, "");
        _mint(msg.sender, SWORD, 10**9, "");
        _mint(msg.sender, SHIELD, 10**9, "");
    }
}

• 关于例子的说明

￮这是一个游戏道具常规使用场景

￮代码继承了 ERC1155 合约，其他的标准函数在继承的 ERC1155 中定义

￮其中的道具从 GOLD 开始，定义了从 0 开始的 tokenID，也可以写成一个枚举类型定义

￮构造函数初始化铸造了各类 Token，其中的 THORS_HAMMER 是唯一的，相当于一个 NFT，其他类型相当于是 Semi-FT

￮可以在代码中增加铸造其他类型 Token 的功能，可以是增加新的类型，也可以是增加某一个已有类型的数量

￮构造函数传入了描述文件的链接，{id} 是一个规范写法，要求读取的客户端能够自动将 {id} 替换成 tokenID

￮如果每一个 ID 对应的铸造数量都是1 ，每一个都是 NFT

￮如果要更灵活一些，需要定义复杂的 ID，并且要在合约中编写 ID 的生成和读取计算

￮这是最基本的例子，其他功能都需要再定义，比较丰富的例子可以参考 Opensea 的一个例子实现，代码库中mock 目录下就是可部署的测试合约 https://github.com/ProjectOpenSea/multi-token-standard

两种合约各有优缺点，总体来说 ERC1155 可以涵盖了 ERC721 的功能，并且有更灵活的功能和更高的扩展性，但合约的实现复杂度会高出不少，并且目前 NFT 交易平台和钱包 APP 对 ERC1155 NFT 的支持还不够友好。选择哪一种标准作为 NFT 项目的开发标准，还是要根据实际应用场景来定。

MrBWG

NFT 标准 ERC1155 和 ERC721 比较说明

MrBWG