Чек-лист перед аудитом смарт-контракта: что подготовить команде

Перед аудитом смарт-контракта нужно заморозить код на конкретном коммите, описать назначение каждого контракта и все роли, записать инварианты, довести тесты и статический анализ до чистого состояния, подготовить скрипты деплоя и список внешних зависимостей. Аудитор оплачивается за время. Каждый час, который он тратит на выяснение «что здесь должно происходить», вы оплачиваете вместо поиска уязвимостей. Ниже — чек-лист из 30 пунктов, разбитый на шесть блоков.

Что аудит даёт, а что нет

Хорошая подготовка нужна не ради формальности. Когда код, документация и тесты в порядке, аудитор сразу переходит к сути: ищет сценарии, которые команда не предусмотрела. Когда документации нет, первые дни уходят на расспросы и чтение кода «с нуля», а часть рисков может остаться незамеченной просто потому, что не хватило времени.

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

Блок 1. Объём и заморозка кода

1. Зафиксируйте коммит или тег, который идёт в аудит, и не меняйте код в этой ветке до отчёта.
2. Составьте список файлов в объёме аудита и отдельно — вне объёма (моки, тесты, скрипты).
3. Посчитайте строки кода без комментариев по каждому файлу: аудиторы оценивают работу по этому показателю.
4. Укажите точные версии компилятора, evmVersion, настройки оптимизатора и via-IR.
5. Зафиксируйте версии зависимостей, например OpenZeppelin 5.7.0, и способ их установки.

Блок 2. Документация

1. Короткое описание продукта: что делает система и кто её пользователи.
2. Назначение каждого контракта и схема взаимодействия между ними.
3. Все роли: кто их получает при деплое, кто может выдавать и отзывать, что каждая роль может сделать.
4. Описание движения денег: откуда приходят средства, где лежат, при каких условиях уходят.
5. Формулы расчётов (награды, комиссии, графики) с примерами чисел и правилами округления.
6. Известные ограничения и осознанные компромиссы, чтобы аудитор не тратил время на то, что вы и так знаете.
7. NatSpec-комментарии (@notice, @dev, @param) у всех внешних функций.

Блок 3. Инварианты и угрозы

1. Список инвариантов на человеческом языке: «сумма балансов равна общей эмиссии», «контракт не выдаёт больше, чем получил».
2. Тот же список в виде инвариантных тестов. Как их писать — в статье о тестировании в Foundry и Hardhat.
3. Модель угроз: что самое ценное в системе и как его можно украсть, заблокировать или обесценить.
4. Перечень внешних зависимостей с адресами: оракулы, токены, DEX, мосты. Что будет, если каждая из них поведёт себя неправильно.
5. Предположения о токенах: работаете ли вы с токенами с комиссией за перевод, с ребейзом, с нестандартным возвратом transfer.

Блок 4. Тесты и анализ

1. Все тесты проходят одной командой из инструкции в README.
2. Отчёт о покрытии строк и веток с объяснением непокрытых участков.
3. Фаззинг и инварианты с увеличенным числом прогонов в CI.
4. Чистый вывод Slither: каждое предупреждение исправлено или объяснено.
5. Тесты на форке сети для интеграций с внешними протоколами.
6. Нет закомментированного кода, TODO, отладочных функций и тестовых адресов в основных контрактах.

Блок 5. Права и обновления

1. Схема прав после деплоя: какие роли уходят мультиподписи, таймлоку, кому-то ещё.
2. Если контракты обновляемые: схема прокси, кто вправе обновлять, проверка раскладки storage. Подробности — в статье о proxy и UUPS.
3. Перечень функций экстренной остановки и кто может их вызвать.
4. Описание того, что может сделать администратор со средствами пользователей в худшем случае.

Блок 6. Деплой

1. Скрипты деплоя в репозитории, с параметрами для каждой сети.
2. Список сетей и порядок развёртывания контрактов, если они зависят друг от друга.
3. План передачи прав и проверки после деплоя. О ключах и верификации — в статье о деплое смарт-контракта.

Когда заказывать аудит

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

Что положить в пакет для аудитора

• Ссылку на репозиторий и тег, доступ на чтение.
• README с командами сборки и тестов, которые работают на чистой машине.
• Документ с описанием системы, ролей, движения денег и инвариантов.
• Отчёт о покрытии и вывод статического анализа.
• Список вопросов, которые беспокоят саму команду: аудиторы ценят такие подсказки.
• Контакт разработчика, который быстро отвечает на вопросы во время аудита.

После отчёта аудитора

Аудитор присылает список находок с уровнями критичности. Каждую нужно исправить или обосновать, почему она принимается как риск. Исправления делаются отдельными коммитами, и аудитор проверяет именно их. Публикуйте итоговый отчёт вместе с коммитом, на котором он сделан, и проверьте, что развёрнутый байт-код соответствует этому коммиту. Иначе пользователи увидят отчёт об одном коде, а работать будут с другим.

Что ещё сделать до запуска

Аудит — одна из линий защиты. Вторая — ограничения: лимиты на вывод, пауза для экстренных случаев, постепенное увеличение сумм. Третья — наблюдение: оповещения о крупных переводах, о вызовах административных функций и о необычной активности. Это задача мониторинга контрактов и реагирования на инциденты. Если проект связан с обычным сайтом и бэкендом, их безопасность проверяют отдельно, например в рамках аудита безопасности.

Подготовить код к аудиту, написать недостающие тесты и инварианты поможет команда разработки смарт-контрактов. Отдельно у нас есть страница аудита смарт-контракта.