Понимание стандартов токенов в Ethereum (ERC1155)
5 марта 2023 г.ТРЕБОВАНИЯ
<цитата>Чтобы лучше понять этот пост, я рекомендую вам сначала изучить ERC20 и стандарты ERC721.
Как я уже говорил в предыдущем сообщении, мы могли отправлять только один токен за раз. в контракте ERC721, что приводит к высокой плате за газ, и отправка нескольких токенов займет много времени. Помимо этого, игровому сообществу действительно нужен другой стандарт токенов, который может обрабатывать несколько стандартов токенов в рамках одного контракта. Чтобы решить эту проблему, ERC1155 был представлен в 2018 году компанией Enjin.
ERC1155 может содержать разные типы токенов с разными конфигурациями. Раньше в ERC721 у нас был один контракт для одной коллекции и с постоянными настройками для этой одной коллекции. Теперь ERC1155 делает возможным один контракт для нескольких коллекций с разными конфигурациями. Это круто, правда? Раньше нам требовалось два контракта для взаимозаменяемых и невзаимозаменяемых токенов и разные контракты для разных типов невзаимозаменяемых токенов. Давайте посмотрим, как работает ERC1155.
Что подразумевается под стандартом Multi-Token?
Основная идея этого стандарта проста и направлена на создание интерфейса смарт-контракта, который может представлять и контролировать любое количество взаимозаменяемых и невзаимозаменяемых типов токенов. Таким образом предполагается, что он может выполнять те же функции, что и ERC20. и токен ERC721, и даже оба одновременно. И самое главное, улучшить функциональность обоих стандартов, сделать их более эффективными и исправить очевидные ошибки реализации стандартов ERC20 и ERC721.
Две очень важные строки, написанные на сайте Ethereum-
Смарт-контракты, реализующие стандарт ERC1155, ДОЛЖНЫ реализовывать все функции интерфейса ERC1155 .
Смарт-контракты, реализующие стандарт ERC1155, ДОЛЖНЫ реализовывать функцию ERC165 supportsInterface и ДОЛЖНЫ возвращать постоянное значение true если 0xd9b67a26 передается через interfaceID аргумент.
ФУНКЦИИ И ВОЗМОЖНОСТИ ERC1155:
- Пакетный перевод: перенос нескольких объектов за один вызов.
- Пакетный баланс. Получите баланс нескольких активов за один вызов.
- Пакетное утверждение: утверждение всех токенов по адресу.
- Крючки: крючок для получения токенов.
- Поддержка NFT: если запас только 1, рассматривайте его как NFT.
- Правила безопасной передачи: набор правил безопасной передачи.
Давайте посмотрим на интерфейс.
pragma solidity ^0.5.9;
interface ERC1155 /* is ERC165 */ {
event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);
event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
event URI(string _value, uint256 indexed _id);
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
function balanceOf(address _owner, uint256 _id) external view returns (uint256);
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
function setApprovalForAll(address _operator, bool _approved) external;
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}
Я объясню это для вас.
Сначала события.
- TransferSingle. То же событие, что и в предыдущих стандартах. Но почему передача одиночная? Что ж, мы знаем, что это стандарт для нескольких токенов с функцией пакетной передачи, что означает, что мы можем отправить один токен или несколько токенов за одну транзакцию. Таким образом, это событие должно генерироваться только при передаче одного токена.
event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);
2. TransferBatch: как следует из названия, это должно происходить каждый раз, когда происходит пакетная передача. Пакетные передачи выполняются путем вызова функции safeBatchTransferFrom.
event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);
3. ApprovalForAll: это событие ДОЛЖНО генерироваться всякий раз, когда одобрение для адреса оператора включено или отключено. Заметьте, здесь написано: «одобряйте для всех». Почему так? Вам лучше догадаться. Я расскажу вам, когда мы будем говорить о функции setApprovalForAll**.**
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
4. URI
- ДОЛЖЕН генерировать каждый раз, когда происходит обновление URI для любого идентификатора токена.
URI события (string _value, uint256 indexed _id);
- URI ДОЛЖЕН указывать на файл JSON, который соответствует «схеме JSON URI метаданных ERC1155».
Теперь взглянем на функции интерфейса ERC1155
- safeTransferFrom: То же имя, та же функциональность, что и у ERC721, но обратите внимание, здесь у нас есть дополнительный параметр суммы. Что это такое? Это относится к количеству токенов, которые мы хотим отправить с определенным идентификатором токена, потому что у нас есть несколько токенов с одним идентификатором токена. Я расскажу вам больше об этом, когда буду говорить о функции balanceOf.
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
<сильный>2. safeBatchTransferFrom: эта функция работает так же, как и функция safeTransferFrom, основное отличие состоит в том, что она принимает массив идентификаторов токенов, а также массив значений, что означает, что несколько токенов могут быть отправлены всего за одну транзакцию. Это одна из проблем, которую ERC1155 решает для ERC721, поскольку ERC721 обеспечивает передачу одного токена за одну транзакцию. Одна вещь, о которой следует помнить при реализации этой функции, — это записывать значения относительно tokenIds. И длина обоих массивов должна быть одинаковой.
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
<сильный>3. balanceOf: эта функция просто возвращает количество токенов определенного идентификатора токена, который имеет адрес. Запись баланса адреса немного отличается от контрактов ERC721. Мы определяем вложенное сопоставление следующим образом: mapping(uint => mapping(address => uint))private balance; владелец этого токена. И, наконец, он присваивает отображению uint, который является балансом. Вот почему функция balanceOf принимает два параметра: адрес и идентификатор токена, чтобы она могла возвращать значение
баланс[_id][_owner].
function balanceOf(address _owner, uint256 _id) external view returns (uint256);
<сильный>4. balanceOfBatch: Как следует из названия, эта функция должна выдавать массив балансов данной учетной записи. Ничего не отличается от функции balanceOf, вместо этого она берет массив и перебирает его, вызывая функцию balanceOf. Затем он сохраняет данные в массиве балансов и возвращает этот массив в конце
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
<сильный>5. setApprovalForAll: Зная ERC20 и ERC721, вы уже знаете, для чего предназначена эта функция. Да, правильно, чтобы утвердить другой кошелек/контракт для обработки ваших токенов. На этот раз есть небольшая разница. Если вы одобряете кого-то, то этот кошелек/контракт утверждается для всех токенов. Помните, в ERC721 у нас было две функции утверждения: одна для одного NFT, а вторая для всех NFT. Но ERC1155 исключает одобрение одного токена и поддерживает одобрение каждого токена, которым владеет кошелек. Чтобы одобрить кого-либо, мы всегда определяем вложенное сопоставление, как и сопоставление баланса.mapping(address => mapping(address => bool)) private Approvals; И присваиваем значения этому сопоставлению через функция setApprovalForAll.
function setApprovalForAll(address _operator, bool _approved) external;
<сильный>6. isApprovedForAllКак видите, это функция просмотра. Он просто проверяет одобрение адреса. Мы передаем адрес владельца и адрес оператора, и эта функция возвращает логическое значение, истинное, если одобрено, и ложное, если не утверждено
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
Это все, что касается интерфейса для ERC1155. Он может быть очень похож на предыдущие, но это не так. В этом стандарте гораздо больше, поскольку он обрабатывает несколько токенов внутри одного контракта. Он должен быть надежным и безопасным для широкой адаптации.
Подобно ERC721, ERC1155 также имеет контракты получателя. ПОЧЕМУ?? Логика та же, контракт получателя должен иметь функциональные возможности для получения токенов из него, иначе токены будут заблокированы навсегда. Давайте посмотрим на интерфейс ERC1155TokenReceiver.
onERC1155Received Обрабатывает получение токена ERC1155 одного типа. Смарт-контракт, совместимый с ERC1155, ДОЛЖЕН вызывать эту функцию в контракте получателя токена в конце safeTransferFrom после обновления баланса. Эта функция ДОЛЖНА возвращать bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))(т.е. 0xf23a6e61), показывая, что она знает о входящем маркере ERC1155 и имеет функциональные получить его.
Эта функция ДОЛЖНА возвращаться, если она отклоняет передачу. Возврат любого другого значения, кроме предписанного значения, сгенерированного keccak256, ДОЛЖЕН привести к отмене транзакции вызывающей стороной.
Посмотрите, какие параметры принимает эта функция1.
_operator Адрес, инициировавший перевод (например, msg.sender)2.
_from Адрес, которому ранее принадлежал токен3.
_id Идентификатор передаваемого токена4.
_value Количество передаваемых токенов5.
_data Дополнительные данные без указания формата
function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);
onERC1155BatchReceived: это почти то же самое, что и onERC1155Received. Но это для пакетных переводов означает, что несколько типов токенов отправляются с разными значениями каждый. В этой функции вместо одного tokenid у нас будет массив id, и то же самое касается values.
function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4);
Эти функции вызываются из контракта токена в контракте получателя. Если получателем является кошелек, то чек не должен передаваться на этот адрес.
Теперь что с реализацией? Мы все определенно согласны с тем, что openzeppelin имеет лучшую реализацию для каждого типа смарт-контрактов. Но новичку эти контракты не понять, поэтому я попытался реализовать контракт самостоятельно в максимально простой форме.ЗДЕСЬ — это ссылка на репозиторий GitHub. Вы можете перейти к контракту Joker.sol, и вы все поймете.
Что еще?
ERC1155 чем-то очень похож на ERC721, поэтому я постоянно говорил о ERC721 на протяжении всей статьи. Потому что, когда вы изучаете несколько тем, находя сходства и различия между ними, концепция становится очень простой для понимания. Теперь в этой заметке, почему бы нам не поговорить об Uri метаданных для ERC1155? Интерфейс для метаданных ERC1155 .
pragma solidity ^0.5.9;
/**
Note: The ERC165 identifier for this interface is 0x0e89341c.
*/
interface ERC1155Metadata_URI {
/**
@notice A distinct Uniform Resource Identifier (URI) for a given token.
@dev URIs are defined in RFC 3986.
The URI MUST point to a JSON file that conforms to the "ERC1155 Metadata URI JSON Schema".
@return URI string
*/
function uri(uint256 _id) external view returns (string memory);
}
Вы помните, что у нас была функция tokenURI в ERC721, которую нужно было реализовать так, чтобы ее можно было вызывать для запроса URI токена? Та же функциональность в ERC1155 была названа uri. Теперь любой клиент, взаимодействующий с вашим контрактом ERC1155, будет ожидать, что функция с именем uri получит URI токена.
Теперь поговорим о схеме JSON для ERC1155. Этот стандарт имеет немного другую схему, чем ERC721.
"title": "Token Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this token represents"
},
"decimals": {
"type": "integer",
"description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation."
},
"description": {
"type": "string",
"description": "Describes the asset to which this token represents"
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
},
"properties": {
"type": "object",
"description": "Arbitrary properties. Values may be strings, numbers, object or arrays."
}
}
}
Означает ли это, что наша схема ERC721 JSON не будет работать с ERC1155? Что ж, я попытался использовать ту же схему JSON, что и для ERC721, внутри ERC1155, и это сработало. Потому что они оба очень похожи. ERC1155 имеет дополнительное свойство десятичных знаков, которое является концепцией ERC20. На данный момент ERC1155 не очень популярен среди проектов NFT, и те, кто его использует, реализуют его простым способом. Этот стандарт в основном используется игровыми платформами.
Это оно? Нет, не совсем, ERC1155 нужно обсудить еще много вещей, но я думаю, что они выходят за рамки этого поста. Вы узнали достаточно, чтобы разработать контракт ERC1155 и создать свои NFT.
Есть более продвинутые свойства ERC1155, которые я здесь не привожу. Вы можете прочитать о них и поиграть. Будет весело.
- ERC1155 содержит ряд правил, связанных с функциями, с которыми вы можете ознакомиться на официальном веб-сайте.< /li>
- В нем также описаны меры, которые необходимо принять в различных сценариях. ссылка
- Схема метаданных дополнительно расширена за счет использования свойства «локализация». ссылка
В настоящее время существует не так много проектов, реализующих ERC1155 с использованием всех правил и свойств. Те, что существуют, в основном игровые и NFT-проекты. Это означает, что нам еще предстоит изучить ERC1155 и его возможности.
Хорошо, теперь я думаю, что вы знаете о ERC20, ERC1155 и ERC1155, а также обо всем процессе NFT.
Вот и все для этой серии статей. Я вернусь с более подробными сообщениями о разработке и безопасности смарт-контрактов, а также о EVM. Не забудьте связаться со мной в Twitter. И поделитесь своим мнением о моих статьях и любых обзорах, чтобы я мог осознавать свои сильные и слабые стороны и приносить больше пользы сообществу.
:::информация Также опубликовано здесь.
:::
Оригинал