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

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

Что на самом деле проверяет аудит

Аудит смарт-контракта — это ручная и автоматизированная проверка кода контракта, которая обычно проводится перед развёртыванием и ищет известные шаблоны уязвимостей: ошибки реентерабельности (reentrancy), переполнение и антипереполнение целых чисел, ошибки контроля доступа, из-за которых привилегированную функцию может вызвать не тот адрес, и логические ошибки, расходящиеся с заявленным назначением контракта. Аудиторы также сверяют контракт с документацией самого проекта, отыскивая места, где код делает не то, что заявлено.

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

Что аудиты находят надёжно

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

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

Что аудиты не находят

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

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

Что это значит на практике

Аудит стоит воспринимать как заметное снижение риска в отношении известных категорий ошибок, а не как доказательство безопасности. Опубликованный отчёт об аудите стоит читать, а не только на него ссылаться: нужно проверить, какой объём он реально охватил, были ли найденные проблемы устранены или лишь зафиксированы, и насколько давно он проводился относительно текущего, возможно изменившегося кода. Аудит снижает риск; он его не устраняет, и ни один добросовестный проект не должен создавать иное впечатление.