Задача. Исторически пользователи Ethereum контролируют средства через EOA (адреса с приватным ключом). У таких адресов базовые возможности: отправить ETH, подписать вызов, выдать approve. Всё «умное» реализуется через смарт-кошельки (контракты), но это новые адреса, миграции и иные UX-трудности.
Идея EIP-7702. Добавить EOAs «умные» возможности без смены адреса: владелец EOA подписывает разрешение (authorization), и ровно на время одной транзакции его адрес ведёт себя как смарт-аккаунт — исполняет заложенную логику (батч-вызовы, лимиты, social recovery, спонсируемый газ и т. п.). После завершения tx адрес снова «обычный» EOA.
*Ключевой принцип:* делегация временная и явная, по подписи владельца. Это даёт 3074-подобный UX, но подходит к дорожной карте account abstraction и дружит с экосистемой роллапов, MEV-инфраструктуры и ERC-4337.
Как EIP-7702 работает (простыми словами)
- Вводится новый тип транзакции (в спецификации его обычно обозначают как type 0x04), который помимо обычных полей несёт список авторизаций от EOAs.
- Авторизация описывает: какой код (или адрес реализации кода) временно связывается с данным EOA, для какого цепочечного контекста (chain id), с каким сроком/окном и какой nonce/объёмом допустимых действий.
- Во время исполнения такой tx код «подсаживается» к аккаунту EOA, и вызовы исполняются как если бы EOA был контрактом.
- По завершении tx связка сбрасывается: EOA снова пустой (без кода). Долговременной «прививки» нет.
Что это даёт в UX:
- Батч-операции (несколько действий за один клик): своп → approve → мост → деплой — без смены адреса.
- Сессионные ключи: выдаём ключ с ограничениями (лимит суммы, список dApp, TTL).
- Газ-спонсорство: платит спонсор/кошелёк по политике (аналог Paymaster).
- Политики расходования: дневные лимиты, «белые списки» получателей.
- Recovery-механики: социальное восстановление без миграции на новый адрес.
Чем EIP-7702 отличается от EIP-3074
EIP-3074 предлагал опкоды AUTH/AUTHCALL: EOA «уполномочивает» invoker-контракт, а тот делает вызовы «от лица» EOA. Это открывало батчи и спонсорство, но рождало риски: долговременные делегаты, «липкие» полномочия, трудности миграции к полной AA.
EIP-7702 переносит идею в тип транзакции:
- Делегация пер-транзакционная (временная), без «вечно доверенных» invoker’ов.
- Лучше вписывается в архитектуру AA/4337: те же паттерны (батчи, paymaster), но без обязательной смены адреса пользователя.
- Нет новых опкодов в EVM — меньше инвазивных изменений виртуальной машины; логика — в верификации транзакции и исполнении.
Плюсы 7702 по сравнению с 3074
- Контроль и отзывчивость: авторизация действует только «здесь и сейчас».
- Совместимость с дорожной картой account abstraction (ниже сравнение с ERC-4337).
- Упрощённый анализ рисков: нет перманентных «привязок» к invoker.
Минусы/ограничения
- Контрактную логику всё равно нужно писать/аудировать.
- Для некоторых кейсов 3074 (с упором на «постоянного управляющего») придётся переосмыслить архитектуру.
ERC-4337 и EIP-7702: конкуренты или союзники?
ERC-4337 — способ дать AA без изменений протокола: «альт-мемпул» с UserOperation, контракт-EntryPoint, bundler и paymaster. Почти весь «умный» UX возможен уже сейчас, но большинство пользователей сидят на EOAs, а миграция в смарт-кошельки требует новых адресов и деплоев.
EIP-7702 дополняет 4337:
- Адрес сохраняется. Пользователь остаётся на своём EOA, но получает AA-возможности «на время tx».
- Инфраструктура совместима. Те же паттерны (батчинг, спонсорство, сессионные ключи) можно реализовывать без EntryPoint/альт-мемпула — либо вместе с 4337 (например, 7702-авторизация, а далее взаимодействие с Paymaster).
- Миграционный путь. Кошельки могут постепенно «включать смарт-режим» EOA, не вынуждая пользователя менять адрес; при желании затем перейти к «полной» смарт-модели 4337.
Итого: 4337 — экосистема и инструменты, 7702 — протокольный мостик к «умным» возможностям EOA. Они совместимы и усиливают друг друга.
Что можно строить поверх EIP-7702 (паттерны)
- Batch/Multicall кошелька. Один подписиный пакет инициирует последовательность действий: approve → swap → bridge → stake с проверками инвариантов (минимальный получаемый объём, дедлайны).
- Сессионные ключи и разрешения. Владелец выдаёт временный ключ для конкретного dApp: лимит токена X, TTL 30 мин, запрет на transfer вне белого списка.
- Мета-транзакции и спонсорство. DApp оплачивает газ пользователя по бизнес-правилам (анти-спам депозиты, allow-list, KYC-гейты там, где это требуется локальными законами).
- Политики безопасности. «Ежедневные лимиты», «двухфакторный вывод» (подтверждение вторым ключом или задержка), «заморозка» при аномалиях.
- Социальное восстановление. Мультисиг-стражи подтверждают «смену владельца» адреса при утрате ключа — без перевыпуска адреса.
Безопасность: где риски и как их снижать
Уровень пользователя
- Фишинг «подтверди авторизацию 7702». Всегда читайте, какой код и какие лимиты/TTL подписываете.
- Сессионные ключи: ограничивайте область действия (список методов, токенов, максимумов).
- Храните «мастер-ключ» оффлайн; давайте dApp только ограниченные сессии.
Уровень разработчика кошелька/dApp
- Аудит исполняемого кода (политик/модулей). Предпочтительны переиспользуемые шаблоны, а не одноразовые «самописные» политики.
- Доменная привязка и EIP-712-подписи: авторизация должна явно фиксировать chain id, TTL, nonces, список методов/ресурсов.
- Fail-safe: если что-то пошло не так — транзакция должна атомарно откатываться; предусмотреть «чёрный список» утёкших сессионных ключей.
- Логи и симуляция (dry-run) перед отправкой: показывайте пользователю итоговые изменения балансов и вероятные риски.
Уровень протокола/рынка
- Диверсификация клиентов, тесты межоперабельности.
- Мониторинг экосистемных шаблонов (стандарты модулей, как у Permit2, Safe Modules и пр.) и быстрые апдейты в случае обнаруженных уязвимостей.
Сравнение: EIP-7702 vs EIP-3074 vs ERC-4337
| Критерий | EIP-7702 | EIP-3074 | ERC-4337 |
|---|---|---|---|
| Что меняем | Новый тип tx (пер-tx авторизация); без новых опкодов | Два новых опкода EVM (AUTH, AUTHCALL) | Ничего в протоколе (альт-мемпул + EntryPoint контракт) |
| Адрес пользователя | Тот же EOA | Тот же EOA | Обычно новый адрес смарт-аккаунта |
| Длительность делегации | Только на один tx | Может быть долгоживущей (invoker) | Зависит от логики аккаунта (контракта) |
| Батчи / мультивызовы | Да (через код-политику) | Да | Да (через аккаунт-контракт) |
| Газ-спонсорство | Да (политики/пэймастеры) | Да | Да (Paymaster 4337) |
| Совместимость с AA-дорожной картой | Высокая (мост к «умным» EOA и 4337) | Ниже (миграция и безопасность invoker) | Собственная экосистема AA |
| Главный риск | Подписать «не тот» код/лимит; баг в модуле | Липкие/широкие полномочия invoker | Ошибки в EntryPoint/аккаунте, opsec bundler/paymaster |
| Где уместно | «Умный EOA без смены адреса» + постепенная AA | Низкоуровневые сценарии с постоянным менеджером | Полноценные смарт-кошельки и богатые политики по умолчанию |
Влияние на экосистему
Кошельки. Можно не менять адрес и постепенно включать «смарт-режим» (батчи, сессии, спонсорство). Это снижает отток пользователей при миграции в AA.
DApp/DeFi. Проще реализовать однокликовые флоу без дополнительных разрешений и «залипших апрувов». Появляется стандартная форма авторизации, которую легко симулировать и проверять.
Инфраструктура. Провайдерам газ-спонсорства (paymasters), бандлерам и релейерам открывается рынок «7702-операций»; при этом они могут использовать наработки 4337 или работать без EntryPoint, если бизнес-логика проще.
L2/роллапам. Улучшается UX поверх дешёвых сетей: меньше «размазанных» апрувов, больше атомарности (особенно в комбинации с shared-sequencer и предподтверждениями — см. Shared Sequencers).
Практические рекомендации (для команд)
- Кошельки: внедряйте понятные подсказки о том, какой код и на сколько пользователь делегирует; показывайте итоговые изменения активов (до/после).
- Разработчики модулей: публикуйте версированные реализации политик (лимиты, списки, recovery), проходите аудит, поддерживайте каталог «одобренных» модулей.
- DApp: предлагайте «сессионные ключи» с узкими правами и TTL; храните минимум, отзывать по событию.
- Инфраструктура: готовьте релейеры/пэймастеры, лимитируйте ставки/объёмы, внедряйте анти-спам депозиты и квоты.
- Безопасность: EIP-712-домены, строгие nonces, симуляция; мониторите аномалии (частые мелкие списания, повторяющиеся адреса-получатели).
Частые вопросы (FAQ)
Нужно ли деплоить контракт-кошелёк, чтобы получить «умные» функции? Нет. По 7702 EOA может получить «умные» возможности на время одной транзакции. Контракт всё равно исполняется — но как временная логика, не как постоянный новый адрес пользователя.
Это заменит ERC-4337? Нет. 4337 остаётся полноценной моделью смарт-аккаунтов, полезной для богатых политик «по умолчанию». 7702 — мост для EOA и совместимый компаньон 4337.
Чем 7702 безопаснее 3074? Главное — временная делегация и отсутствие долгоживущих invoker-контрактов с широкими полномочиями. Пользователь каждый раз явно подтверждает «какой код и на что».
Можно ли оплачивать газ токенами? Да, через политику спонсорства/пэймастер (в 4337-стиле) или иным соглашением с релейером — детали зависят от реализации вашего модуля.
А если авторизованный код содержит баг? Ровно как и со смарт-контрактами: нужен аудит, версии модулей и «красная кнопка» (ограничения/отзыв/тайм-локи) на стороне кошелька.