Аудит блокчейн-проекта: что проверяют и зачем

Ошибка в обычном коде исправляется выкладкой. Ошибка в опубликованном в блокчейне смарт-контракте исправляется выпуском нового контракта и переносом всего накопленного состояния — держателей, балансов, связей. Поэтому аудит блокчейн-проекта стоит перед запуском, а не после, и стоит он заметной части бюджета.

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

Что проверяют в аудите блокчейн-проекта

Аудит — это не одна проверка, а четыре слоя, и пропуск любого делает остальные бессмысленными.

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

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

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

• Он не покрывает правки после проверки. Одна строка, добавленная после сдачи отчёта, выводит контракт за пределы проверенного.
• Он не отвечает за внешние протоколы. Если контракт берёт цену у стороннего источника, поведение этого источника — отдельный риск.
• Он не оценивает бизнес-модель. Вопрос, сходится ли экономика проекта, к аудитору не относится.
• Он не защищает от потери ключа. Самый частый способ потерять контроль над контрактом не имеет отношения к коду.

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

Как подготовиться и не переплатить

Аудит оплачивается временем аудитора, а время уходит на чтение. Всё, что делает чтение быстрее, снижает цену.

Стандартные библиотеки вместо своих реализаций. Проверенные реализации токенов и контроля доступа читаются глазами за минуты, потому что аудитор их уже знает. Собственная реализация той же логики читается часами. Референсные библиотеки и обоснование их выбора описаны в документации OpenZeppelin Contracts.

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

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

Заморозка кода. Версия фиксируется на всё время проверки. Правки по ходу аудита — самый быстрый способ раздуть счёт: проверенное приходится читать заново, и оплачивается это как новая работа.

Перед подготовкой к проверке имеет смысл свериться с базовыми понятиями — что вообще исполняется в сети и почему это нельзя откатить, разобрано в статье «что такое смарт-контракт». Ограничения самого языка и поведение при ошибках описаны в документации Solidity.

Что делать с отчётом

Находки приходят с уровнями: критические, высокие, средние, низкие и замечания. Обрабатывать их нужно по-разному.

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

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

Кто проверяет и как читать отчёт

Рынок проверок неоднороден, и разница между исполнителями больше, чем между ценами. Полезно смотреть на три вещи.

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

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

Повторный проход. Входит ли проверка исправлений в цену или продаётся отдельно — вопрос, который выясняют до подписания, а не после получения находок.

Читая готовый отчёт, обращайте внимание не только на список находок, но и на раздел с допущениями: там написано, что аудитор считал за пределами проверки. Обычно туда попадают внешние протоколы, поведение владельца ключей и экономическая модель — то есть ровно те риски, за которые дальше отвечает бизнес, а не проверяющий.

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

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

• Наблюдение за поведением. Оповещения на нетипичные операции: крупный вывод, серия одинаковых вызовов, обращение к функциям управления.
• План на плохой день. Заранее описанный порядок действий: кто принимает решение, что можно остановить и как об этом сообщат пользователям.
• Разделённые права. Управление через мультиподпись и задержка перед исполнением изменений — чтобы неверная или чужая команда не сработала мгновенно.
• Программа вознаграждений за находки. Работает постоянно, а не один раз, — но только если о ней знают: без потока исследователей она стоит времени и не приносит находок.

Когда аудит не нужен

Если контракт — стандартный токен без изменённой логики, развёрнутый библиотечным кодом без единой собственной строки, полноценный аудит избыточен: проверять нечего, весь код уже проверен многократно. Достаточно прогнать анализаторы, убедиться, что параметры выпуска верные, и корректно распорядиться правами владельца.

Аудит становится обязательным ровно тогда, когда появляется своя логика: комиссии, распределение, вестинг, стейкинг, связь нескольких контрактов между собой. С этого момента каждая новая связка добавляет к проверке больше времени, чем добавила к разработке.

Один вопрос помогает понять объём работ ещё до разговора с подрядчиком: сколько строк в ваших контрактах написано вами, а не взято из стандартной библиотеки? Если ноль — вам нужна проверка параметров публикации, а не аудит. Если много — считайте аудит обязательной статьёй бюджета.

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