Риски, связанные со смарт-контрактами: аудит, уязвимости и то, что упускается из виду

Что на самом деле приводит к сбоям в смарт-контрактах?

Реентрантность — классический пример. Контракт отправляет средства на внешний адрес до обновления собственного состояния, а получатель, будучи контрактом, вызывает обратный вызов до того, как обновление вступит в силу, что приводит к циклическому списанию средств. Взлом DAO в 2016 году, ущерб от которого на тот момент составил около 60 миллионов долларов, закрепил этот тип уязвимости и привёл к расколу Ethereum на две ветви. Спустя десятилетие реентрантность по-прежнему встречается, иногда в экзотических формах: инцидент с Curve в 2023 году, ущерб от которого составил примерно 70 миллионов долларов по всем пулам, возник из-за сбоя защиты от реентрантности в определённых версиях самого компилятора Vyper, что означало, что контракты, исходная логика которых была корректной, компилировались в некорректный байт-код. Аудиторы, читавшие исходный код, могли сразу это заметить.

Манипуляции с оракулами нацелены на входные данные. Контракт, доверяющий ценовому фиду, может быть ограблен путем искажения цены, а флэш-кредиты предоставляют капитал для такого искажения в рамках одной атомарной транзакции. Mango Markets, ущерб от которого в 2022 году составил около 114 миллионов долларов, является каноническим примером, и механика таких атак остаётся стандартной; в этой части серии подробно анализируется данная схема.

Наиболее досадным классом являются сбои в контроле доступа: функции, которые может вызвать любой, из-за отсутствия модификатора; открытые инициализаторы; привилегированные роли, сохраняемые ключами развертывающего. Инциденты с кошельком Parity в 2017 году, когда были похищены десятки миллионов и навсегда заморожено более 150 миллионов долларов, в обоих случаях связаны именно с этим.

Арифметические ошибки и ошибки валидации сохраняются, несмотря на появление более безопасных языков программирования. В мае 2025 года из Cetus, крупнейшего DEX на Sui, было похищено около 223 миллионов долларов из-за того, что одна проверка на переполнение сравнивалась с неверной константой, что позволило специально сформированному значению пройти валидацию и исказить учет ликвидности. Согласно результатам анализа инцидента, контракт проходил аудит более одного раза. Важно отметить последствия для протокола: примерно 162 миллиона долларов были заморожены благодаря скоординированным действиям валидаторов и переведены в процесс восстановления и компенсации по результатам голосования сообщества. Общая сумма ущерба от эксплойта и сумма замороженных или направленных на восстановление средств должны указываться отдельно, а окончательная цифра чистого убытка должна указываться только после того, как будет подготовлен датированный бухгалтерский отчет, а не на основе предположений.

Наконец, чистая логическая ошибка: код, который компилируется, проходит тесты, делает то, что написано, но выдает неверный результат. Убыток Euler Finance в размере 197 миллионов долларов в 2023 году возник из-за сочетания механизма пожертвований с логикой ликвидации таким образом, что ни одна отдельная строка кода не позволяла это очевидно обнаружить. Для этого класса не существует сканера, поскольку с технической точки зрения ничего не сломано, кроме самой идеи.

Что на самом деле проверяет аудит, а что по замыслу находится за пределами его охвата?

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

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

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

Ничто из этого не является аргументом против аудитов. Это аргумент в пользу того, чтобы трактовать «проверенный» как «проверенный экспертами в условиях ограничений», что позволяет правильно оценить значение этого знака в соответствии с тем, что он может означать.

Почему прошедшие аудит протоколы по-прежнему теряют сотни миллионов?

Последние данные позволяют количественно оценить эту закономерность. TRM Labs насчитала 207 инцидентов в первой половине 2026 года — рекордное число, однако общий ущерб составил менее миллиарда долларов, что на 58 процентов меньше, чем годом ранее; эксплойты смарт-контрактов составили около 60 процентов инцидентов и небольшую долю ущерба, в то время как атаки на инфраструктуру, ключи, среды подписи и операционный доступ унесли примерно 76 процентов средств при доле инцидентов около 15 процентов. Цифры за 2025 год отражали ту же картину, но в более жестокой форме: было похищено около 3,4 миллиарда долларов, причем основную долю составило похищение 1,5 миллиарда долларов у Bybit, в ходе которого была атакована не какой-либо контракт, а рабочий процесс подписания. Злоумышленники переключаются на самый уязвимый уровень, и благодаря многолетнему аудиту устранение ошибок в контрактах стало более сложной задачей по сравнению с устранением уязвимостей в операционных процессах.

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

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

Как выглядит надёжный стек безопасности, выходящий за рамки аудита?

Избыточная проверка выявляет пробелы, обусловленные особенностями проверяющих: разные компании, разные методы, разные «слепые зоны», а также конкурсные платформы, на которых сотни независимых исследователей проверяют один и тот же код. Формальная верификация доказывает конкретные свойства, законность и инварианты доступа на основе математической модели; её ограничением является то, что она проверяет только те свойства, о формулировке которых кто-то подумал. Фузинг и тестирование инвариантов механически прочесывают пространство состояний и превосходно справляются с граничными случаями валидации класса Cetus; они достаточно дешёвы, так что их отсутствие теперь является тревожным сигналом.

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

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

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

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

Как эксперту следует читать отчёт об аудите?

Начните с области охвата. Какие контракты, какой коммит, что было исключено, и соответствует ли развернутый байт-код проверенному коду; блок-эксплореры позволяют легко проверить это, а несоответствия встречаются достаточно часто, чтобы проверять их регулярно. Аудит коммита A ничего не говорит о коммите B.

Рассматривайте допущения как список уязвимостей. «Мы предполагаем, что администратор честен» означает, что компрометация ключа администратора — это риск, который вам предстоит оценить. «Поведение Oracle выходит за рамки проверки» означает, что паттерн Mango не был изучен. Каждое заявленное допущение — это граница, на которой остановилась проверка, а границы — это места, где охотятся злоумышленники.

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

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

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

Часто задаваемые вопросы

Безопасен ли для использования протокол, прошедший аудит?

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

Почему бы просто не проводить аудит до тех пор, пока не останется ничего, что можно было бы найти?

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

В чём разница между аудитом и формальной верификацией?

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

Действительно ли программы вознаграждений за обнаружение ошибок работают?

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

Что, с точки зрения пользователя, является лучшим показателем культуры безопасности протокола?

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

Источники и дополнительная литература

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

• TRM Labs, Анализ криптохаков за первое полугодие 2026 года: количество инцидентов, общий ущерб и распределение по типам атак. https://www.trmlabs.com/resources/blog/h1-2026-crypto-hacks-reach-record-high-as-losses-fall-below-usd-1-billion
• Chainalysis, Отчет о криптовалютных преступлениях за 2026 год: анализ похищенных средств. https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2026/
• Halborn, разъяснение: взлом Cetus (май 2025 г.). https://www.halborn.com/blog/post/explained-the-cetus-hack-may-2025
• Sui Foundation, Реакция на инцидент с Cetus и голосование сообщества в цепочке: процесс заморозки и возврата 162 млн долларов. https://blog.sui.io/cetus-incident-response-onchain-community-vote/
• ethereum.org, документация по безопасности смарт-контрактов. https://ethereum.org/en/developers/docs/smart-contracts/security/
• ethereum.org, документация по оракулам. https://ethereum.org/en/developers/docs/oracles/
• Фонд Ethereum, история форков DAO и документация. https://ethereum.org/en/history/#dao-fork
• Рекомендация по блокировке реентрантности компилятора Vyper (июль 2023 г.) и анализ инцидента с Curve. https://hackmd.io/@vyperlang/HJUgNMhs2
• Материалы по анализу инцидента с Euler Finance и отчеты о восстановлении. https://www.euler.finance/blog
• Rekt News, архив анализов инцидентов и рейтинг. https://rekt.news/
• Immunefi: статистика платформы по поиску уязвимостей и структура программы. https://immunefi.com/
• Trail of Bits: руководство по безопасной разработке смарт-контрактов. https://github.com/crytic/building-secure-contracts
• Общественное объявление ФБР IC3, в котором кража средств с Bybit приписывается Северной Корее. https://www.ic3.gov/PSA/2025/PSA250226