Інструкції щодо аудиту протоколів ставок

Час читання: 6 протокол

У цьому блозі ми окреслили концепцію протоколів ставки ліквідності та вказівки щодо аудиту протоколів ставки. Рекомендації охоплюють низку вразливих місць, таких як механізми зняття коштів, помилки округлення, зовнішні виклики, логіка комісії, цикли, структури, тривалість стекінгу тощо. Ця публікація в блозі стане корисною довідкою для перевірки протоколів стекінгу та може допомогти вам виявити потенційні помилки .

Що таке ставка ліквідності?

Ставка ліквідності дозволяє користувачам робити ставки на свої криптовалютні авуари та отримувати винагороди без шкоди для ліквідності. Замість того, щоб блокувати свої монети на фіксований період, користувачі можуть отримати ліквідний токен, який представляє їхні активи. Цим токеном можна торгувати або використовувати його як будь-яку іншу криптовалюту, дозволяючи користувачам використовувати свої активи як їм заманеться, водночас отримуючи винагороди за ставки.

Наприклад, у вас є 100 ETH, які ви хочете зробити в мережі Ethereum. Замість того, щоб блокувати свій ETH на фіксований період, ви можете скористатися послугою стекінгу ліквідності, як-от Lido, щоб поставити свій ETH і отримати натомість ліквідний токен під назвою stETH. З stETH ви все ще можете торгувати або використовувати свій ETH, заробляючи винагороди за ставки.

Почнемо з аудиту контрактів на стейкинг:

Вивчіть усі наявні специфікації аудиту, перш ніж почати код контракту. Це може бути у формі технічного документу, файлів README або щось інше. Це дасть вам уявлення про те, що міститиме код контракту.

Переглядаючи документ специфікації аудиту для контракту на ставку, зверніть увагу на такі моменти:

• Види зборів та їх обчислення.
• Механізм винагороди за поставлені токени
• Повноваження власника
• Чи буде контракт підтримувати ETH?
• Які токени міститиме контракт?
• Оригінальний контракт, з якого він розгалужений

Перевірте, чи відповідають технічні характеристики коду. Почніть із комісії та токеноміки, а потім перевірте повноваження власника. Перевірте, чи всі винагороди та комісії відповідають документації.

Шукати вразливі місця?

1. Механізм виведення винагороди:

Перевірте, чи правильно реалізовано механізм винагороди токенів, а винагороди розподіляються справедливо й пропорційно між усіма учасниками. Проекти можуть розподіляти винагороди двома способами: автоматично, періодично або за запитом самих користувачів. Функцію вилучення можна реалізувати та налаштувати відповідно до бізнес-логіки протоколу.
Нижче наведено кілька контрольних точок:

• Перевірте, чи може будь-який користувач зняти більше, ніж його винагорода + сума ставки.
• Перевірте переповнення/недоповнення в розрахунку суми
• Перевірте, чи можуть певні параметри мати негативний вплив на винагороду під час розрахунку.
• Якщо у цій функції використовується block.timestamp або block.number. Перевірте, чи можна його якимось чином використати.

2. Логіка оплати:

Якщо внесення та зняття стягується певна комісія, переконайтеся, що жоден користувач не може обійти комісію. Крім того, будьте пильні щодо будь-яких потенційних проблем з переповненням або недоповненням. Лише адміністратор або власник має мати право змінювати налаштування плати. Також переконайтеся, що було встановлено поріг для максимальних комісій, що запобігає встановленню адміністратором надмірно високої суми.

3. Механізм карбування/спалювання токена LP:

Перевірте, чи правильно реалізовано механізми карбування та спалювання. Функція burn повинна скасовувати всі зміни стану, зроблені функцією mint. Крім того, важливо переконатися, що користувачі отримують відповідну кількість токенів під час першої ставки, коли пул порожній.

Логіку функцій карбування та запису можна перевірити математично, щоб виявити будь-яку приховану вразливість. Крім того, загальна пропозиція викарбуваних токенів LP не повинна перевищувати поставлені активи.

4. Помилки округлення:

Навіть незважаючи на те, що деяких незначних помилок округлення зазвичай не уникнути, і вони не викликають занепокоєння, вони можуть значно збільшитися, якщо їх можна помножити. Шукайте крайні випадки, де можна отримати вигоду від помилок округлення, багаторазово розставляючи та знімаючи розставки.

Щоб визначити, чи можуть помилки округлення накопичуватися до значної кількості протягом тривалого періоду часу, ми можемо математично обчислити діапазон можливих помилок округлення.

5. Тривалість ставки:

Переконайтеся, що розрахунки тривалості стекінгу в контракті відповідають вказаній бізнес-логіці. Переконайтеся, що користувачі не можуть обміняти нагороди до закінчення тривалості ставки, минаючи перевірки тривалості. Також перевірте, чи може зловмисник використати тривалість ставки, щоб отримати більше винагород.

6. Зовнішні виклики та обробка маркерів:

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

7. Перевірки маніпулювання цінами:

Маніпулювання цінами за допомогою флеш-позики — один із найпоширеніших зломів проектів DeFi. Можуть виникати ситуації, коли зловмисники можуть використовувати швидкі позики для маніпулювання цінами під час ставки або зняття ставки великої кількості токенів. Уважно перегляньте функції стекінгу та скасування ставок, щоб уникнути граничних сценаріїв, які можуть призвести до атак маніпулювання цінами на основі позики та втрати коштів інших користувачів.

8. Деякі додаткові перевірки:

• Петлі: Якщо логіка контракту включає цикл над масивами, важливо переконатися, що обмеження блокового газу не перевищено. Це може статися, коли розмір масиву дуже великий, тому вам слід дослідити, які функції можуть збільшити розмір масиву та чи може будь-який користувач використати це для виклику DoS-атаки. Подивіться це звітом.
• Структури: Контракти про ставки використовують тип структури для зберігання даних користувача або пулу. Під час оголошення або доступу до структури у функції важливо вказати, чи використовувати «пам’ять» чи «зберігання». Це може допомогти нам заощадити газ. Для отримання додаткової інформації, будь ласка, зверніться до цієї статті.
• Попереду: шукайте будь-які сценарії, коли зловмисники можуть ініціювати будь-яку транзакцію на свою користь.
• Функціональна видимість/перевірка контролю доступу: Будь-яка функція, яка оголошена як зовнішня або публічна, може бути доступна будь-кому. Тому важливо переконатися, що жодна державна функція не може виконувати будь-які конфіденційні дії. Важливо переконатися, що протокол стейкингу реалізував відповідні засоби контролю для запобігання несанкціонованому доступу як до монет, що ставляться, так і до інфраструктури системи.
• Ризики централізації: Важливо не наділяти власника надмірними повноваженнями. Якщо адресу адміністратора зламано, це може завдати значної шкоди протоколу. Переконайтеся, що привілеї власника або адміністратора належні, і переконайтеся, що в протоколі є план для обробки ситуацій, коли витік особистих ключів адміністратора.
• Обробка ETH / WETH: Контракти часто включають певну логіку для обробки ETH. Наприклад, коли msg.value > 0, контракт може конвертувати ETH у WETH, дозволяючи безпосереднє отримання WETH. Коли користувач вказує WETH як валюту, але надсилає ETH із викликом, це може порушити певні інваріанти та призвести до неправильної поведінки.

Наразі ми обговорювали протоколи оцінки ліквідності та вказівки щодо аудиту таких протоколів. У двох словах, Liquidity Staking дозволяє користувачам отримувати винагороди за ставки без шкоди для ліквідності. Ми окреслили вразливі місця в контрактах на стейкинг, на які аудитори повинні звернути увагу, наприклад механізми зняття коштів, логіку комісії, механізм карбування/спалювання токенів LP, помилки округлення, тривалість стекінгу, зовнішні виклики та перевірки маніпулювання цінами. 

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

---

11 думки

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
• джерело: https://blog.quillhash.com/2023/03/10/guidelines-for-auditing-staking-protocols/