Формальная проверка против аудита: почему «мы проверили код» уже недостаточно

После проверок я спал спокойно. Я больше нет. Когда я впервые увидел, как протокол после аудита потерял 30 миллионов долларов из-за взаимодействия с государством, которое пропустили аудиторы, я сказал себе, что это крайний случай. Во второй раз я обвинил прицел. В третий раз — где-то в пятом вскрытии, которое я прочитал на этой неделе, — я понял, что проблема не в одиторах. Это была методология. Аудит — это когда люди читают код и пишут тесты. Люди упускают вещи. Тесты пропускают пути. А в смарт-контракте, обрабатывающем реальный капитал, фраза «у нас, наверное, есть всё» не является моделью безопасности. Это желание. Оглавление Ситуация стала мрачно предсказуемой. Протокол привлекает капитал, заказывает аудит у уважаемой фирмы, получает отчет, исправляет отмеченные проблемы, развертывает и объявляет «проверено» своему сообществу. Спустя месяцы, а иногда и недели, деньги пропали. В октябре 2022 года Team Finance потеряла 14,5 миллионов долларов. Кодовую базу проверили две отдельные аудиторские фирмы. Один из них отметил уязвимую функцию миграции. Контракт все равно был использован. 18 апреля 2026 года из моста LayerZero компании Kelp DAO было истощено 116 500 rsETH — примерно 292 миллиона долларов США и около 18% всего оборотного запаса токена. Это стало крупнейшим эксплойтом DeFi в 2026 году. Посмертный вывод: ни один смарт-контракт не был нарушен. Ни один криптографический примитив не был скомпрометирован. Контракты выполнялись точно так, как написано. Сбой произошел в инфраструктуре оффчейн-верификатора — конфигурации с одной DVN, которая позволяла злоумышленнику подделывать межсетевое сообщение. Отчет об аудите не мог этого отразить, потому что в коде контракта не было ничего плохого. В 2025 году общие потери Web3 достигли 3,375 миллиарда долларов в результате 313 крупных инцидентов безопасности. Когда аудит становится «флажком» (то, что проект делает, чтобы сигнализировать о усердии, а не процессом, который значительно снижает риск), в отрасли возникает структурная проблема. И это так. Позвольте мне уточнить, что дает аудит смарт-контрактов, потому что отрасль склонна умалчивать об этом. Аудит предполагает, что группа исследователей безопасности читает ваш код, запускает статические анализаторы, пишет специальные тестовые примеры и документирует результаты своих исследований. Лучшие компании выявляют уязвимости повторного входа, целочисленные переполнения, проблемы контроля доступа, логические ошибки и опасные экономические крайности. Их отчеты подробны и действительно ценны. Но аудит ограничен человеческим вниманием и набором сценариев, которые рассматривают аудиторы. Ни один аудит не исследует все возможные пути исполнения контракта. Пространство состояний нетривиального смарт-контракта — все возможные комбинации входных данных, состояний хранения, контекстов вызова и последовательностей выполнения — слишком обширно, чтобы любой человек или фаззер мог его исчерпывающе охватить. Фаззинг выявляет примерно 80% проблем посредством рандомизированной генерации входных данных. Остальные 20% прячутся в математических крайних случаях, до которых случайные входные данные никогда не доходят. Аудитор, тестирующий сценарий первого депозита, может никогда не построить точное состояние, в котором totalSupply равно 1, а totalAssets  имеет тип (uint256).max, создавая инфляционную атаку. Аудит отвечает: «Мы нашли баги?» Он не дает и структурно не может ответить: «Ошибок не существует». Это не критика аудиторов. Это математическое ограничение метода. Формальная проверка представляет собой принципиально иную категорию гарантий. Вместо того, чтобы люди читали код и искали проблемы, формальная проверка преобразует смарт-контракты в математические спецификации, а затем использует автоматизированный проверяющий механизм для исчерпывающего поиска любого пути выполнения, который нарушает эти спецификации. Доказывающий не устает. Он не пропускает крайние случаи, потому что у него не хватило времени. Он не преминул рассмотреть сценарий, потому что он казался маловероятным. Он систематически исследует все пространство состояний, определенное спецификацией. Если проверяющий обнаруживает нарушение — переход состояния, который, по словам спецификации, должен быть невозможен, но код допускает — контракт не проходит проверку. Команда исправляет это и проверяет еще раз. Если доказывающий не обнаруживает нарушений, он представляет математическое доказательство. Не вероятность. Не высокий уровень доверия. Доказательство того, что в пределах указанных свойств код не может вести себя неопределённым образом. Ключевая фраза: в пределах указанных свойств. Формальная проверка подтверждает то, что вы указываете. Если вы укажете неправильные вещи или не укажете важное свойство, доказательство его не покрывает. Вот почему написание точных спецификаций — инвариантов, правил перехода состояний, свойств контроля доступа — так же важно, как и запуск проверяющего устройства. Самый сильный аргумент в пользу формальной проверки не является теоретическим. Это конкретные ошибки, которые все еще содержатся в исходном коде, проверенном несколькими экспертами. DAI MakerDAO, одна из наиболее тщательно изучаемых кодовых баз в DeFi, содержала нарушение собственного основного инварианта с момента его первого запуска в ноябре 2019 года до мая 2022 года. Это была математическая ошибка в основополагающем отчете протокола.