Як оцінити звіт про аудит смарт-контракту
Звіт про аудит смарт-контракту — не гарантія безпеки. Дізнайтеся, як перевірити обсяг, знахідки, виправлення та репутацію аудитора, а також тривожні ознаки підроблених аудитів.
Щоб оцінити звіт про аудит смарт-контракту, переконайтеся, що він справжній і опублікований самим аудитором, перевірте, що його обсяг охоплює фактично розгорнуті контракти, прочитайте критичні та високі знахідки й з’ясуйте, чи виправлено кожну з них, а також зверніть увагу на те, чого аудит явно не охоплював. Аудит — це знімок конкретного коду, а не гарантія того, що проєкт безпечний чи чесний.
Проєкти часто подають позначку «пройшов аудит» як знак довіри. Одні аудити ретельні й змістовні, інші вузькі, застарілі або підроблені. Якщо ви знаєте, як читати звіт, то побачите різницю приблизно за п’ятнадцять хвилин.
Що таке аудит смарт-контракту
Аудит смарт-контракту — це перевірка безпеки, під час якої фахівці читають код проєкту, тестують його й шукають вразливості, як-от reentrancy, помилки контролю доступу, математичні помилки та логічні вади. Потім вони публікують звіт, де перелічують знайдене, оцінюють серйозність кожної проблеми й описують реакцію команди. На цю тему: Експлойти смарт-контрактів.
Аудити цінні, бо смарт-контракти важко змінити після розгортання, а зберігають вони нерідко великі суми. Проте аудитори працюють в умовах обмеженого часу, перевіряють лише те, що їм надали, і можуть пропустити тонкі проблеми. Чимало зламаних протоколів проходили аудит.
Розділи типового звіту про аудит
| Розділ | На що звертати увагу |
|---|---|
| Резюме | Назва аудитора, проєкт, дати, загальний висновок |
| Обсяг | Точні файли, контракти, хеш коміту або перевірені розгорнуті адреси |
| Методологія | Ручна перевірка, автоматизовані інструменти, тестування, формальна верифікація |
| Знахідки | Кожна проблема з рівнем серйозності, описом і рекомендацією |
| Статус | Чи кожну знахідку виправлено, взято до відома чи оскаржено |
| Відмова від відповідальності | Обмеження перевірки |
Покроково: як оцінити звіт
1. Переконайтеся, що звіт справжній
Підроблені аудити — відома шахрайська тактика. Шукайте звіт на офіційному сайті або в GitHub аудитора, переходячи туди самостійно. Якщо аудитор ніколи не чув про проєкт або звіт існує лише як PDF на сайті проєкту, вважайте його неперевіреним. У нашому посібнику про підроблені аудити перелічено поширені хитрощі.
2. Звірте обсяг із тим, що розгорнуто
У звіті має бути вказано коміт коду або адреси контрактів. Перевірте в оглядачі блоків, що розгорнуті контракти збігаються. Поширені прогалини:
- Аудит охоплював попередню версію, а код згодом змінився.
- Перевіряли лише контракт токена, а не контракти стейкінгу, сховищ чи мостів, де зберігаються кошти користувачів.
- Контракти оновлювані, тож код можуть пізніше замінити.
3. Спершу прочитайте серйозні знахідки
Переходьте одразу до критичних і високих проблем. Щодо кожної запитайте себе:
- Чи позначено її як усунену і чи перевірив аудитор виправлення?
- Якщо її «взято до відома», а не виправлено, чим це пояснює команда?
- Чи стосується вона прав адміністратора, наприклад можливості випускати токени, призупиняти перекази чи виводити кошти?
Взяті до відома проблеми централізації часто важливіші для інвесторів, ніж помилки в коді. Власник, здатний випускати необмежену кількість токенів, — це ризик, навіть якщо код працює ідеально.
4. Перевірте дати
Зверніть увагу, коли проводили аудит, і порівняйте це з датою розгортання та пізнішими оновленнями. Старий аудит протоколу, який часто оновлюють, мало що каже про сьогоднішній код.
5. Оцініть аудитора
Звертайте увагу на аудиторів із публічною історією роботи, докладними опублікованими звітами та дослідниками безпеки, названими на ім’я. Односторінковий звіт без подробиць від фірми, яка перевіряє сотні токенів на місяць, важить менше.
6. Прочитайте відмову від відповідальності та обмеження
У відмові від відповідальності зазвичай зазначено, що аудит не охоплює економічну модель, позамережеві компоненти, оракули, код фронтенду та майбутні зміни. Саме в цих сферах трапляється багато реальних втрат.
Як розуміти рівні серйозності
Більшість аудиторів використовують схожу шкалу, хоча визначення в різних фірм відрізняються:
| Серйозність | Типове значення | Наскільки це має вас турбувати |
|---|---|---|
| Критична | Можлива пряма втрата або крадіжка коштів | Має бути виправлена до запуску; якщо не усунена — тримайтеся осторонь |
| Висока | Серйозна втрата коштів або непрацюючі ключові функції за певних умов | Має бути виправлена; перевірте, що аудитор це підтвердив |
| Середня | Проблеми за особливих обставин або значна централізація | Читайте уважно, особливо знахідки про повноваження адміністратора |
| Низька | Дрібні проблеми з обмеженим впливом | Зазвичай прийнятно, якщо взято до відома |
| Інформаційна | Якість коду, ефективність газу, найкращі практики | Рідко турбує користувачів |
Звіт із великою кількістю знахідок — не обов’язково погана новина. Це може означати, що аудитор був ретельним, а команда виправила проблеми до запуску. Важливо, наскільки серйозне те, що лишилося неусуненим, і як відреагувала команда. Команда, яка оскаржує кожну знахідку або мовчки ігнорує серйозні, багато каже про свою культуру безпеки.
Тривожні ознаки у звітах про аудит
- Немає подробиць про обсяг, хешу коміту чи адрес контрактів.
- Критичні проблеми позначено як «взяті до відома» без виправлення.
- Знахідки про права власника, які проєкт применшує.
- Звіт розміщено лише в проєкту.
- Маркетингові заяви на кшталт «100% безпечно» чи «повністю захищено аудитом».
- Аудит датовано задовго до великих змін коду.
Чого аудит вам не скаже
Навіть сильний аудит не відповідає на питання:
- Чи справжня команда і чи можна їй довіряти — див. як перевірити, чи справжня криптокоманда.
- Чи заблоковано ліквідність, чи її можуть вивести.
- Чи справедливі пропозиція токена та графіки розблокування.
- Чи може економічна модель протоколу не витримати навантаження.
Поєднуйте аудит з іншими перевірками: публічною програмою bug bounty, кількома незалежними аудитами, часом роботи без інцидентів і прозорими правами адміністратора.
Підсумок
Звіт про аудит корисний як доказ лише тоді, коли він справжній, актуальний і охоплює контракти, якими ви справді користуєтеся. Перевірте джерело, звірте обсяг, прочитайте серйозні знахідки та те, як їх усунули, і зверніть увагу на те, що залишилося поза межами. Використовуйте його як одну зі складових свого дослідження, але ніколи як доказ безпечності проєкту.
Поширені запитання
Чи означає аудит, що криптопроєкт безпечний?
Ні. Аудит — це перевірка конкретного коду в конкретний момент конкретною командою. Він може пропустити помилки, нічого не каже про чесність команди чи токеноміку й не охоплює код, змінений після перевірки. Чимало зламаних протоколів проходили аудит. Вважайте аудит одним із доказів, а не гарантією.
Як зрозуміти, що звіт про аудит справжній?
Знайдіть звіт на власному сайті або в офіційному GitHub аудитора, а не лише на сайті проєкту. Переконайтеся, що адреси контрактів або коміт коду у звіті збігаються з тим, що розгорнуто. Деякі аудитори дають змогу перевірити звіти напряму. PDF-файлу, який існує лише в каналах проєкту, недостатньо.
Що означають рівні серйозності в аудиті?
Аудитори зазвичай класифікують знахідки як критичні, високі, середні, низькі та інформаційні. Критичні й високі проблеми можуть призвести до втрати коштів або непрацездатності протоколу. Найважливіше — чи ці серйозні знахідки виправили і чи підтвердив аудитор виправлення під час повторної перевірки.
Чи достатньо одного аудиту?
Для великих протоколів, що зберігають значні кошти користувачів, один аудит часто вважають мінімумом. Кілька незалежних аудитів, публічна програма bug bounty, формальна верифікація ключових компонентів і довга історія без інцидентів разом дають набагато вагоміші докази, ніж будь-який окремий звіт.