EIP-7702: даём вашему EOA суперспособности на месте
Абстракция аккаунта (4337) создала смарт-аккаунты — но чтобы ими пользоваться, приходилось переезжать на новый адрес. EIP-7702 обновляет ваш существующий EOA прямо на месте: вы подписываете делегирование, ваш аккаунт указывает на контракт, и вызов выполняет код этого контракта от вашего имени — тот же адрес, тот же ключ.
- EOA против контрактов
- абстракция аккаунта (4337)
EIP-4337 дал Ethereum смарт-аккаунты — программируемую валидацию, батчинг, спонсируемый газ — но с оговоркой: смарт-аккаунт — это контракт на новом адресе. Чтобы им воспользоваться, приходится мигрировать: переносить средства, заново выстраивать идентичность и отказываться от адреса (и ключа), по которому вас все знают. Сотни миллионов обычных EOA, которыми на практике пользуется почти каждый, остались за бортом. EIP-7702 (вошёл в Pectra, 2025) исправляет это, позволяя EOA временно стать смарт-аккаунтом, сохранив свой адрес и ключ. Идея — всего одна маленькая мысль; давайте выведем её.
Проблема: 4337 оставляет ваш EOA позади
Смарт-аккаунт 4337 — это контракт, развёрнутый на собственном адресе. Поэтому, чтобы получить его возможности, вы переезжаете: отправляете активы на новый аккаунт, переключаете все интеграции и живёте за другим адресом. Ваш EOA Externally-owned account — обычный аккаунт, порождённый закрытым ключом. Он может инициировать транзакции, но его правила фиксированы: одна подпись ECDSA, газ только в ETH, одно действие. , со всей своей историей и ключом, который все узнают, остаётся позади — и по-прежнему жёстким.
Эта миграция — трение, которого почти никто не хочет. И заметьте единственное различие между вашим EOA и смарт-аккаунтом: у смарт-аккаунта есть код, а у EOA — нет. Так что вопрос напрашивается сам.
→ Шаг 2: указываем EOA на контракт.
Подписываем делегирование; код становится указателем
Добавляем новый тип транзакции, 0x04, который несёт список авторизаций: подписанные тройки (chainId, delegate_address, nonce). Собственный ключ EOA подписывает одну из них — «установить мой код как делегирование этому контракту» — и когда она применяется, поле кода аккаунта устанавливается в крошечный указатель делегирования (delegation designator) 23-байтовое значение 0xef0100 ++ address, которое EIP-7702 записывает в поле кода EOA. Это не байткод контракта — это указатель, говорящий EVM выполнять код этого контракта в контексте данного аккаунта. : 0xef0100 ++ delegate_address. Важно, что это перенаправление, а не копия — EOA не хранит байткод контракта, только 23-байтовый указатель на него.
→ Шаг 3: выполняем код, на который он указывает.
Выполняем код делегата — в собственном контексте EOA
Вот и развязка. Всякий раз, когда аккаунт вызывается (или выступает отправителем транзакции), EVM видит designator 0xef0100, следует по нему, загружает код контракта-делегата и выполняет его — но в контексте EOA: хранилище EOA, баланс EOA, адрес EOA. Внутри этого кода address(this) — это и есть 0xВы. Как будто ваш аккаунт одолжил поведение контракта, оставаясь при этом полностью собой.
Так что одна реализация контракта может обслуживать сколько угодно EOA, делегирующих ей, и каждый из них выполняет эту логику над своим собственным состоянием. Теперь аккаунт программируем, ни разу никуда не переехав.
→ Шаг 4: суперспособности — и оговорка.
Что вы получаете — на адресе, который у вас уже есть
Ваш существующий аккаунт теперь может делать то же, что и смарт-аккаунт, не отказываясь от вашего ключа: батчить approve и swap в один атомарный вызов; быть спонсируемым, когда релеер отправляет транзакцию типа 0x04 и платит за газ (даже за самую первую транзакцию вашего аккаунта); использовать сессионные ключи и ограниченные разрешения; и подключаться напрямую к экосистеме 4337, делегируя реализации аккаунта в стиле 4337.