Аудит розумних контрактів: що перевіряють аудитори, а що аудит не гарантує

Аудит смартконтракту — це незалежна перевірка коду й архітектури в межах визначеного обсягу. Її мета — виявити вразливості, помилки реалізації та невідповідності між очікуваною і фактичною поведінкою.

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

Ця стаття має виключно освітню мету. Аудит не гарантує безпеку, повернення коштів або дохід.

Спочатку — обсяг перевірки

Корисний звіт точно визначає, що саме перевірялося:

репозиторій і хеш commit;
файли та контракти;
версія компілятора й налаштування збірки;
залежності;
архітектура та привілейовані ролі;
гілка або реліз;
винятки, обмеження та припущення;
дата перевірки.

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

Що зазвичай перевіряють аудитори

1. Очікувана поведінка та інваріанти

Аудитори порівнюють код із його специфікацією:

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

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

2. Контроль доступу

Аудитори перевіряють ролі owner, admin, operator та інші привілейовані ролі, зокрема повноваження:

надавати або відкликати дозволи;
призупиняти систему;
змінювати комісії та ліміти;
карбувати токени;
виводити активи;
оновлювати реалізацію.

Також перевіряють, чи може один ключ здійснити критичну зміну та чи передбачені в архітектурі такі засоби контролю, як multisig або timelock.

3. Зовнішні виклики та повторний вхід

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

4. Розрахунки та одиниці

Аудитори шукають:

округлення та втрата точності;
невідповідні десяткові знаки токенів;
неправильний порядок операцій;
граничні значення;
ділення на нуль;
unsafe unchecked arithmetic;
розбіжності між внутрішніми й показаними одиницями.

5. Відмова в обслуговуванні та gas

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

6. Proxy-контракти та оновлення

Для систем із можливістю оновлення перевірка має охоплювати:

контракти proxy та implementation;
права на оновлення або адміністрування;
ініціалізація;
сумісність storage layout;
можливості несанкціонованого оновлення;
наслідки зміни логіки після аудиту.

Proxy може зберігати ту саму адресу для користувача, делегуючи виконання новій логіці. Тому твердження «контракт неможливо змінити» слід перевіряти з урахуванням фактичної архітектури.

7. Інтеграції

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

8. Події та моніторинг

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

Методи, що використовуються під час аудиту

Перевірка зазвичай поєднує:

ручний аналіз коду й архітектури;
модульне та інтеграційне тестування;
статичний і динамічний аналіз;
fuzzing зі згенерованими вхідними даними;
тестування на основі властивостей;
перевірки відомих класів вразливостей;
перевірка збірки та розгортання;
іноді — формальна верифікація вибраних властивостей.

Жоден метод не охоплює все. Формальна верифікація може довести відповідність коду формальній специфікації, але не може довести властивість, якої в специфікації не зазначено.

Як користувачеві читати звіт про аудит

1. Зіставте з перевіреною версією

Знайдіть хеш commit і визначте:

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

Якщо це неможливо встановити, звіт надає лише обмежені докази щодо чинного розгортання.

2. Читайте висновки, а не лише резюме

Для кожного висновку перевірте:

рівень серйозності та сценарій;
зачеплений код;
рекомендація;
відповідь розробника;
поточний статус;
чи провів аудитор повторне тестування виправлення.

Виправлено або Вирішено is meaningful only when tied to a specific corrected version.

3. Прочитайте про обмеження

Звіти можуть не охоплювати:

системи frontend і backend;
керування ключами;
економічна модель;
сторонні контракти;
інфраструктура розгортання;
виробнича конфігурація;
юридичні та операційні питання.

Користувачі взаємодіють з усією системою, а не лише з її файлами Solidity.

4. Оцініть адміністративний ризик

Запитайте:

хто контролює оновлення;
чи можна призупиняти операції;
чи можуть змінюватися комісії або пов’язані адреси;
чи існує timelock;
чи використовується мультипідпис;
як користувачі дізнаються про зміни.

Це питання управління та довіри, навіть якщо в коді не виявлено вразливостей.

5. Перевіряйте безпеку й після аудиту

Корисні показники для постійного моніторингу:

тестування кожного релізу;
перевірка значних оновлень;
програма винагород за виявлення помилок;
моніторинг ролей та implementations;
процедури реагування на інциденти;
обмеження обсягу активів під ризиком.

Чого аудит не гарантує

Аудит не гарантує:

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

Запитання, які має поставити обачний користувач

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Контрольний список звіту

Звіт доступний у джерелі аудитора.
Репозиторій і хеш commit зазначено.
Критичні контракти й залежності входять до обсягу перевірки.
Перевірена версія відповідає чинному розгортанню.
Proxy, implementation і admin охоплено перевіркою.
Процедури визначення статусу й повторного тестування задокументовано.
Припущення та винятки прочитано.
Ризики поза кодом оцінено окремо.

Джерела та додаткові матеріали

Ethereum.org — Безпека смартконтрактів
Ethereum.org — Тестування смартконтрактів
Ethereum.org — Формальна верифікація смартконтрактів
Solidity Documentation — Питання безпеки
OpenZeppelin Docs — Шаблон оновлення Proxy