Аудит смарт-контрактов: что проверяют аудиторы и чего аудит не гарантирует

Аудит смарт-контракта — это независимая проверка кода и архитектуры в установленных границах. Его цель — выявить уязвимости, ошибки реализации и расхождения между ожидаемым и фактическим поведением.

Аудит может уменьшить неопределённость, но не делает контракт полностью безопасным. В официальном руководстве Ethereum аудит описывается как дополнительная проверка, а не универсальное средство, способное найти каждую ошибку.

Эта статья предназначена только для образовательных целей. Аудит не гарантирует безопасность, возврат средств или доходность.

Сначала определите область проверки

Качественный отчёт точно указывает, что было проверено:

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

Это важно, потому что даже настоящий аудит может относиться к старой версии, другому развёртыванию или только одной части большой системы.

Что обычно проверяют аудиторы

1. Ожидаемое поведение и инварианты

Аудиторы сопоставляют код со спецификацией:

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

Если в спецификации отсутствует важное требование, технически корректный код всё равно может реализовать небезопасную или нежелательную модель.

2. Управление доступом

Проверяющие изучают роли owner, admin, operator и другие привилегированные роли, включая полномочия:

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

Также оценивается, может ли один ключ выполнить критически важное изменение и предусмотрены ли средства контроля, например мультиподпись или timelock.

3. Внешние вызовы и повторный вход

Во время выполнения контракт может передать управление другому контракту. Это создаёт риск повторного входа: внешний контракт вызывает исходный контракт до завершения изменения состояния. Официальное руководство Solidity рекомендует там, где это применимо, строго соблюдать порядок проверок, изменений состояния и внешних взаимодействий.

4. Расчёты и единицы измерения

Аудиторы ищут:

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

5. Отказ в обслуживании и газ

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

6. Прокси и обновления

Для обновляемых систем проверка должна охватывать:

контракты прокси и реализации;
права upgrader или admin;
инициализацию;
совместимость структуры хранилища;
пути несанкционированного обновления;
последствия изменения логики после аудита.

Прокси может сохранять один и тот же пользовательский адрес, делегируя выполнение новой логике. Поэтому утверждение «контракт невозможно изменить» необходимо проверять по фактической архитектуре.

7. Интеграции

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

8. События и мониторинг

Проверяющие могут оценивать, точно ли события отражают важные действия: изменение ролей, обновления, приостановку и переводы. События помогают вести мониторинг, но не заменяют проверку состояния.

Методы аудита

Проверка обычно сочетает:

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

Ни один метод не охватывает всё. Формальная верификация может доказать соответствие кода формальной спецификации, но не способна доказать свойство, которое в спецификации не задано.

Как пользователю читать аудит

1. Сверьте проверенную версию

Найдите хеш коммита и установите:

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

Если это невозможно установить, отчёт даёт лишь ограниченные сведения о действующем развёртывании.

2. Читайте замечания, а не только резюме

По каждому замечанию проверьте:

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

Исправлено или Урегулировано is meaningful only when tied to a specific corrected version.

3. Изучите ограничения

Отчёты могут не охватывать:

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

Пользователи взаимодействуют со всей системой, а не только с её файлами Solidity.

4. Оцените административные риски

Выясните:

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

Это вопросы управления и доверия, даже если в коде не обнаружено уязвимостей.

5. Проверьте меры безопасности после аудита

К полезным постоянным мерам относятся:

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

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

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

отсутствие всех ошибок;
безопасность кода, изменённого после проверки;
безопасность сайта, кошелька, 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.

Чек-лист отчёта

Отчёт доступен в официальном источнике аудитора.
Указаны репозиторий и хеш коммита.
Критически важные контракты и зависимости входят в область проверки.
Проверенная версия соответствует действующему развёртыванию.
Проверка охватывает прокси, реализацию и администратора.
Статусы замечаний и повторная проверка задокументированы.
Допущения и исключения изучены.
Риски вне кода оценены отдельно.

Источники и дополнительные материалы

Ethereum.org — Безопасность смарт-контрактов
Ethereum.org — Тестирование смарт-контрактов
Ethereum.org — Формальная верификация смарт-контрактов
Solidity Documentation — Рекомендации по безопасности
OpenZeppelin Docs — Схема обновления через прокси