Как EIP-7702 влияет на безопасность кошельков? Понимание рисков делегирования и кражи активов

EIP-7702 — важное улучшение протокола в развитии абстракции аккаунтов Ethereum. Оно позволяет традиционным EOA-кошелькам делегировать логику выполнения смарт-контрактов с помощью авторизации. Благодаря этому обычные адреса могут поддерживать пакетные транзакции, спонсирование комиссии за газ и более гибкое управление аккаунтом. В отличие от создания полностью нового кошелька на основе смарт-контракта, EIP-7702 сохраняет существующие адреса кошельков и активы пользователей, изменяя способ выполнения транзакций аккаунтом.

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

Поэтому для понимания EIP-7702 недостаточно сосредоточиться только на возможностях абстракции аккаунтов. Необходимо также анализировать, как вступает в силу авторизация делегирования, какие действия может выполнять вредоносный код и как обычные пользователи могут выявлять и удалять опасные делегирования. В этой статье рассматриваются технические принципы, потенциальные сценарии атак и практики безопасности кошельков, связанные с EIP-7702.

Ключевые моменты

• EIP-7702 — функция аккаунтов, представленная в обновлении Ethereum Pectra. Она позволяет традиционным внешне управляемым аккаунтам (EOA) выполнять логику смарт-контрактов через делегирование без перевода активов на новый адрес.

• Авторизация EIP-7702 отличается от обычного ERC-20 Approve. Первая может изменить логику выполнения аккаунта, тогда как второй обычно предоставляет определённому получателю право использовать заданное количество токенов.

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

• Делегирование EIP-7702 не прекращается автоматически после завершения одной транзакции. Для отзыва или замены делегирования требуется новая действительная авторизация, а очистка делегирования не позволит вернуть уже переведённые активы.

• Оценка безопасности EIP-7702 требует не только проверки источника подписи. Необходимо также понимать разрешения, поведение кода и возможности обновления делегированного контракта.

Что такое EIP-7702? Зачем традиционным EOA-кошелькам нужно делегированное выполнение?

Аккаунты Ethereum в основном делятся на внешне управляемые аккаунты (Externally Owned Accounts, EOA) и аккаунты смарт-контрактов. EOA контролируются приватными ключами и могут инициировать транзакции. Аккаунты смарт-контрактов выполняют операции в соответствии с развернутым кодом и могут поддерживать более сложное управление разрешениями и логику транзакций.

Традиционные EOA имеют простую структуру и широкую совместимость, но их возможности выполнения ограничены. Например, пользователю может потребоваться отдельно подписать несколько транзакций, чтобы завершить набор ончейн-операций, или самостоятельно иметь ETH для оплаты комиссии сети. Кошельки на основе смарт-контрактов могут улучшить эти сценарии, но обычно требуют развертывания нового аккаунта, переноса активов и соблюдения дополнительных требований совместимости.

EIP-7702 предлагает иной подход: он позволяет EOA делегировать выполнение кода аккаунта логике смарт-контракта по указанному адресу с помощью авторизации. Пользователи могут получить доступ к некоторым функциям смарт-аккаунтов со своего существующего адреса кошелька без его изменения.

На уровне протокола EIP-7702 вводит новый тип транзакции и список авторизаций. Подходящая авторизация может установить в поле кода EOA специальный индикатор делегирования, указывающий на определённый адрес контракта. Когда другая транзакция вызывает этот аккаунт, Ethereum выполняет делегированный код в соответствии с применимыми правилами.

Такая конструкция предоставляет продуктам кошельков больше гибкости для поддержки пакетных операций, гибкой валидации транзакций, спонсирования комиссии за газ и управления разрешениями на основе контрактов. Однако EIP-7702 сам по себе не предоставляет все эти возможности автоматически. Конкретные функции по-прежнему зависят от реализации делегированного контракта.

Как работает EIP-7702? Как связаны подпись авторизации и делегированный контракт?

Основная идея EIP-7702 заключается в разделении владения аккаунтом и логики выполнения кода. Пользователи продолжают контролировать свои EOA с помощью существующих приватных ключей, но могут использовать соответствующую протоколу авторизацию, чтобы указать, какой код контракта должен использовать адрес.

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

Типичный процесс делегирования EIP-7702 состоит из четырёх этапов:

1. Выбор цели делегирования: кошелёк или приложение определяет адрес реализации смарт-контракта, который необходимо использовать.

2. Создание подписи авторизации: пользователь подписывает данные авторизации для указанной цели делегирования приватным ключом EOA.

3. Обработка авторизации ончейн: авторизация включается в транзакцию, поддерживающую EIP-7702. После проверки сеть устанавливает индикатор делегирования аккаунта.

4. Выполнение делегированного кода: при последующем вызове аккаунта код указанного контракта реализации выполняется в соответствии с правилами EIP-7702.

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

Адрес цели делегирования не означает, что пользователь передал этому адресу свой приватный ключ. Это также не означает, что владелец этого адреса автоматически получает разрешение переводить активы. Фактический риск зависит от того, как делегированный код обрабатывает валидацию транзакций, точки входа выполнения и контроль доступа. Если код позволяет злоумышленнику выполнять операции с активами без дополнительной авторизации владельца аккаунта, опасное делегирование может стать точкой входа для кражи активов.

Чем EIP-7702 отличается от ERC-20 Approve?

В традиционных DeFi-транзакциях пользователи часто используют ERC-20 Approve, чтобы разрешить децентрализованной бирже или другому смарт-контракту использовать определённый токен. Например, пользователь может разрешить контракту потратить до 100 USDC. Такая авторизация обычно записывается контрактом токена и определяет, какое количество токенов может использовать конкретный получатель разрешения.

EIP-7702 работает на другом уровне авторизации. Он не просто разрешает контракту потратить определённое количество токенов. Вместо этого он определяет, какой код смарт-контракта выполняет аккаунт. Делегированный код может включать валидацию транзакций, переводы активов, пакетные вызовы и другие функции управления аккаунтом, поэтому потенциальная область его влияния может быть шире.

Делегирование EIP-7702 не означает, что право владения кошельком напрямую передаётся контракту. Безопасная реализация делегирования всё ещё может требовать действительную подпись владельца аккаунта и устанавливать лимиты транзакций, временные ограничения и другие защитные меры.

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

Как вредоносная авторизация EIP-7702 может привести к краже активов из кошелька?

Один из основных рисков безопасности EIP-7702 заключается в том, что злоумышленники могут использовать фишинг подписей, чтобы обманом заставить пользователей одобрить вредоносные делегирования. Злоумышленники могут представлять запрос на авторизацию как обновление кошелька, проверку аккаунта, получение вознаграждения или оптимизацию транзакции, создавая у пользователей впечатление, что они подтверждают обычную подпись.

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

Если делегированный код содержит функцию перевода активов, которую может вызвать злоумышленник, он может использовать эту логику выполнения для перевода ETH или других токенов с аккаунта.

Типичный сценарий риска можно описать следующим образом:

1. Склонение к подписи: злоумышленник получает авторизацию пользователя для вредоносной цели делегирования через поддельный сайт или интерфейс приложения.

2. Отправка авторизации: злоумышленник или другой отправитель транзакции отправляет действительную авторизацию в сеть, поддерживающую EIP-7702.

3. Установка делегирования: после проверки авторизации сеть переводит затронутый аккаунт на выполнение указанного кода контракта.

4. Активация вредоносной логики: злоумышленник вызывает уязвимую точку входа выполнения во вредоносном коде.

5. Перевод активов: вредоносная логика выполняет переводы, операции с токенами или другие опасные действия в контексте аккаунта.

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

30 октября 2026 года произошёл крупный инцидент безопасности, связанный с горячими кошельками Binance. Анализ инцидента TRM Labs пришёл к выводу, что злоумышленники использовали делегирование EIP-7702 в сети Ethereum, чтобы подключить соответствующие горячие кошельки к вредоносному исполняемому коду. В нём также были отмечены аномальные переводы средств в других блокчейнах. В различных анализах безопасности по-прежнему содержатся детали о масштабе атаки, способе получения подписей и первоначальном пути проникновения, которые требуют дополнительной проверки.

Этот инцидент показывает, что EIP-7702 может служить инфраструктурой для обычной автоматизации кошельков, но также способен усилить последствия потери контроля над системами авторизации или подписания. Однако он не доказывает, что сам протокол EIP-7702 содержит уязвимость, позволяющую произвольным злоумышленникам обходить проверку подписей.

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

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

Причина в том, что пользователи могут добровольно подписывать авторизации с опасными последствиями. В случае EIP-7702 злоумышленнику не обязательно получать приватный ключ напрямую. Если он сможет склонить пользователя к подписанию действительной авторизации вредоносного делегирования и выполнить условия для ончейн-исполнения, он может получить возможность влиять на последующее поведение аккаунта.

Этот риск похож на традиционный фишинг подписей, но его цель расширяется с одной транзакции или определённого разрешения на токены до логики выполнения аккаунта.

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

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

Для институциональных кошельков политики подписания, списки разрешённых контрактов, многосторонние одобрения и симуляция транзакций также должны охватывать авторизации EIP-7702, а не полагаться только на традиционную проверку сумм переводов.

Прекращается ли делегирование EIP-7702 автоматически? Как проверить и отозвать рискованные авторизации?

Одной из важных характеристик EIP-7702 является то, что состояние делегирования не очищается автоматически после завершения транзакции, которая его устанавливает.

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

На уровне протокола пользователи могут использовать новую действительную авторизацию, чтобы установить целью делегирования нулевой адрес и тем самым очистить индикатор делегирования EIP-7702. При необходимости пользователи также могут повторно авторизовать доверенный контракт реализации.

Для проверки и управления делегированием можно выполнить следующие действия:

1. Проверить статус кода аккаунта: используйте надёжный блокчейн-обозреватель или инструмент безопасности кошелька, чтобы подтвердить наличие делегирования EIP-7702 у адреса.

2. Проверить целевой контракт: убедитесь, что делегирование указывает на тот же контракт реализации, который опубликован используемым продуктом кошелька.

3. Оценить риск контракта: проверьте, проходил ли код аудит, имеет ли он права администратора, может ли он обновляться и позволяет ли третьим лицам выполнять операции с активами.

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

5. Проверить связанные риски: также проверьте разрешения ERC-20, аномальные записи транзакций и статус аккаунта в других сетях.

При запросе кода аккаунта с делегированием EIP-7702 пользователи могут увидеть специальный индикатор, начинающийся с 0xef0100, за которым следует адрес цели делегирования. Это один из способов идентификации на уровне протокола. Однако обычным пользователям не требуется самостоятельно разбирать необработанные шестнадцатеричные данные. Они могут использовать надёжный инструмент, который корректно отображает статус EIP-7702.

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

Чем модель безопасности EIP-7702 отличается от смарт-аккаунтов ERC-4337?

EIP-7702 и ERC-4337 связаны с абстракцией аккаунтов Ethereum, но решают эту задачу разными способами.

ERC-4337 использует такие компоненты, как UserOperation, Bundler и EntryPoint, чтобы предоставить инфраструктуру выполнения транзакций для аккаунтов смарт-контрактов без необходимости для традиционных EOA напрямую инициировать каждую операцию. Правила валидации и выполнения аккаунта реализуются смарт-контрактами.

EIP-7702 в первую очередь решает вопрос о том, как традиционные EOA могут получить возможности выполнения смарт-контрактов. Он позволяет существующим адресам делегировать выполнение кода контракта, снижая барьер для пользователей, желающих использовать функции смарт-аккаунтов.

Эти два подхода не являются полными заменами друг друга. Некоторые архитектуры кошельков могут использовать EIP-7702 для предоставления существующим EOA возможностей выполнения кода, а затем сочетать его с инфраструктурой ERC-4337 для создания более функционального смарт-аккаунта.

С точки зрения безопасности EIP-7702 требует внимания к вредоносным делегированиям и обману при подписании. ERC-4337 требует внимания к логике валидации контрактов аккаунта, модулям выполнения, разрешениям на обновление и связанным инфраструктурным рискам. Фактическая безопасность зависит от конкретной реализации, а не только от выбранного стандарта.

Как обычным пользователям защититься от фишинга подписей EIP-7702?

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

1. Пользователям следует различать подписи транзакций, подписи сообщений, авторизации токенов и делегирования аккаунтов. Если интерфейс кошелька отображает EIP-7702, Delegation, Set Code или аналогичное уведомление, убедитесь, что операция действительно требует изменения логики выполнения аккаунта.

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

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

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

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

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

Что EIP-7702 означает для будущего безопасности кошельков и абстракции аккаунтов?

EIP-7702 переводит аккаунты Ethereum от относительно фиксированной модели выполнения EOA к более гибким программируемым аккаунтам. Для разработчиков кошельков это означает возможность предоставлять пакетные транзакции, спонсирование комиссии за газ, управление разрешениями и автоматизированное выполнение при сохранении существующих адресов.

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

С точки зрения проектирования продукта практики безопасности EIP-7702 могут развиваться в трёх направлениях.

• Прозрачность авторизации. Кошельки должны помогать пользователям понимать, что изменит делегирование, а не просто отображать адрес контракта.

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

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

Значение EIP-7702 заключается не только в улучшении работы с кошельками, но и в расширении безопасности аккаунтов за пределы традиционной защиты приватных ключей до комплексного управления намерениями при подписании, выполнением кода и постоянными разрешениями.

Итоги

EIP-7702 предоставляет традиционным EOA Ethereum возможности делегирования смарт-контрактов, позволяя пользователям получать доступ к более гибким функциям выполнения аккаунта при сохранении существующих адресов кошельков. Этот механизм создаёт новую техническую основу для абстракции аккаунтов, но также меняет границы безопасности традиционных кошельков.

В отличие от ERC-20 Approve, который главным образом контролирует разрешения на расходование токенов, авторизация EIP-7702 может изменить код контракта, выполняемый аккаунтом. Если пользователь подпишет вредоносное делегирование, злоумышленник может использовать небезопасную логику выполнения для перевода активов, не обязательно получая приватный ключ пользователя напрямую.

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

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

Что такое EIP-7702?

EIP-7702 — улучшение протокола Ethereum, которое позволяет традиционным EOA делегировать выполнение кода смарт-контрактов через авторизацию, предоставляя некоторые функции смарт-аккаунтов.

Может ли EIP-7702 автоматически вывести все активы из кошелька?

Нет. EIP-7702 сам по себе не является функцией, которая автоматически похищает активы. Основные риски связаны с вредоносными авторизациями, небезопасным делегированным кодом или скомпрометированными системами подписания.

Совпадает ли авторизация EIP-7702 с ERC-20 Approve?

Нет. ERC-20 Approve обычно предоставляет конкретному адресу разрешение на использование токенов, тогда как авторизация EIP-7702 указывает код контракта, выполняемый аккаунтом. Уровни разрешений различаются.

Можно ли отозвать делегирование EIP-7702?

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

Может ли аппаратный кошелёк предотвратить фишинг EIP-7702?

Не полностью. Аппаратный кошелёк помогает защитить приватный ключ, но пользователь всё равно может столкнуться с риском для активов, если подтвердит вредоносную авторизацию на устройстве.

Как узнать, есть ли у кошелька делегирование EIP-7702?

Можно использовать блокчейн-обозреватель или инструмент безопасности, поддерживающий EIP-7702, чтобы проверить код аккаунта и цель делегирования. Если вы обнаружили незнакомый адрес делегирования, проверьте его источник и разрешения.