⚠️ 该 EIP 不建议普遍使用或实施,因为它可能会发生变化。

EIP-5521: Referable NFT Source

An EIP-721 extension to construct reference relationships among NFTs

作者 Saber Yu, Qin Wang, Shange Fu, Shiping Chen, Sherry Xu, Jiangshan Yu
讨论-To https://ethereum-magicians.org/t/eip-x-erc-721-referable-nft/10310
状态 Draft
类型 Standards Track
分类 ERC
创建日期 2022-08-10
依赖 165, 721
英文版 https://eips.ethereum.org/EIPS/eip-5521

摘要

This standard is an extension of EIP-721. It proposes two referrable indicators, referring and referred, and a time-based indicator createdTimestamp. The relationship between each NFT forms a Directed acyclic graph (DAG). The standard allows users to query, track and analyze their relationships.

动机

Many scenarios require inheritance, reference, and extension of NFTs. For instance, an artist may develop his NFT work based on a previous NFT, or a DJ may remix his record by referring to two pop songs, etc. Proposing a referable solution for existing NFTs and enabling efficient queries on cross-references make much sense.

By adding the referring indicator, users can mint new NFTs (e.g., C, D, E) by referring to existing NFTs (e.g., A, B), while referred enables the referred NFTs (A, B) to be aware that who has quoted it (e.g., A ← D; C ← E; B ← E, and A ← E). The createdTimestamp is an indicator used to show the creation time of NFTs (A, B, C, D, E).

规范

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Relationship: a structure that contains referring, referred, createdTimestamp, and other customized attributes such as mapping (uint256 => address) privityOfAgreement recording the ownerships of referred NFTs at the time the rNFTs were being created. referring: an out-degree indicator, used to show the users this NFT refers to; referred: an in-degree indicator, used to show the users who have refereed this NFT; createdTimestamp: a time-based indicator, used to compare the timestamp of mint.

safeMint: mint a new rNFT; setNode: set the referring list of an rNFT and update the referred list of each one in the referring list; setNodeReferring: set the referring list of an rNFT; setNodeReferred: set the referred list of the given rNFTs; referringOf: Get the referring list of an rNFT; referredOf: Get the referred list of an rNFT.

基本原理

This standard is intended to establish the referable DAG for queries on cross-relationship and accordingly provide the simplest functions. It provides advantages as follows.

Clear ownership inheritance: This standard extends the static NFT into a virtually extensible NFT network. Artists do not have to create work isolated from others. The ownership inheritance avoids reinventing the same wheel.

Incentive Compatibility: This standard clarifies the referable relationship across different NFTs, helping to integrate multiple up-layer incentive models for both original NFT owners and new creators.

Easy Integration: This standard makes it easier for the existing token standards or third-party protocols. For instance, the rNFT can be collaborating with the Top-down composible NFT (cf. EIP-998 to build a finer-grained reference relationship, where the Relationship structure and the interface IERC_rNFT can be seamlessly stored and updated when invoking the mint function). Another example is that the rNFT can be applied to rentable scenarios (cf. EIP-5006 to build a hierarchical rental market, where multiple users can rent the same NFT during the same time or one user can rent multiple NFTs during the same duration).

向后兼容性

This standard can be fully EIP-721 compatible by adding an extension function set.

测试用例

Truffle and Openzeppelin are required to run the following in a test network.

truffle develop
rNFT = await ERC_rNFT.new("ERC_rNFT","ERC_rNFT")
rNFT.safeMint(1,[])
rNFT.referredOf(1)
rNFT.referringOf(1)

rNFT.safeMint(2,[1])
rNFT.referredOf(2)
rNFT.referringOf(2)

rNFT.safeMint(3,[1,2])
rNFT.referredOf(2)
rNFT.referredOf(3)
rNFT.referringOf(3)

Reference Implementation

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.4;

interface IERC_rNFT {

    // Logged when a node in the rNFT gets referred and changed
    /// @notice Emitted when the `node` (i.e., an rNFT) is changed
    event UpdateNode(uint256 indexed tokenId, address indexed owner, uint256[] _referringList, uint256[] _referredList);

    /// @notice Set the referred and referring relationship of an rNFT
    /// Throws if `tokenId` is not valid rNFT
    /// @param _tokenIds The list of the rNFTs that `tokenId` refers to
    function setNode(uint256 tokenId, uint256[] memory _tokenIds) external;

    /// @notice Get the list of the rNFTs that `tokenId` refers to
    /// Throws if `tokenId` is not valid rNFT
    /// @param tokenId The rNFT of the referring list
    function referringOf(uint256 tokenId) external view returns(uint256[] memory);

    /// @notice Get the list of the rNFT that refers to `tokenId`
    /// Throws if `tokenId` is not valid rNFT
    /// @param tokenId The rNFT of the referred list
    function referredOf(uint256 tokenId) external view returns(uint256[] memory);
}
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "./IERC_rNFT.sol";

contract ERC_rNFT is ERC721, IERC_rNFT {

    struct Relationship {
        uint256[] referring;   // referring list
        uint256[] referred; // referred list
        uint256 createdTimestamp; // unix timestamp when the rNFT is being created

        // Customized attributes
        // The distribution of profits complies to the aggreement when the NFT was being created regardless of the change of ownership unless specified in the agreement
        // <token ID => token owner address>
        // mapping (uint256 => address) privityOfAgreement
    }

    mapping (uint256 => Relationship) internal _relationship;
    address contractOwner = address(0);

    constructor(string memory name_, string memory symbol_) ERC721(name_, symbol_) {
        contractOwner = msg.sender;
    }

    function safeMint(uint256 tokenId, uint256[] memory _tokenIds) public {
        _safeMint(msg.sender, tokenId);
        setNode(tokenId, _tokenIds);
    }

    /// @notice set the referring list of an rNFT
    /// Throws if `tokenId` is not a valid rNFT
    /// @param _tokenIds array of rNFTs
    function setNodeReferring(uint256 tokenId, uint256[] memory _tokenIds) private {
        require(_isApprovedOrOwner(msg.sender, tokenId), "ERC_rNFT: transfer caller is not owner nor approved");
        if (contractOwner != msg.sender && _tokenIds.length == 0) { revert("ERC_rNFT: the referring list cannot be empty"); }

        Relationship storage relationship = _relationship[tokenId];
        relationship.referring = _tokenIds;
        relationship.createdTimestamp = block.timestamp;
        emit UpdateNode(tokenId, msg.sender, relationship.referring, relationship.referred);
    }

    /// @notice set the referred list of an rNFT
    /// Throws if `tokenId` is not a valid rNFT
    /// @param _tokenIds array of rNFTs
    function setNodeReferred(uint256 tokenId, uint256[] memory _tokenIds) private {
        for (uint i = 0; i < _tokenIds.length; i++) {
            Relationship storage relationship = _relationship[_tokenIds[i]];

            if (relationship.createdTimestamp >= block.timestamp) { revert("ERC_rNFT: the referred rNFT needs to be a predecessor"); } // Make sure the reference complies with the timing sequence

            relationship.referred.push(tokenId);
            emit UpdateNode(_tokenIds[i], ownerOf(_tokenIds[i]), relationship.referring, relationship.referred);
        }
    }

    /// @notice set the referred list of an rNFT and update the referring list of each one in the referred list
    /// Throws if `tokenId` is not a valid rNFT
    /// @param _tokenIds array of rNFTs
    function setNode(uint256 tokenId, uint256[] memory _tokenIds) public virtual override {
        setNodeReferring(tokenId, _tokenIds);
        setNodeReferred(tokenId, _tokenIds);
    }

    /// @notice Get the referring list of an rNFT
    /// @param tokenId The considered rNFT
    /// @return The referring list of an rNFT
    function referringOf(uint256 tokenId) external view virtual override returns(uint256[] memory) {
        require(_exists(tokenId), "ERC_rNFT: token ID not existed");
        return _relationship[tokenId].referring;
    }

    /// @notice Get the referred list of an rNFT
    /// @param tokenId The considered rNFT
    /// @return The referred list of an rNFT
    function referredOf(uint256 tokenId) external view virtual override returns(uint256[] memory) {
        require(_exists(tokenId), "ERC_rNFT: token ID not existed");
        return _relationship[tokenId].referred;
    }

    /// @dev See {IERC165-supportsInterface}.
    function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
        return interfaceId == type(IERC_rNFT).interfaceId || super.supportsInterface(interfaceId);
    }
}

Security Considerations

The createdTimestamp only covers the block-level timestamp (based on block headers), which does not support fine-grained comparisons such as transaction-level.

The change of ownership has nothing to do with the reference relationship. Normally, the distribution of profits complies to the aggreement when the NFT was being created regardless of the change of ownership unless specified in the agreement.

In the context of collaborating with EIP-998, referring a token will not refer its descendants by default. In the case that only a specific child token gets referred, it means the privity of contract will involve nobody other than the owner of this specific child token. Alternatively, a chain-of-reference all the way from the root token to a specific very bottom child token (from root to leaf) can be constructured and recorded in the referring to explicitly define the distribution of profits.

版权声明

Copyright and related rights waived via CC0.

参考文献

Please cite this document as:

Saber Yu, Qin Wang, Shange Fu, Shiping Chen, Sherry Xu, Jiangshan Yu, "EIP-5521: Referable NFT [DRAFT]," Ethereum Improvement Proposals, no. 5521, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5521.