Новое исследование, представленное на симпозиуме USENIX Security, показало, что 63% ранних транзакций авторизации EIP-7702 в Ethereum были связаны с контрактами, контролируемыми злоумышленниками. Из 3 664 166 авторизаций, зафиксированных в семи сетях до 15 июля 2025 года, 2 322 548 транзакций были ассоциированы с вредоносными контрактами, нацеленными на внешние счета (EOA).
EIP-7702 вошёл в обновление Pectra, активированное в Ethereum 7 мая 2025 года. Оно позволяет внешнему счёту делегировать выполнение кода смарт-контракта без переноса активов на новый адрес. Это открывает возможности для пакетных транзакций, спонсируемых комиссий и других функций абстракции аккаунтов, но одновременно передаёт делегированному коду полномочия действовать от имени аккаунта.
Исследователи проанализировали более 22,8 млрд исторических транзакций на Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base и Gnosis. Они выявили 924 вредоносных контракта: 793 были нацелены на EOA, 124 — на контрактные аккаунты, ещё семь отнесены к комбинированным атакам. Подтверждённые потери в трёх категориях составили $2 362 848,76. Отдельная оценка потенциального риска для устаревших контрактов достигает примерно $10,14 млн.
Проблема не сводится к ошибке в протоколе. Основной риск возникает на стыке гибкости EIP-7702, интерфейсов кошельков и фишинга: пользователь может подписать вредоносную авторизацию, не осознавая, что передаёт контракту контроль над аккаунтом. После этого автоматизированные системы способны быстро выводить активы.
Кроме того, EIP-7702 нарушает прежнее допущение, что проверка msg.sender == tx.origin идентифицирует обычный внешний счёт. Исследователи нашли 967 активных контрактов в Ethereum, использующих такую проверку как защиту от флэш-кредитов, и оценили их потенциальный риск примерно в $10,1 млн. Также обнаружены 500 специальных ненулевых целей делегирования без развёрнутого кода; такой адрес, созданный через CREATE2, может получить код позже и изменить поведение аккаунта.
Авторы подчёркивают, что мониторинг только текущего состояния недостаточен: злоумышленники переназначали аккаунты на безобидный код после атаки, поэтому история авторизаций становится частью контура безопасности. Рекомендации включают белый список делегируемых контрактов, явное отображение цели в кошельках, отказ от произвольного делегирования на аппаратных кошельках и использование проверенных реализаций. Для приложений предлагается запрашивать нужную функцию через интерфейсы уровня кошелька, такие как ERC-5792, а выбор конкретной системы — EIP-7702, ERC-4337 или другой — оставлять за кошельком.
Вывод исследования не в том, что абстракцию аккаунтов следует отменить, а в том, что новые возможности кошельков требуют сопоставимых по силе защитных инструментов.
