Анализ безопасности смарт-контракта ERC 1155 NFT

Анализ безопасности смарт-контракта ERC 1155 NFT

Анализ безопасности смарт-контракта ERC 1155 NFT PlatoBlockchain Data Intelligence. Вертикальный поиск. Ай.

Время Читать: 5 минут

Вы наверняка слышали о токенах криптовалюты. Различные токены играют жизненно важную роль в экосистеме web3. Эти токены представляют собственность, богатство, доверие и авторитет в криптовалюте. Самое интересное, что вы также можете создать свой криптовалютный токен. 

Эти токены представляют собой смарт-контракты, включающие различные функции для различных действий, таких как передача, проверка баланса и т. д. Вы можете создать свой токен, создав для него смарт-контракт. Тем не менее, чтобы обеспечить безопасность вашего токена и придать ему чувство доверия, ERC 20 является стандарт смарт-контракта рекомендуется следовать ему для создания взаимозаменяемых токенов, а ERC 721 — это стандарт смарт-контракта, который используется для создания невзаимозаменяемых токенов (NFT).

ERC 20 и ERC 721 являются широко распространенными протоколами смарт-контрактов для создания токенов. Они обеспечивают безопасную и надежную среду для токенов. И эти протоколы продолжают улучшаться и улучшаться. Шаг в этом направлении приводит к созданию нового протокола смарт-контрактов ERC 1155 для токенов. Давайте посмотрим, что это такое.

1. Что такое ERC 1155?

Все ERC, такие как 20 и 721, являются просто стандартами для создания смарт-контрактов, которые подходят для различных обстоятельств для NFT. У нас есть ERC 721, а взаимозаменяемые токены, такие как USDT и DAI, соответствуют стандартам ERC 20. ERC 1155 — это один стандарт, включающий функции и свойства ERC 20 и ERC 721.

Предположим, вы хотите создать программу, в которой вы создаете несколько товаров. Например, вы хотите создать жетон с именем золото, еще один токен с именем серебро и один король, и логика говорит, что тот, у кого больше золота и серебра, будет королем. Король может быть только один. Это простой протокол, но для его создания вам нужно будет развернуть 3 контракта только для активов, один для золотого токена, другой для серебра и один для короля, который будет ERC 721. Но что, если вы можете развернуть только один контракт, в котором перечислены все эти разные токены?

Это одна из таких проблем, которую решает ERC 1155. Вам не нужно развертывать контракт для каждого из токенов, которые вы хотите использовать в блокчейне. Это был один из таких примеров контракта ERC 1155. Угадайте, где нам нужна система такого типа с несколькими активами, некоторые взаимозаменяемые, некоторые невзаимозаменяемые. Ответ — веб3 игры. ERC 1155 предоставляет разработчикам игр Web3 масштабируемость и плавную разработку для транзакций в сети.

1.1 Идентификаторы токенов в ERC 1155

Вы должны знать, как можно проверить баланс в разных токенах ERC 20, вы можете просто позвонить BalanceOf (адрес _владелец) функция, и вы можете получить, сколько токенов содержит этот адрес. Но ERC 1155 имеет дело с разными токенами, поэтому нам нужно предоставить разные идентификаторы для разных токенов. Почти каждая функция, связанная с токенами, принимает как минимум два параметра: tokenId (актив, о котором вы хотите узнать) и адрес, о котором вы хотите узнать.

Например, предположим, что в контракте есть 3 жетона: золото, серебро и король. Чтобы узнать, сколько золота имеет конкретный адрес в этом протоколе, вы можете вызвать функцию balanceOf(адрес _владелец, uint256 _id) в смарт-контракте. Предположим, что tokenId для золота указан равным 1. Тогда вы можете вызвать балансОф(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Руководство по аудиту смарт-контракта ERC 1155

ERC 1155 существует уже некоторое время, и некоторые функции недоступны в обычном протоколе ERC 20 или ERC 721, например пакетная передача. Кроме того, ERC 1155 менее распространен на рынке, что делает эту область менее изученной для многих разработчиков. QuillAudits делится важной информацией о протоколах, которые ищут BUIDL на ERC 1155, чтобы они могли помочь создать более безопасную экосистему web3, защитив себя. 

2.1 Интерфейс приемника ERC 1155

Когда наш контракт ERC 1155 передает активы в какой-либо другой контракт, что обычно является требованием протокола игры web3, ВАЖНО иметь интерфейс ERC1155Receiver в контракте получения для успешной транзакции токенов.

Две функции, которые входят в интерфейс приемника ERC 1155:

  • onERC1155Received(оператор, от, идентификатор, значение, данные)
  • onERC1155BatchReceived (оператор, от, идентификаторы, значения, данные)

Обе функции имеют почти схожую функциональность, единственное отличие состоит в том, что последняя возникает, когда мы имеем дело с более чем одной транзакцией за раз, поэтому есть небольшая разница между параметрами и возвращаемыми значениями. Но здесь речь пойдет только о том, что получил ERC1155. 

Эта функция НЕ ДОЛЖНА вызываться вне процесса чеканки или передачи. Чтобы принять передачу, он должен вернуть bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")), если передача разрешена.

Глядя на параметры: -

  1. оператор:- адрес, который инициировал перевод (т.е. msg.sender) 
  2. from:- Адрес, которому ранее принадлежал токен
  3. id: - ID передаваемого токена 
  4. value: - Количество передаваемых токенов 
  5. data:- Дополнительные данные без указанного формата 

2.2 Нет функции одобрить()?

Если вы когда-либо работали с ERC 20 или ERC 721, вы наверняка сталкивались с функцией Appro(), которая разрешает какому-то адресу брать утвержденные токены с баланса владельца. Например, если A хочет одобрить получение B 100 токенов DAI, то A может вызвать функцию утверждения, говоря, что B имеет право на 100 токенов DAI, а позже B может выполнить транзакцию с этой суммой.

Но ERC 1155 не имеет утвердить функция для одного токена. У нас есть setApprovalForAll (оператор адреса, bool утвержден) функция, которая вызывается владельцем и принимает оператор параметра адреса, который является адресом плательщика или того, кому мы хотим одобрить наши токены. Таким образом, мы не можем назвать утвердить функцию или предоставить одобрение для одного токена из нашего списка токенов ERC 1155, но вместо этого доступ ко всем токенам будет одобрен сразу. Команда разработчиков должна знать об этом. Если это проигнорировать, это может привести к огромным потерям и компрометации протокола.

2.3 Некоторые регулярные проверки

В двух предыдущих разделах были рассмотрены две уникальные проверки, связанные с ERC 1155. В этом разделе мы проведем некоторые регулярные проверки, которые не нуждаются в очень глубоком объяснении.

  1. Имейте в виду идентификаторы: - Каждая внешняя функция или интерфейс, который работает с ERC 1155, должен иметь указанный идентификатор токена, чтобы принимать его в качестве входных данных.
  2. Burn/Mint: всякий раз, когда вызываются эти функции, они должны изменять баланс и totalSupply только для указанного идентификатора токена.
  3. Сходство с ERC 20: многие свойства аналогичны стандарту токена ERC 20. В этом вопросе также поможет изучение рекомендаций по безопасности для ERC 20.
  4. Повторный вход: как обсуждалось, ERC 1155 проверяет поддерживаемый интерфейс в логике передачи. Таким образом, могут быть различные сценарии, которые могут привести к уязвимость повторного входа. Рекомендуется оставить модификаторы защиты от повторного входа в соответствующих функциях.

3. Заключение

Экосистема Web3 постоянно развивается в соответствии с обычными стандартами для повышения безопасности и функциональности. ERC 1155 — шаг в этом направлении. Но когда новые стандарты выпускаются, это создает пробел в знаниях, связанных с не очень распространенными стандартами в протоколах, и сопряжено с риском меньшего пространства выборки для мер безопасности. В этот момент на сцену выходит QuillAudits с командой экспертов. Мы занимаемся, анализируем и находим различные способы компрометации протокола и защищаем протокол наших клиентов с невероятными результатами. Посетите наш веб-сайт и защитите свой проект Web3!

17 Просмотры

Отметка времени:

Больше от Квиллхэш