为什么ERC721的铸币功能有访问控制？

Question

我看到的大多数使用 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铸币功能的最佳实践是什么？

Answer 1

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

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

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

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

然后，代币所有者可以转移他们的代币，让任何人控制他们的代币，并根据合约的实现执行其他操作。

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

例子：

1. 合约所有者将代币 ID 铸造1到地址0x123。

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

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

2. 合约所有者将代币 ID 铸造2到地址0x123。

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

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

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