Почему функция чеканки ERC721 имеет контроль доступа?

Question

Я вижу, что в большинстве примеров ERC721 с использованием Open Zeppelin требуется, чтобы функция 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;
}

Означает ли это, что новый контракт должен развертываться каждый раз, когда чеканится новый токен? Это кажется чрезмерным не только с точки зрения платы за газ, но и в контракте 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) кажется более распространенным явлением, чем позволять кому-либо свободно чеканить новые токены.

---

Несмотря на то, что теоретически возможно развертывать новый контракт каждый раз, когда чеканится новый токен, это не стандартный подход (и я лично не видел ни одного контракта, который бы это делал). В большинстве случаев процесс чеканки «просто» создает новый идентификатор, сохраняет новую строку / значение URL, связанное с идентификатором, связывает этот новый токен с адресом владельца (токена, а не владельца контракта), а также обновляет некоторые метаданные, такие как как количество токенов, принадлежащих адресу (см. пример ниже).

Владелец токена может затем передать свои токены, предоставить кому-либо контроль над своими токенами и делать другие вещи в зависимости от реализации контракта.

Отображения, которые вы указываете в своем вопросе ( _owners а также _balances) предполагают, что они хранят адреса владельцев токенов (не владельцев контрактов), а также количество токенов, хранящихся на каждом адресе.

Пример:

1. Владелец контракта вводит идентификатор токена для адреса.

   • Значение равно (было 0, значение по умолчанию)

   • Стоимость становится 1 (было 0, значение по умолчанию)

2. Владелец контракта вводит идентификатор токена для адреса.

   • Значение _owners[1] все еще

   • Значение _owners[2] сейчас 0x123 (было 0, значение по умолчанию)

   • Значение _balances[0x123] становится 2 (потому что теперь у них есть 2 токена)