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

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

Мітка часу: 20 лютого 2023 7:21
Аналіз безпеки смарт-контракту ERC 1155 NFT PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

Час читання: 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. Здогадайтеся, де нам потрібен такий тип системи з кількома активами, деякі взаємозамінні, деякі незамінні. Відповідь: ігри web3. ERC 1155 надає розробникам ігор Web3 масштабованість і плавну розробку для мережевих транзакцій.

1.1 Ідентифікатори маркерів у ERC 1155

Ви повинні знати, як можна перевірити баланс у різних жетонах ERC 20, ви можете просто зателефонувати balanceOf(адреса _власник) і ви можете дізнатися, скільки токенів містить ця адреса. Але ERC 1155 стосується різних токенів, тому нам потрібно надати різні ідентифікатори для різних токенів. Майже кожна функція, пов’язана з токенами, містить принаймні два параметри: tokenId (актив, про який ви хочете запитати) та адресу, яку ви хочете знати.

Наприклад, припустимо, що в контракті є 3 жетони: золото, срібло та король. Щоб дізнатися, скільки золота містить певна адреса в цьому протоколі, ви можете викликати функцію balanceOf(адреса _власник, uint256 _id) у смарт-контракті. Припустімо, що tokenId для золота вказано рівним 1. Тоді ви можете викликати balnceOf(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(оператор, від, ідентифікатори, значення, дані)

Обидві функції мають майже однакову функціональність, єдина різниця полягає в тому, що остання полягає в тому, що коли ми маємо справу з більш ніж однією транзакцією одночасно, таким чином у пакеті імен існує невелика різниця між параметрами та значеннями, що повертаються. Але тут ми будемо говорити лише про onERC1155Recieved. 

Цю функцію ЗАБОРОНЯЄТЬСЯ викликати за межами процесу монетного двору чи перенесення. Щоб прийняти передачу, вона має повернути bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)), якщо передачу дозволено.

Дивлячись на параметри: -

  1. operator:- Адреса, яка ініціювала передачу (тобто msg.sender) 
  2. from:- Адреса, яка раніше володіла маркером
  3. id:- Ідентифікатор маркера, який передається 
  4. value:- кількість токенів, що передаються 
  5. дані: додаткові дані без указаного формату 

2.2 Немає функції approve()?

Якщо ви коли-небудь працювали з ERC 20 або ERC 721, то натрапили б на функцію approve(), яка дозволяє певній адресі брати схвалені токени з балансу власника. Наприклад, якщо 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 думки

Часова мітка:

Більше від Квілхаш