«Зомби‑смарт‑контракт» — это код в сети, который команда прекратила поддерживать или деактивировала, но который всё ещё продолжает выполняться и может хранить средства, принимать вызовы или исполнять логику. Публичные уведомления о деактивации или отключение фронтенда не отключают сам контракт. Байткод остаётся «живым» по своему адресу, поэтому взаимодействия продолжаются, пока вызывающие передают корректные входные данные. Эта динамика описана в Rekt post‑mortem по Aztec Connect.
В DeFi это оставляет длинный хвост заброшенных контрактов, которые сохраняют экономическую ценность и точки входа для вызовов в сети. Злоумышленники сканируют эти конечные точки, а боты или ничего не подозревающие пользователи могут взаимодействовать с устаревшими адресами. Риск сохраняется, потому что смарт‑контракты Ethereum по умолчанию неизменяемы; только явные проекты с возможностью обновления позволяют менять поведение.
Если путь обновлений или полномочия администратора удалены или отозваны, команды могут оказаться не в состоянии поставить на паузу, исправить или окончательно вывести устаревший контракт. Это ограничение следует из модели неизменяемости Ethereum и того, как паттерны proxy/UUPS/diamond опираются на роли администратора, как описано в документах по безопасности смарт‑контрактов Ethereum Foundation.
Как зомби‑смарт‑контракты сохраняются on‑chain
Ethereum smart contract’ы нельзя изменить после развертывания. Любая возможность менять поведение должна быть явно заложена через паттерны вроде прокси, UUPS или diamond, которые делегируют вызовы обновляемой логике. Эти паттерны зависят от ключей администратора или ролей управления (governance). Если эти роли настроены неверно, скомпрометированы или отозваны, команда может полностью потерять возможность исправить или окончательно вывести контракт, даже если публично объявила о прекращении. См. документацию Ethereum Foundation о последствиях для безопасности неизменяемости и паттернов обновлений.
Прекращение продукта или отключение сайта не влияет на байткод on‑chain. Адрес остаётся вызываемым, а любое остаточное состояние или ценность сохраняются. Атакующие могут взаимодействовать напрямую через транзакции, а интеграторы, которые всё ещё указывают на легаси‑адрес, могут непреднамеренно направлять пользователей на прекращённую логику. Явление заброшенных или зомби‑контрактов наблюдалось годами в академических и эмпирических работах, включая ранние измерения спящих и не поддерживаемых контрактов в Ethereum, о которых сообщал CSIRO Data61 (анализ 2016 года).
Что превращает прекращение (deprecation) в поверхность атаки
Риск после прекращения — не теоретический. Он возникает из нескольких практических механизмов, выявленных в реконструкциях инцидентов:
Активные точки входа: функции остаются вызываемыми даже после того, как проект объявил о прекращении, оставляя полезные операции открытыми для противников. Это было отмечено в технической реконструкции Aztec Connect.
Остаточная ценность: неизменяемые контракты всё ещё могут удерживать средства или позиции поставщиков ликвидности, превращая их в «мифические приманки» (honeypots) для специализированных эксплойтов или манипуляций со состоянием.
Сломанные предположения об админах/off‑chain участниках: если контракт ожидает, что оператор, relayer или sequencer будет вести себя определённым образом, эти предположения могут не сработать, когда команды сворачиваются или когда ключи удалены.
Архитектурные границы: несовпадения между off‑chain proof и on‑chain границей урегулирования могут быть злоупотреблены без «взлома» криптографии — как объяснено в пост‑мортеме Aztec Connect.
Отраслевые обзоры отмечали несколько сливов (drains) устаревших или легаси‑контрактов в разных блокчейнах в 2025–2026 годах, подавая это как операционный риск и риск жизненного цикла, а не как единый класс багов. Сводка PANews с цитированием ZeroDrift фиксирует эти наблюдения.
Пример из практики: прекращённый RollupProcessorV3 у Aztec Connect
В июне 2026 года устаревший контракт RollupProcessorV3, использовавшийся Aztec Connect, был выведен примерно на $2.1–$2.3 млн. Анализы описывают обход границы урегулирования (settlement‑boundary bypass) на устаревшем пути, а не новую криптографическую «поломку». Ключевой момент: контракт всё ещё был живым и вызывался по своему адресу даже после прекращения. Подробнее см. сводку PANews с цитированием ZeroDrift и пост‑мортем Rekt.
Суть — операционная: прекращение продукта не выводит из эксплуатации его on‑chain контракты. Пока точки входа не отключены или средства не мигрированы, остаточная ценность и вызываемая логика приглашают целевые эксплуатации.
Кто подвергается воздействию, когда протокол «уходит в тень» (goes dark)
Конечные пользователи с остаточными балансами: средства, оставленные в vault’ах, пулах или контрактах по типу escrow, могут оказаться «застрявшими» или подвергнутыми воздействию новых путей атаки.
Интеграторы и агрегаторы: роутеры или фронтенды, которые всё ещё ссылаются на легаси‑адреса, могут продолжать отправлять транзакции на прекращённую логику.
Команды протокола и DAO: если роли администратора были отозваны, чтобы сигнализировать децентрализацию, команда может оказаться не в состоянии поставить на паузу или запатчить легаси‑код, если появится новый риск. Это ограничение следует из модели, описанной в документах по безопасности Ethereum Foundation.
Аудиторы и мониторинги: инструменты часто фокусируются на активных развертываниях, оставляя слепые зоны для прекращённых адресов, даже если там хранится ценность.
Руководство по выводу из эксплуатации (runbook), которому могут следовать команды
Зомби‑контракты лучше всего предотвращать через планирование жизненного цикла. Отраслевые рекомендации, включая руководство OpenZeppelin Contracts & Upgrades, подчёркивают планирование миграций, использование multisig’ов для админов и внедрение безопасных режимов. Практический runbook выглядит примерно так:
Инвентаризируйте всё. Перечислите все развернутые адреса, прокси обновлений, роли администраторов, кикеров/обслуживающих (keepers), уполномоченных участников и зависимые сервисы.
Опубликуйте план «сворачивания» (wind‑down). Сообщите чёткие сроки и точные адреса, попадающие в зону охвата. Дайте пользователям окно для вывода средств и повторяющиеся напоминания.
Включите режимы только вывода (withdraw‑only) или паузы, если код поддерживает это. Предпочитайте управляемые состояния, которые позволяют выход (exits), но блокируют новые депозиты, заимствования или сложные потоки.
Слейте/выведите остаточную ценность, контролируемую протоколом. Мигрируйте средства казначейства и размотайте (unwind) позиции LP, которые удерживаются контрактами, принадлежащими администратору.
Отзовите approvals и роли. Уберите ключи операторов, отключите relayers и ужесточите списки контроля доступа в поэтапном, документированном порядке.
Завершите пути обновлений. Если прокси и обновления всё ещё возможны, направьте реализации на минимальную логику, которая блокирует изменяющие состояние точки входа, кроме выводов средств.
Укрепите администрирование. Перенесите любую оставшуюся власть на хорошо управляемый multisig (например, Safe) с явными подписантами и опубликованной политикой — как рекомендовано в практических руководствах вроде OpenZeppelin.
Выведите из эксплуатации off‑chain зависимости. Отключите keepers и автоматику, заархивируйте фронтенды и задокументируйте, что легаси‑адреса прекращены и не поддерживаются.
Следите и страхуйте хвост. Держите алерты, бонсы/гранты или покрытие на период после wind‑down, чтобы поймать неожиданные вызовы или потоки ценности в старые адреса.
Закройте цикл. Опубликуйте отчёт после вывода из эксплуатации (post‑decommissioning) с финальными состояниями и ссылками на эксплореры, чтобы пользователи и интеграторы могли проверить результат on‑chain.
Ограничения и заблуждения, за которыми нужно следить
Неизменяемость работает в обе стороны. Если ключи администратора отозваны (ренounced) или путь для обновлений никогда не существовал, команда не сможет позже добавить режим паузы или вывода средств. Это следует из модели неизменяемости и обновляемости.
Уведомление о прекращении (deprecation) — не выключатель (kill switch). Объявления или отключение интерфейса не делают контракт безопасным или неактивным. Это было подчеркнуто в реконструкции Aztec Connect.
Аудиты устаревают. Код, который однажды прошёл проверку, может стать рискованным, когда исчезают off‑chain участники, меняются экономические условия или перестают выполняться исходные предположения.
Не все прокси одинаковы. Плохо спроектированные пути обновления могут оставить неожиданные вызываемые маршруты или коллизии хранилищ (storage collisions), что усложняет вывод из эксплуатации.
Остаточные средства привлекают внимание. Даже небольшие балансы в устаревших адресах могут стимулировать атаки, нацеленные специально под ситуацию, — это отражено в трекерах инцидентов, процитированных PANews/ZeroDrift.
Где на практике вы столкнётесь с зомби‑контрактами
Читатели чаще всего сталкиваются с зомби‑контрактами, когда:
Следуйте туториалу или агрегатору, который ссылается на более старый адрес протокола, который с тех пор мигрировал.
Посмотрите несколько версий пула, хранилища (vault) или маршрутизатора (router) в блок-эксплорере, при этом без ясных указаний, какая версия сейчас является актуальной.
Взаимодействуйте напрямую по адресу контракта после того, как фронтенд офлайн, не зная, что функциональность была прекращена (deprecate), но не отключена (disabled).
Храните активы в протоколе, который объявляет о «сворачивании» (wind‑down), оставляя окно для вывода средств, но без on‑chain механизма, который бы блокировал последующие рискованные взаимодействия.
Прежде чем трогать легаси‑адрес, проверьте наличие прокси‑паттернов и текущую реализацию, подтвердите роли администраторов или состояния паузы, прочитайте последние advisory и убедитесь, что ваши действия соответствуют актуальному пути миграции протокола.
Часто задаваемые вопросы
Как понять, что контракт заброшен или всё ещё активен?
Ищите недавнюю активность on‑chain, объявления по governance или разработке, и проверьте, указан ли адрес как текущий в проекте. Узнайте, стоит ли контракт за прокси и обновлялась ли реализация недавно. Если роли администратора отозваны и нет пути обновлений, варианты поддержки ограничены согласно документации Ethereum Foundation.
Делает ли безопаснее протокол отозвание (renouncing) ключей администратора?
Это может снизить некоторые риски управления (governance), но также убирает возможность поставить на паузу, исправить или окончательно вывести ошибочный или прекращённый контракт. Этот компромисс заложен в модели неизменяемости и обновляемости Ethereum, описанной Ethereum Foundation.
Если контракт прекращён (deprecated), безопасно ли продолжать его использовать?
Нет. Уведомления о прекращении и отключение UI не отключают on‑chain код. Контракт остаётся вызываемым и может по‑прежнему удерживать средства — это видно в анализах, например в пост‑мортеме Rekt по Aztec Connect.
Зомби‑контракты — это только проблема Ethereum?
Нет. Паттерн может встречаться в любой сети с неизменяемыми или частично неизменяемыми смарт‑контрактами. Трекеры, процитированные PANews/ZeroDrift, наблюдали выводы средств из прекращённых или легаси‑контрактов в нескольких сетях в 2025–2026 годах.
Что должны делать интеграторы, когда зависимость прекращена (deprecated)?
Перенаправьте (repoint) на новые адреса, удалите или заблокируйте маршруты к прекращённой логике и выполните сфокусированный обзор интеграции. Рассмотрите добавление circuit breakers, более строгих allowlist’ов и предупреждений о прекращении, чтобы пользователи случайно не взаимодействовали с «зомби»-эндпоинтами.
Отказ от ответственности: эта статья предоставляется только в информационных целях. Она не предлагается и не предназначена для использования как юридическая, налоговая, инвестиционная, финансовая или иная рекомендация.