有关带Meta信息的NFTBridge合约的讨论

weiqiushi commented 2 months ago

参照最新的公共数据产品的设计，每个公共数据都会有一个meta信息，该信息包含作者，版权，文件列表等可读信息

由于公共数据合约要求，链上数据必须符合ERC7585规范，即可以通过接口 function getDataOwner(bytes32 dataHash) external view returns (address); 查询到链上owner的地址

因此，我们有链上的桥合约DataBridge，用来保存datahash和owner address之间的关系

再考虑将meta信息也上链，保存在桥合约里。桥合约本身的设计就类似：

contract DataBridge {
    struct NFTData {
        string meta;
        address owner;
    }

    mapping (bytes32 => NFTData) ownerData;

    function setData(bytes32[] calldata dataMixedHash, string[] calldata dataMetas) public {
        // storage owner and meta
    }

    function getDataOwner(bytes32 dataMixedHash) public view returns (address) {
        return ownerData[dataMixedHash].owner;
    }

    function getDataMeta(bytes32 dataMixedHash) public view returns (string memory) {
        return ownerData[dataMixedHash].meta;
    }
}

这里的数据结构和get接口都比较明确，set接口的权限问题是需要进一步讨论的：谁有权限set owner和mets数据？

如果任何人都有权限去set，owner自动变成自己，那么：
- 会不会有抢注datahash的事情发生？当datahash被抢占时，要怎么处理？
- 如果data meta也是分账户保存的，那么ERC7585需要的getDataOwner接口就没办法实现了
如果特定账户才有权限set，与现在线上的实现一致：
- 那就要和后端的上传审核实现打通，上传审核通过后，由服务器以特定身份调用set接口，同时set owner和meta信息

@waterflier

waterflier commented 2 months ago

因为XLayer上并没有太多的NFT项目，所以我的想法是可以做一个新的，符合ERC7585规范的NFT合约。

该合约可以动态的增加新的Token，每次审核通过，我们作为合约的Owner，可以批量的增加一些新的Token
按之前Williams的建议，该合约的NFT Token Id可以直接是MixHash
站在用户的视角，审核通过后自己就得到了一个新的NFT，该NFT是标准的，且我们不可能再回收。
用户选择一些版权选项的时候，NFT的Owner会变成基金会账号。

weiqiushi commented 2 months ago

看了一下openzeppelin的ERC721实现，由于标准ERC721的token id是uint256，因此我们可以直接将我们的bytes32映射到uint256。

基本的实现思路如下：

基于openzeppelin的ERC721的标准实现合约
将bytes32的mixHash直接转换成uint256，转调标准ERC721
给每个接收uint256的ERC721接口再提供一个bytes32的接口，内部转调对应的ERC721接口
修改tokenURI的实现，返回的url拼接mixHash的0x开头16进制字符串，而不是原来的拼接数字实现
增加Writer权限，owner可以设置writer，只有writer可以mint NFT

是否需要增加burn功能？openzeppelin的ERC721实现了burn功能，但没有开放给外部使用

waterflier commented 2 months ago

可以支持burn,比如有版权争议的nft,最后的结果是可以burn掉。不过，这需要nft的owner调用。

weiqiushi commented 2 months ago

合约代码已完成，简介如下：

扩展了openzeppelin的ERC721标准合约，错误和事件都沿用标准的ERC721错误和事件
保留了原接口，并为每个接收uint256 tokenId的接口增加了对应的bytes32 tokenId的接口
增加了writer权限，owner可赋予和取消writer权限。owner默认是writer
writer可以批量mint NFT
NFT的owner和writer可以burn NFT

waterflier commented 1 month ago

我对目前的合约实现有如下疑问

按现在的逻辑，结构上是无法实现tag的move的。比如我有一个tag: /taga/tag/tagb/tagc 此时我想把tag改成根tag是做不到的
对tag的合法字符检查，只过滤了 '/' 这里应该和最严格的路径系统对齐？很多字符都是不可以用的。
setTagMeta的时候，为什么不通过tag_hash来设置？感觉没必要走全路径逻辑？
mapping(bytes32 => mapping(address => Data)) datas; 这个结构有点绕，我理解是 MixHash->UserAddress->TagHashList ?

weiqiushi commented 1 month ago

tag的move是指什么？如果是tag本身的话，为什么需要移动？我新建一个tag就可以了。可能需要移动的只有数据。如果是指数据上的tag修改的话，这里是故意没做这个功能的，有需求的话，可以加一个把数据上的某个tag替换成根tag的逻辑，这个逻辑相当于"删除"数据上的某个tag
isCharValid可以随时加不合法字符。现在只有'/'是因为从合约的角度看，只有'/'是不合法的，其他所有字符都可以。如果产品上有需求了再加上
setTagMeta设计成全路径是类似mkdir -p的逻辑, 在创建"/游戏/角色扮演"这个tag的时候，其实是同时创建了"/游戏"和"/游戏/角色扮演"两个tag，只是前者的meta信息是空的。addDataTag就是用tagHash来设置了
这个理解是正确的，因为每个人都可以给数据附自己的tag list

buckyos / DCRM

有关带Meta信息的NFTBridge合约的讨论 #15