Как читать отчёт об аудите смарт-контракта после подозрительной активности

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

Как выглядит схема со стороны жертвы

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

Второй сюжет — объявление о замене логики, пришедшее через канал проекта. Канал мог быть захвачен, и тогда «плановое обновление» оказывается чужой реализацией. Связка между угоном публичного аккаунта и последующими операциями разобрана в материале о том, как защитить аккаунт проекта в социальной сети от угона.

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

Признаки, по которым распознаётся подмена

Сверяют адреса. В отчёте указан адрес или хеш коммита проверенной реализации. В сети действующий адрес реализации читают из служебной ячейки посредника: стандарт ERC-1967 закрепил для неё позицию 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, полученную как значение хеш-функции от строки eip1967.proxy.implementation минус единица.

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

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

Проверка за 60 секунд: что открыть и на что смотреть

1. Откройте страницу адреса в обозревателе и выясните, посредник это или обычный контракт. Обозреватели показывают признак прямо в заголовке.
2. Прочитайте служебную ячейку реализации по позиции из стандарта ERC-1967. Последние двадцать байтов значения — адрес действующей логики.
3. Сравните полученный адрес с адресом или хешем коммита из отчёта об аудите. Это главная сверка.
4. Посмотрите список событий обновления и сопоставьте даты замен с датой окончания аудита.
5. Проверьте, опубликованы ли исходники действующей реализации и подтверждено ли совпадение сборки с байткодом.

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

Пошаговые действия, если деньги уже ушли

Разбор по контракту требует фиксации состояния сети, а оно меняется. Снимайте доказательства сразу. До любых действий.

1. Зафиксируйте текущее значение служебной ячейки реализации, адрес посредника, номер блока и время в UTC.
2. Выгрузите список событий обновления и свою операцию с идентификатором. Сохраните копию отчёта об аудите.
3. Отзовите выданные посреднику разрешения на расход токенов. Отзыв не возвращает списанное, зато закрывает дальнейший расход.
4. Подайте заявление в орган внутренних дел. По статье 144 Уголовно-процессуального кодекса решение принимается в срок до трёх суток, с продлением до десяти, а при документальных проверках — до тридцати суток.
5. Если цепочка уходит в сервис с идентификацией клиентов, укажите это в заявлении: запросы к таким сервисам направляют уполномоченные органы, а не пострадавший.

Национальный контур расследования опирается на аналитику Росфинмониторинга: государственный модуль сервиса «Прозрачный блокчейн» к сентябрю 2026 года подключили более восьмидесяти банков, а анализ охватывает более тридцати криптовалют. Границы самостоятельной трассировки описаны в материале о том, как проследить движение украденных средств и подготовиться к худшему сценарию.

Как закрыть дыру, чтобы не повторилось

Первое — подписка на события обновления. По тем адресам, где лежат ваши средства. Уведомление о смене логики приходит раньше, чем новость в канале проекта, и не зависит от того, кто этим каналом владеет.

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

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

Чек-лист

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

Частые вопросы