Смарт-контракты в DeFi: как оценить надежность кода проекта
Он не покрывает автоматически новую версию кода, изменившиеся параметры пула, ошибки компилятора или экономическую атаку через внешнюю ликвидность.
Это принципиальная разница для любого, кто оценивает риски смарт-контрактов перед тем, как внести средства в пул, использовать лендинг или взаимодействовать с другим dApp. Надпись «аудит пройден» сама по себе мало что говорит. Смотреть нужно на область проверки, найденные проблемы, исправления и то, совпадает ли проверенная версия с той, которая работает сейчас.
Анатомия аудита: от сканирования до ручной проверки
Комплексный аудит обычно занимает от двух до четырёх недель. Срок зависит от размера системы, её сложности, объёма документации и доступности разработчиков, которые отвечают на вопросы и выпускают исправления. За это время аудиторы проходят несколько этапов, и каждый отвечает за свой класс ошибок.
Сначала согласуют объём проверки: какие контракты входят в аудит, какие версии кода анализируются, какие зависимости и сценарии считаются частью системы. Если в отчёт попал только основной контракт, это не означает, что проверили весь маршрут движения средств. Токен, оракул, модуль управления, прокси-слой и внешние интеграции могут остаться за пределами охвата.
Дальше идут автоматические инструменты анализа смарт-контрактов. Например, Slither помогает выявлять типовые ошибки и подозрительные конструкции в коде; MythX проводит автоматизированный анализ безопасности, а Echidna используют для тестирования свойств контракта с разными входными данными. Такие инструменты полезны как быстрый фильтр: они находят часть известных паттернов и помогают аудиторам не тратить ручную проверку на очевидные вещи.
Затем начинается ручной разбор. Аудитор прослеживает, как меняются балансы и права доступа, кто может вызывать критические функции, как контракт обрабатывает ошибки внешних вызовов и что происходит при нестандартном порядке транзакций. В DeFi значимы и отдельные функции, и порядок их выполнения: например, как обновляется цена, когда меняется состояние пула и в какой момент пользователь может вывести активы.
Если для системы уместна формальная верификация, её применяют к конкретным свойствам кода. Такой анализ может проверить, выполняются ли заданные инварианты при определённых условиях. Сам набор свойств надо сформулировать правильно: проверка не спасёт от требования, которое забыли описать, и не докажет безопасность всей экономики протокола.
После проверки команда получает отчёт, исправляет замечания, а аудиторы оценивают изменения. Здесь существенна дисциплина версий: если разработчики внесли правки после основного аудита, важно понять, проверялись ли эти правки повторно и какой именно коммит считается финальным.
Аудит имеет смысл читать как карту границ проверки: что вошло в охват, какую версию смотрели и какие сценарии остались за кадром.
Почему сканеры не видят большую часть картины
Автоматизированный анализ хорош там, где уязвимость похожа на известный шаблон: например, опасный порядок операций или небезопасный внешний вызов. Протокол может быть уязвим и без очевидной ошибки в строках кода. Иногда проблема возникает из взаимодействия нескольких контрактов, нестандартного движения ликвидности или неверного экономического предположения.
По данным исследования 127 реальных атак на DeFi-протоколы общим объёмом около $2,3 млрд, автоматизированные инструменты безопасности могли бы предотвратить около 8% атак. В денежном выражении эти инциденты связаны с потерями примерно $149 млн из общих $2,3 млрд. Все атаки из этой предотвращаемой группы были связаны с повторным входом (reentrancy). Это узкий, но показательный результат: сканер способен ловить важный класс ошибок, однако его нельзя считать универсальным детектором эксплойтов.
В логике DeFi есть сценарии, которые трудно свести к проверке одного контракта. Допустим, протокол использует оракул и опирается на цену актива в пуле с низкой ликвидностью. Контракт может корректно исполнять описанные операции, но рыночный игрок способен временно сместить цену, использовать это состояние для займа и вернуть рынок в равновесие уже после вывода средств. Вопрос выходит за рамки кода: выдерживает ли экономическая модель атаку с доступным капиталом и подходящей последовательностью транзакций.
Похожая история возникает с фронтраном и манипуляциями порядком исполнения. Если результат операции чувствителен к состоянию пула между отправкой и включением транзакции в блок, атакующий может попытаться воспользоваться этой задержкой. Формальная проверка отдельной функции не обязательно ответит, насколько такая атака выгодна и при каких условиях она становится исполнимой.
Поэтому проверка смарт-контрактов на уязвимости должна сочетать автоматизированный анализ с ручной проверкой логики и экономических допущений. Сканеры дают полезный сигнал, но отсутствие предупреждений в их отчёте не означает, что протокол прошёл проверку на все возможные сценарии. Особенно если в систему входят оракулы, мосты, пулы с переменной ликвидностью или контракты внешних проектов.
Ошибки могут появиться до исполнения контракта
Смарт-контракт обычно оценивают по исходному коду, но между ним и работающим байткодом есть компилятор. Ошибка на этом уровне способна превратить корректно выглядящий код в небезопасную программу.
30 июля 2023 года уязвимость в компиляторе Vyper затронула версии 0.2.15, 0.2.16 и 0.3.0. В результате инцидента Curve Finance и связанные проекты потеряли около $70 млн. Этот случай важен именно тем, что ломает удобную схему «контракт проверен — значит, код безопасен»: нужно понимать, каким компилятором и какой его версией собрали проверяемую систему, а также совпадает ли сборка с тем, что развернуто в сети.
Есть и другие слои, которые легко теряются за значком аудита:
- Зависимости и внешние контракты. Если протокол опирается на сторонний токен, оракул или модуль, их поведение влияет на итоговый риск. Проверка основного репозитория не гарантирует, что аудиторы анализировали каждую внешнюю интеграцию.
- Права администратора. Владелец или DAO могут менять параметры, подключать новые модули, приостанавливать функции и обновлять реализацию. Эти полномочия иногда критичнее, чем качество отдельной функции.
- Прокси и обновления. Если логика контракта может обновляться, пользователь взаимодействует не только с текущей версией, но и с процессом управления будущими изменениями.
- Оракулы и рыночная ликвидность. Ошибка в источнике цены или уязвимое допущение о глубине пула способно открыть путь к атаке без классического бага в коде.
- Исправления после аудита. Даже небольшое изменение может затронуть права доступа или порядок операций. Надпись о проведённом аудите не сообщает, проверяли ли последнюю редакцию.
По данным DeFiLlama, к декабрю 2024 года совокупные потери в результате хакерских атак и эксплойтов в DeFi превысили $9,11 млрд. Эта сумма не означает, что все инциденты вызваны ошибками, которые должен был обнаружить аудит: у атак разные причины и механики. Масштаб потерь показывает, почему проверку нельзя сводить к одному PDF-файлу и статусу в профиле проекта.
Что на самом деле означает ценник аудита
Стоимость аудита смарт-контрактов может варьироваться от $5 000 до $100 000. На цену влияют сложность кода, репутация аудиторской компании и срочность. Такой диапазон не позволяет по одной цифре судить о качестве: дорогая проверка не гарантирует правильного охвата, бюджетный аудит при этом может быть полезен для небольшой системы с чётко очерченной областью работы.
Сравнивать предложения лучше по содержанию работ, чем по одной строке сметы:
| Параметр | Что выяснить |
|---|---|
| Охват | Какие контракты, библиотеки, зависимости и версии входят в проверку |
| Методы | Будут ли автоматический анализ, ручная проверка и тестирование сценариев |
| Экономическая логика | Проверяют ли только безопасность кода или также допущения о ликвидности, оракулах и взаимодействиях |
| Исправления | Включена ли повторная проверка после устранения найденных проблем |
| Результат | Получит ли команда подробный отчёт с уровнем серьёзности, доказательствами и рекомендациями |
| Актуальность | Как фиксируют проверенную версию и что происходит при последующих обновлениях |
Цена может отражать масштаб работы, но сама по себе не раскрывает глубину исследования. Для протокола с несколькими контрактами, сложными ролями доступа и внешними интеграциями короткая проверка узкого участка даст неполную картину, даже если её выполнила известная команда. Обратная ситуация тоже возможна: проект может получить аккуратный отчёт, но пропустить экономическую модель, потому что та не входила в согласованный объём.
Отдельный вопрос — время. Типичный аудит длится две-четыре недели. Если протокол торопится к запуску и просит проверить большой объём кода за считаные дни, это повод выяснить, какие этапы сократили. Быстрый обзор и комплексная проверка решают разные задачи; в коммуникации проекта их иногда упаковывают в одинаково уверенную формулировку.
Как читать отчёт и оценивать риски
Для начала найдите в отчёте точную область проверки и идентификатор версии: ссылку на коммит, тег релиза или иной способ сопоставить документ с кодом. Затем проверьте, совпадает ли эта версия с опубликованными контрактами. Если отчёт относится к старому коммиту, его выводы нельзя автоматически переносить на нынешнюю реализацию.
Далее посмотрите на найденные проблемы и их статус. В отчёте обычно указаны уровень серьёзности, описание сценария и рекомендуемое исправление. Важно понять, что команда сделала с каждым пунктом: исправила, приняла риск, отложила или отклонила замечание. Если проблему закрыли изменением кода, полезно увидеть подтверждение повторной проверки. Формулировка «решено» без объяснения может означать разные вещи.
Не менее важно читать ограничения. Аудиторы могут прямо обозначить, что не проверяли: например, внешние контракты, экономическую устойчивость, отдельные административные функции или обновления после определённой даты. Такие оговорки не обесценивают отчёт. Они показывают его реальные границы. Проблема возникает, когда краткий маркетинговый пересказ проекта делает вид, будто проверили весь протокол целиком.
Практический порядок чтения можно свести к четырём вопросам:
1. Что именно проверили? Сверьте список контрактов и модулей с архитектурой проекта, включая прокси, библиотеки и интеграции.
2. Какую версию проверили? Сопоставьте коммит или релиз с развернутым кодом и обновлениями, опубликованными после аудита.
3. Что нашли и как исправили? Проследите судьбу замечаний, особенно тех, которые связаны с доступом к средствам, обновлением кода и внешними вызовами.
4. Какие риски исключены из охвата? Ищите оговорки об оракулах, экономической модели, зависимости от сторонних контрактов и управлении протоколом.
Отчёт отвечает на вопрос о проверенной версии и её границах. Он не выдаёт бессрочный сертификат безопасности всему проекту.
Учитывайте и то, как устроено управление. Если команда или DAO может обновлять контракт, менять параметры или переключать внешние источники данных, аудит описывает только один этап жизненного цикла. Для пользователя важны полномочия, которыми располагают администраторы, порядок принятия решений и возможность быстро изменить поведение системы после публикации отчёта.
Наконец, не путайте наличие инструментов с полнотой анализа. Slither, MythX и Echidna помогают искать конкретные классы проблем, но не заменяют ручной разбор и не оценивают автоматически все экономические аномалии. Даже формальная верификация зависит от того, какие свойства проверяли и насколько полно они отражают реальные сценарии протокола.
Вердикт: аудит полезен, но его нужно читать вместе с архитектурой
Аудит остаётся одним из главных сигналов о дисциплине разработки DeFi-протокола. Он даёт независимый разбор кода, фиксирует замечания и помогает команде устранить часть уязвимостей до того, как ими воспользуется атакующий. Его надёжность для читателя определяется конкретикой: охватом, методами, версией кода, статусом исправлений и оговорёнными ограничениями.
Поэтому оценка смарт-контрактов в DeFi начинается с документов, но не заканчивается ими. Сопоставьте отчёт с архитектурой проекта, выясните, кто контролирует обновления, какие внешние зависимости участвуют в движении средств и что происходит при манипуляции ценой или ликвидностью. Для DeFi именно связки между компонентами часто важнее красивого статуса «проверено».
В этой экосистеме безопасность не статична: код меняется, протоколы подключают новые модули, а ликвидность переходит между пулами. Аудит полезно воспринимать как сильный, но ограниченный снимок системы. Чем точнее вы понимаете, что попало в этот снимок, тем меньше шансов принять его за гарантию.
