EIP-7702 позволяет обычному Ethereum-аккаунту, управляемому приватным ключом, делегировать выполнение уже развёрнутому смарт-контрактному коду. Адрес, баланс и история сохраняются, но при обращении к аккаунту EVM может исполнять логику указанного контракта в контексте этого адреса. Так EOA получает batching, sponsorship, сессионные ключи и другие свойства smart account без переноса активов на новый адрес.
Стандарт вошёл в Ethereum вместе с Pectra 7 мая 2025 года и действует в mainnet. Это не автоматическое обновление всех кошельков: делегацию должен поддержать конкретный wallet, а функции определяет выбранный контракт. EIP-7702 создаёт механизм, но не гарантирует безопасную реализацию.
EOA и contract account до EIP-7702
Externally owned account управляется парой ключей. Он может инициировать транзакции, хранить ETH и токены, но не содержит программируемой логики. Contract account, напротив, исполняет код, однако сам по себе не подписывает обычную транзакцию приватным ключом.
Smart account обычно строится как контрактный кошелёк. Он способен проверять несколько ключей, объединять вызовы и задавать лимиты, но пользователь получает новый адрес и должен переместить активы. Архитектура Account Abstraction решает часть UX-проблем через ERC-4337, bundlers и EntryPoint. EIP-7702 добавляет путь для существующего EOA.
Что записывается в аккаунт
EIP-7702 вводит транзакцию типа 4, SetCode. Она содержит authorization list. Каждая авторизация связывает chainId, адрес делегированного кода и nonce с подписью владельца EOA. После проверки протокол записывает в поле кода аккаунта специальный delegation indicator: короткий префикс и указатель на адрес реализации.
В аккаунт не копируется весь байткод. Индикатор сообщает EVM, где найти исполняемый код. При вызове логика берётся по адресу делегата, но выполняется в контексте EOA: с его адресом, балансом и storage. Поэтому делегированный код получает доступ к возможностям аккаунта и становится критической границей безопасности.
Указатель может быть заменён новой авторизацией. Делегация на нулевой адрес очищает индикатор. Отмена не стирает уже совершённые переводы, approvals и изменения storage.
Кто отправляет SetCode-транзакцию
Внешнюю транзакцию может оплатить не тот же аккаунт, чья авторизация находится в списке. Это позволяет relayer или приложению включить подписанное разрешение и оплатить gas. Один SetCode может обработать несколько authorization tuples, если каждая проходит проверку chainId, nonce и подписи.
Авторизация обрабатывается до основной части исполнения. Важная деталь протокола – успешно установленная делегация не откатывается только потому, что последующий вызов транзакции завершился revert. Пользователь не должен считать неуспешную бизнес-операцию доказательством отсутствия делегации.
Какие функции появляются
Batching. Кошелёк может выполнить несколько вызовов атомарно, например approve и swap. Пользователь подтверждает один сценарий, а код проверяет и исполняет пакет.
Gas sponsorship. Paymaster или иной спонсор может оплатить gas, а приложение – принять комиссию в токене. Конкретные условия задаёт инфраструктура, а не EIP-7702.
Сессионные ключи. Основной ключ разрешает временному ключу ограниченный набор методов, контрактов, сумм и срок. Это удобно для игр и частых действий, но безопасность зависит от корректности ограничений. Принцип подробно разобран в материале о сессионных ключах.
Recovery и дополнительные валидаторы. Делегированный контракт может проверять passkey, несколько подписей или правила восстановления. Но основной приватный ключ EOA остаётся высшим уровнем контроля и способен действовать напрямую. Делегация на multisig-код сама по себе не превращает старый одиночный ключ в настоящий multisig. Для сравнения полезна архитектура контрактных аккаунтов Safe, где правила задаются самим кошельком.
Связь с ERC-4337 и интерфейсами кошельков
EIP-7702 не заменяет ERC-4337. Делегированный EOA может использовать совместимую логику и участвовать в UserOperation через EntryPoint. ERC-4337 описывает альтернативный путь доставки и проверки операций, а EIP-7702 – протокольный способ связать существующий адрес с кодом.
Приложению не следует просить пользователя подписать произвольную низкоуровневую делегацию. Официальные рекомендации предлагают обращаться к возможностям кошелька через стандартизированные интерфейсы, например запрашивать пакет вызовов. Кошелёк сам выбирает реализацию, которую он проверил и разрешил.
Почему приватный ключ остаётся главным
После делегации EOA продолжает инициировать транзакции. Владелец исходного ключа может заменить или удалить указатель. Это облегчает совместимость и не требует менять адрес, однако ограничивает recovery: если основной ключ украден, злоумышленник может обойти правила дополнительного валидатора или переназначить делегацию.
Поэтому маркетинговое утверждение «обычный кошелёк стал multisig» требует проверки. Настоящая модель зависит от того, способен ли старый ключ самостоятельно вывести активы, сменить код или отменить защиту. EIP-7702 по умолчанию не отбирает у него эти полномочия.
Главный риск – адрес делегированного кода
Авторизация EIP-7702 не похожа на обычный allowance для одного токена. Делегированный код может совершать вызовы от имени аккаунта, управлять approvals, переводами и взаимодействиями с приложениями. Ошибка или вредоносная логика угрожает всем совместимым активам на адресе.
Пользователь не способен безопасно оценить произвольный байткод по одному адресу. Поэтому кошельки используют списки известных реализаций, аудит, симуляцию и собственные политики. Даже аудит не исключает ошибку, а proxy добавляет риск того, что реализация изменится позже.
Proxy и обновляемость
Делегация может указывать прямо на реализацию или на proxy. Прямой адрес проще анализировать, но для обновления потребуется новая авторизация. Proxy позволяет менять логику без повторной делегации, зато пользователь зависит от администратора и правил upgrade.
Если ключ обновления скомпрометирован, безопасный сегодня делегат может получить вредоносную реализацию завтра. Проверять нужно не только текущий код, но и owner, timelock, multisig, возможность pause и процесс обновления.
Риски для приложений
После EIP-7702 наличие кода по адресу больше не означает, что аккаунт изначально был contract wallet. Разработчикам нельзя строить безопасность на простом различии EOA и contract по размеру кода. Проверки через tx.origin также требуют пересмотра: делегированный EOA может выполнять несколько вложенных действий и нарушать старые предположения о верхнем уровне вызова.
Контракт должен явно проверять полномочия и защищаться от reentrancy, flash-loan сценариев и повторного исполнения, а не полагаться на тип отправителя. Эти изменения касаются разработчиков даже тогда, когда их приложение само не предлагает EIP-7702.
Как пользователю распознать делегацию
Кошелёк должен ясно показать, что запрос меняет исполняемую логику аккаунта, и назвать проверенную реализацию. Обычный сайт не должен требовать вставить адрес неизвестного delegator contract. Если интерфейс называет действие «активацией бонуса», «проверкой кошелька» или «подключением», но фактически просит authorization EIP-7702, запрос нужно отклонить.
Подпись typed data и делегация кода – разные механизмы, хотя оба могут выглядеть как подтверждение в кошельке. Перед любой структурированной подписью полезен отдельный контроль EIP-712 полей. Нельзя ориентироваться только на отсутствие gas или на знакомый логотип сайта.
Как снять делегацию
- Откройте функцию управления аккаунтом в кошельке, который установил делегацию.
- Проверьте текущий адрес делегата, сеть и ожидаемую операцию очистки.
- Создайте авторизацию на нулевой адрес или используйте штатную команду revoke, если кошелёк реализует её корректно.
- Дождитесь включения SetCode-транзакции и снова проверьте code аккаунта.
- Отдельно отзовите опасные token approvals, session keys и разрешения, созданные прежним кодом.
Если основной ключ скомпрометирован, простая отмена может превратиться в гонку со злоумышленником. В такой ситуации безопаснее действовать по плану аварийного переноса, а не многократно отправлять gas на атакуемый адрес.
Основные риски
- Вредоносный делегат. Код получает широкую возможность действовать от имени EOA.
- Ошибка реализации. Баг проверки подписи, nonce или пакетного вызова может привести к потере средств.
- Proxy upgrade. Администратор способен изменить поведение уже одобренного адреса.
- Компрометация ключа EOA. Старый ключ сохраняет окончательный контроль и может обойти дополнительные правила.
- Phishing. Безобидное описание может скрывать авторизацию делегации.
- Неатомарные ожидания. Revert основной операции не обязательно отменяет уже обработанный authorization tuple.
- Несовместимость приложений. Старые контракты могут неверно трактовать делегированный EOA и
tx.origin. - Инфраструктурная зависимость. Bundler, paymaster и relayer способны быть недоступны, хотя хороший аккаунт должен сохранять независимый путь исполнения.
Итог
EIP-7702 сохраняет адрес EOA и добавляет к нему указатель на исполняемый код. Это позволяет кошелькам внедрять batching, sponsorship, recovery и временные полномочия без миграции активов. Одновременно делегированный контракт становится частью защиты всего аккаунта, а исходный приватный ключ сохраняет высший контроль. Использовать механизм безопасно можно только через кошелёк, который проверяет реализацию, ясно показывает делегацию и даёт понятный способ её отменить.
