Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
weiqiushi opened this issue Sep 20, 2024 · 6 comments
Open

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

weiqiushi opened this issue Sep 20, 2024 · 6 comments
Assignees

Comments

@weiqiushi
Copy link
Member

参照最新的公共数据产品的设计,每个公共数据都会有一个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

@weiqiushi weiqiushi self-assigned this Sep 20, 2024
@waterflier
Copy link
Member

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

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

@weiqiushi
Copy link
Member Author

看了一下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
Copy link
Member

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

@weiqiushi
Copy link
Member Author

合约代码已完成,简介如下:

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

@waterflier
Copy link
Member

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

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

@weiqiushi
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants