3

我看到的大多数使用 Open Zeppelin 的 ERC721 示例都要求 mint 函数具有访问控制，其中只允许合约的所有者调用该函数。例如，_

function mint(address to) public virtual {
    require(hasRole(MINTER_ROLE, _msgSender()), "ERC721PresetMinterPauserAutoId: must have minter role to mint");

    _mint(to, _tokenIdTracker.current());
    _tokenIdTracker.increment();
}

或以下使用Ownable库。

function mint(address receiver) external onlyOwner returns (uint256) {
    _tokenIds.increment();

    uint256 newTokenId = _tokenIds.current();
    _mint(receiver, newTokenId);

    return newTokenId;
}

这是否意味着每次铸造新代币时都必须部署新合约？这似乎不仅在 gas 费用方面过高，而且 ERC721 合约还具有映射不同所有者和代币的属性：

// Mapping from token ID to owner address
mapping (uint256 => address) private _owners;

// Mapping owner address to token count
mapping (address => uint256) private _balances;

如果铸币仅限于合约所有者，这将毫无意义。

对我来说，部署单个ERC721 合约（及其依赖项）并让用户调用 mint 函数更有意义。ERC721的mint功能的最佳实践是什么？

4

1 回答 1

3

ERC-721标准没有定义铸造新代币的“最佳”或“正确”方式（例如是否应该开放或限制），并且由每个合约开发人员以一种方式实现或省略铸造功能反映了他们的需求。

规范中不包括创建 NFT（“铸造”）和销毁 NFT（“燃烧”）。您的合同可以通过其他方式实施这些。在创建或销毁 NFT 时，请参阅事件文档以了解您的职责。

但是，拥有一个授权铸造新代币的地址白名单（例如MINTER_ROLE或onlyOwner）似乎比允许任何人自由铸造新代币更常见。

尽管理论上可以在每次铸造新代币时部署新合约，但这不是标准方法（我个人还没有看到任何这样做的合约）。在大多数情况下，铸币过程“只是”创建一个新 ID，存储与该 ID 关联的新字符串/URL 值，将这个新令牌与所有者地址（令牌的，而不是合约所有者）相关联，并更新一些元数据，例如作为地址拥有的代币数量（参见下面的示例）。

然后，代币所有者可以转移他们的代币，让任何人控制他们的代币，并根据合约实施做其他事情。

您在问题 (_owners和_balances) 中指出的映射表明它们存储代币所有者（而非合约所有者）地址以及每个地址持有的代币数量。

例子：

  1. 合约所有者铸造代币 ID1到 address 0x123。

    • 的_owners[1]值为0x123（为 0，默认值）

    • _balances[0x123]变为的值1（为 0，默认值）

  2. 合约所有者铸造代币 ID2到 address 0x123。

    • 的值_owners[1]仍然是0x123

    • 的值_owners[2]现在0x123（为 0，默认值）

    • _balances[0x123]成为的价值2（因为他们现在拥有 2 个代币）

于 2021-05-19T23:10:25.867 回答