前言
因为一些机缘，我最近和几个同行朋友一起提交了一个新的EIP协议标准，EIP-6150，这是一个支持层级结构的NFT协议标准，撰写此文时处在Review状态，改为LastCall状态的PR还在等待通过。
该协议标准有4位作者：KeeganLee、msfew、Kartin和qizhou。KeeganLee就是我，主要负责了接口的定义和实现代码的编写。Kartin是这个EIP的发起人，也是HyperOracle的创始人。msfew则是HyperOracle的研究员，主要帮忙做一些辅助性的工作，包括完善文档、提交PR、跟进讨论区的QA等。qizhou是EthStorage的创始人，之前就提交过其他EIP，熟悉申请EIP的流程，也对以太坊基金会的人比较熟悉，为这个协议提供了很多指导。以下是该EIP-6150的github地址：
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6150.mdHierarchicalNFTs
目前的NFT几乎都是扁平化的，不同NFT之间不存在关联关系。而层级化的NFT，则可以将所有NFT串联起来组成树状结构，就像文件系统一样。
如上图所示，可以想象成每个文件夹都是一个单独的NFT，不同文件夹之间的层级关系也就是NFT之间的层级关系。
层级化的NFT可用于多种不同的应用场景，比如：
组织架构社交关系图谱电商商品类目结构层级评论系统可以说，任何具有层级结构的场景都可以适用这个EIP-6150协议标准。层级结构的NFT在去中心化社交、去中心化电商等领域都将可能产生广泛应用。
接口定义
EIP-6150总共定义了5个接口文件：
IERC6150IERC6150EnumerableIERC6150BurnableIERC6150ParentTransferableIERC6150AccessControlIERC6150
IERC6150?是规定必须实现的接口，最小化定义了一个事件和四个函数，且要求继承IERC165和IERC721接口，接口定义如下：
Minted?事件需在铸造一个新的NFT时发出，记录了新NFT的铸造者、接收者、父节点NFT的ID、新NFTID。当铸造一个根节点NFT时，那parentId则记为0，即0表示一个无效的空节点，因此，有效的节点NFT的tokenId就不可以为0。
parentOf?函数用于查询指定tokenId的NFT的父节点NFT。
childrenOf?函数则查询出指定tokenId的NFT的所有子节点NFTs。
isRoot?和?isLeaf?函数则分别可查询指定tokenId在整个NFT层级树中是不是根节点或叶子节点。
IERC6150Enumerable
IERC6150Enumerable?是可选的扩展接口，主要补充了几个跟层级相关的Enumerable的查询接口，接口定义如下：
继承?IERC721Enumerable?也是可选的，但为了更好地兼容ERC721，最好可以继承。childrenCountOf?函数用于查询指定节点下有多少个子节点，如果参数parentId为0，则表示查询根节点的数量。childOfParentByIndex?函数则是从指定的父节点下的所有子节点数组中找出指定索引位置的子节点的tokenId，比如指定父节点parentId=110，其下有10个子节点，找出索引位置为5的子节点tokenId=1105，则查询结果返回1105。indexInChildrenEnumeration?函数则是查询指定的tokenId在指定父节点下的子节点数组中所在的索引位置，比如指定tokenId=1105，父节点parentId=110，1105在子节点数组中的索引位置为5，则查询结果返回5。如果指定tokenId并不在指定父节点parentId下面，则需要抛出错误。
IERC6150Burnable
IERC6150Burnable?也是可选的扩展接口，定义了销毁节点的操作，接口定义如下：
只定义了两个函数，safeBurn?用于安全销毁单个节点，但要求只有指定节点为叶子节点时才允许销毁。就和Linux的文件系统一样，如果某目录下存在其他文件或文件夹，是不允许直接删除的。若强制删除，则目录下的所有文件和文件夹都会被级联式全部删除。当前协议没有定义级联式删除的函数，若有这个需求，可以自己再额外去添加函数实现。safeBatchBrun?函数则是用于批量销毁多个叶子节点。
IERC6150ParentTransferable
IERC6150ParentTransferable?也是一个可选的扩展接口，支持层级关系的转移，就和文件夹可以从一个目录移动到另一个目录一样，接口定义如下：
接口定义了两个函数和一个事件，支持单节点的转移，也支持多节点的批量转移。每个节点发生层级关系转移时，需要抛出?ParentTransferred?事件，记录下所转移的tokenId、旧的父节点ID和新的父节点ID。transferParent?将指定的tokenId转移到指定的父节点下，若指定的父节点为0，则表示指定节点改为了根节点。batchTransferParent?则可以指定多个tokenId，批量将这些节点都转移到指定的父节点下。
IERC6150AccessControl
最后一个接口?IERC6150AccessControl?也是可选的，提供了几个权限控制的函数，接口定义如下：
总共定义了三个函数，isAdminOf?用于查询指定的account对指定的tokenId是否有管理员权限。在ERC721中，每个NFT都只有唯一的owner并拥有管理权限。但在层级式的结构中，一个NFT是可以有多个管理员的，就和文件系统中可以有多个管理员一样。这个扩展接口就提供了支持多管理员的模式，但对于怎么设置多个管理员，则难以定义通用函数，所以就没做标准化的定义。不过，需要保证，NFT的owner同时也是管理员。
canMintChildren?则用来判定某个account对指定的parentId是否具有铸造子节点的权限。
canBurnTokenByAccount?则用来检查某个account对指定的tokenId是否具有销毁的权限。
参考实现
EIP的github上，我对每个接口都提供了对应的参考实现代码，代码地址如下：
https://github.com/ethereum/EIPs/tree/master/assets/eip-6150/contracts但这里我不打算对每个实现代码都一一讲解，我只讲最核心的?ERC6150.sol?的实现。因为代码相对有点长，就不贴代码出来了，大家可以点击链接进去看代码。我主要讲讲实现的一些逻辑和思路。
存储上，用了三个mapping：_parentOf、_childrenOf、_indexInChildrenArray，分别用来存储指定节点的：父节点、子节点数组、所在子节点数组里的索引位置。有了这三个mapping之后，几个查询函数的实现就非常简单了，我就不细说了。核心是?_safeMintWithParent?和?_safeBurn?函数，分别是铸造NFT和销毁NFT的内部函数。
铸造函数的代码如下：
实现逻辑其实也很简单，有两个校验需要注意下，一是要铸造的新NFT的tokenId需要大于0，正如前面所说的，0为无效节点；二是当parentId不为0时，需保证parentId是存在的，当parentId为0时，则表示铸造的是根节点NFT。?_beforeMintWithParent?和?_afterMintWithParent?是为了增加扩展性而增加的，可由继承此合约的上层合约根据需求再去实现。中间代码就是对几个mapping进行赋值了，然后调用了ERC721的?_safeMint?函数实现底层的铸造，接着就发送Minted事件了。
这个铸造函数是internalvirtual的，上层合约可以重载该函数，且上层的实现合约需要再根据具体需求自己添加开放的铸造函数。
接着看看销毁函数，代码如下：
销毁时，要求tokenId是存在的且需是叶子节点才允许销毁。另外，销毁时，需要从子节点数组中移除，而为了节省gas，同时把子节点数组中的最后一个元素移到了销毁的索引位置。
另外，实现代码中，也封装了批量铸造的内部函数，方便扩展支持批量铸造多个子节点的需求。
其实，整个协议并不复杂，但已经足以覆盖到很多应用场景，后续我会结合一些具体的应用场景，再增加示例代码作为案例，以促进该协议的落地应用。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。