ERC-7579 — это стандарт интерфейсов для модульных смарт-аккаунтов в экосистеме Ethereum и совместимых L2. Его цель — сделать аккаунт компонуемым: ядро остаётся тонким, а функциональность подключается через модули (подписи, лимиты, батчи, сессионные ключи, 2FA, social recovery, автоматизация и т. п.). Стандарт задуман как совместимый с ERC-4337 (AA) и дополняющий EIP-7702.
Ключевые свойства:
- Минимализм ядра. Базовый аккаунт знает только, как устанавливать/удалять модули и как делегировать им валидацию/исполнение.
- Типизация модулей. Единые категории (валидаторы, исполнители, хуки, фоллбек-таргеты) и ожидаемые точки входа.
- Без привязки к одному UX. Можно собрать кошелёк «под задачу» — от простого 1/1 до продвинутого с лимитами, сессиями, MPC/Passkeys.
- Совместимость с инфраструктурой. Бандлеры/пэймастеры 4337 продолжают работать; 7702 может включать «умный режим» EOA на один шаг.
Зачем нужен модульный стандарт
Монолитные «смарт-кошельки» сложно обновлять: любая новая функция требует форка логики аккаунта или миграции адреса. Модульность решает это:
- Плагины вместо форков. Подключаем нужный модуль — без смены адреса.
- Безопасность через изоляцию. Ошибочный модуль можно отключить, не ломая остальное.
- Инновации без координации. Разработчики публикуют модули (подписи, политики, интеграции) по единым интерфейсам, а кошельки их комбинируют.
Модель ERC-7579 на пальцах
Аккаунт — тонкое ядро c «менеджером модулей». Модуль — контракт, реализующий один из типов поведения. Роутинг — аккаунт делегирует модулю нужный этап: проверку подписи, выполнение, хуки до/после и фоллбек-вызовы.
| Роль | Что делает | Примеры |
|---|---|---|
| Validator (валидатор) | Подтверждает авторизацию/подпись, решает «кто владелец» и при каких условиях | EOA-подпись (ECDSA), мультисиг, пороговые схемы, MPC/Passkeys, сессионный ключ, 2FA/гардианы |
| Executor (исполнитель) | Делает вызовы от имени аккаунта: одиночные/батчи, ограниченные операции | multicall, лимиты расходов, оплата газом токеном, «спящие» ордера, автоматизация |
| Hook (хуки) | Код, вызываемый до/после исполнения для политик и логирования | «Ежедневный лимит», белые/чёрные списки, анти-фишинг, KYT/скоринг, задержки вывода |
| Fallback/Target | Обрабатывает вызовы, не перехваченные другими маршрутами | Совместимость с DApp-API, прокси к специфическому интерфейсу |
В большинстве реализаций валидатор выбирается для валидации (в т. ч. validateUserOp из 4337 или isValidSignature по EIP-1271), а исполнитель — для execute/executeBatch.
Базовые интерфейсы (упрощённо)
Ниже сокращённый вид типичных методов ядра; конкретные сигнатуры могут отличаться у реализаций 7579, но идеи одни и те же.
installModule(moduleType, moduleAddress, initData) → moduleId uninstallModule(moduleType, moduleAddress, deinitData) isModuleInstalled(moduleType, moduleAddress) → bool
validateUserOp(userOp, userOpHash, missingFunds) → validationData execute(target, value, calldata) executeBatch(targets[], values[], calldatas[]) supportsModule(moduleType) → bool
У модулей, в свою очередь, есть точки входа:
onInstall(initData) инициализация, установка прав/слотов onUninstall(data) зачистка isValidSignature(hash, signature) → magicValue для валидаторов (EIP-1271) preExecute(ctx) / postExecute(ctx) для хуков
Идея: ядро — «менеджер + маршрутизатор», всё остальное — в модулях.
Жизненный цикл модуля
1) Установка. Владелец (через текущий валидатор) вызывает installModule(...), модуль сохраняет состояние и публикует события. 2) Активация. С этого момента аккаунт может делегировать модулю нужный этап. Допустим, новый валидатор делает EOA-подписи ненужными. 3) Откат/удаление. uninstallModule(...) отключает функциональность и чистит слоты. Хорошая практика — timelock и «заморозка» на критичных операциях. 4) Обновление. Ставим новую версию параллельно, переключаем роутинг, затем удаляем старую.
*Совет:* храните реестр разрешённых модулей (адреса/хэши), подписывайте установки оффлайн-ключом «хозяина» и показывайте пользователю читаемые разрешения.
Совместимость с ERC-4337 и EIP-7702
* ERC-4337. Аккаунт 7579 реализует validateUserOp и может использовать 4337-инфраструктуру (bundler, EntryPoint, Paymaster). Валидатор-модуль берёт на себя проверку UserOperation, исполнитель — делает батч-вызовы. * EIP-7702. Если пользователь остаётся на EOA, 7702 позволяет на один tx подцепить «модуль-политику» (батч, лимит, спонсорство) — мягкий мост к AA. Постоянный «смарт-режим» и богатые политики удобнее оформить как аккаунт 7579.
Сравнение подходов
| Критерий | ERC-7579 (модульный) | ERC-6900 (модульный, «плагины») | ERC-4337 (AA-модель) | EIP-7702 (умный EOA на 1 tx) |
|---|---|---|---|---|
| Что стандартизует | Роли модулей и точки входа в аккаунт | Богатая иерархия «плагинов» и разрешений | Протокол отправки UserOperation | Тип tx с одноразовой авторизацией |
| Адрес пользователя | Смарт-аккаунт | Смарт-аккаунт | Смарт-аккаунт | EOA |
| Модульность | Высокая, тонкое ядро | Высокая, но толще металл | Зависит от реализации аккаунта | Временные политики, без постоянных модулей |
| Совместимость | Дружит с 4337/7702 | Дружит с 4337 | База для AA | Мост к AA, совместим с 4337-паттернами |
| Где уместно | Конструктор кошельков/SDK | Единый «маркет» плагинов с богатыми разрешениями | Инфраструктура AA | Лёгкие сценарии без смены адреса |
Идеологически 6900 и 7579 близки (оба — про модульность). 7579 делает акцент на минимализме ядра и газ-экономии, оставляя «богатые реестры/маркетплейсы» на уровень экосистем.
Примеры модулей и сценариев
1) Подписи и доступ
- Валидатор Passkey/WebAuthn: подписи через платформенный аутентификатор.
- Мультисиг/гардианы: N-из-M, социальное восстановление, задержка вывода.
- Сессионные ключи: ограниченные по времени/лимитам/целям.
2) Исполнение
- Multicall/Batch: «approve → swap → bridge → stake» атомарно.
- Платёж токеном: оплатить газом ERC-20 через встроенный пэймастер.
- Отложенные/кипер-задания: автоматический ребаланс, DCA, автоклейм.
3) Политики (хуки)
- Ежедневные лимиты и белые списки получателей.
- Анти-фишинг: отображение человеко-читаемого плана действий, запрет «непонятных» call-data.
- KYT/комплаенс: внешние сигналы-флаги → блокировка/таймлок.
4) Фоллбек-интеграции
- Совместимость с нестандартными DApp-API.
- Проксирование permit2/подписи по ERC-1271 для DeFi.
Безопасность: чек-лист для команд
- Модульный реестр. Держите allow-list «доверенных» модулей (адрес/версии/хэши), показывайте пользователю издателя и аудит.
- Разрешения в человеко-читаемом виде. До установки отобразите: «может тратить до X, вызывать Y, TTL Z».
- Timelock/guardian-переключатели. Для критичных операций — задержка и возможность «стоп-кран» до вступления в силу.
- Изоляция состояния. Каждый модуль — свои слоты; запрет на прямой доступ к чужим; аккуратный delegatecall (или его отсутствие).
- Экономика газа. Batch и хуки — не бесплатно. Следите за лимитами 4337-пэймастера/бандлера и «горячими местами» по газу.
- Журналы событий и отладка. Единый формат событий установки/снятия модуля, pre/post-хуков и отказов.
- Планы отката. Возможность аварийно вернуть «базовый валидатор», если новый модуль ведёт себя некорректно.
- Диверсификация клиентов. Тестируйте с несколькими EL/CL и на L2 — различия в газе и опкодах могут влиять на UX.
Паттерны проектирования модулей
- Validator-first. Начинайте с модели владения: EOA-подпись, мультисиг, Passkeys, MPC — и уже под неё навешивайте исполнители/хуки.
- Stateless-по-возможности. Меньше состояния → проще обновления и аудиты. Критичные параметры храните в аккаунте, а не в модуле.
- Scopes для сессионных ключей. Ограничивайте *методы/контракты/суммы/TTL*. Храните «счётчик сессии» (nonce) и отзыв.
- Fail-closed. При сомнениях — отклонять. Pre-hook не смог подтвердить правило → revert.
- Версионирование. Семантические версии модулей, миграции «A→B→C» с проверкой инвариантов и событиями.
- Оптимизация маршрутизации. Частые пути — отдельные селекторы без лишней диспетчеризации.
Интероп и экосистема
- Бандлеры/пэймастеры из 4337 работают как есть: модуль-валидатор реализует validateUserOp, исполнитель — execute.
- Аггрегаторы подписей. Для Passkeys/MPC используйте агрегаторы (off-chain/он-чейн) — модуль валидатора может принимать *пакеты* доказательств.
- Маркет модулей. Реестры (on/off-chain каталоги) упрощают поиск и обновления, но не являются частью стандарта — это «надстройка» экосистемы.
- L2/роллапы. Модули одинаково полезны в дешёвых сетях: именно там востребованы batch/автоматизация/сессии.
Риски и граничные случаи
- Supply-chain риск модулей. Популярный модуль с бэкдором затрагивает множество аккаунтов. Помогают open-source, аудит, allow-list и «мягкие включения» через timelock.
- Реэнтранси и хуки. Pre/post-хуки — новые поверхности для ошибок. Используйте проверенные шаблоны, разделяйте состояние и избегайте «взаимных вызовов».
- Злоупотребление сессионными ключами. Ограничивайте TTL/лимиты и давайте лёгкий отзыв в UI.
- Совместимость DeFi. Некоторые протоколы ожидают EOA-подписи; обеспечьте ERC-1271 и понятную симуляцию.
FAQ
Это «замена» ERC-4337? Нет. 4337 — транспорт/механика AA. 7579 — как устроить аккаунт внутри, чтобы он был расширяемым. Они комплементарны.
Чем 7579 отличается от 6900? Оба — про модульность. 6900 детальнее стандартизует «плагины и разрешения». 7579 делает упор на минимализм ядра и газ-эффективность, оставляя «рынок плагинов» экосистеме.
Могу ли я остаться на EOA и получить часть функций? Да — через EIP-7702 (разрешение «на один tx»). Для постоянных политик и богатых модулей переход к аккаунту 7579 удобнее.
Насколько это безопасно? Как и любой смарт-контракт: безопасность = дизайн прав + аудит модулей + прозрачный UX. Преимущество 7579 — можно отключать модуль и обновляться без миграции адреса.
А если модуль «умрёт»? Держите аварийный валидатор/гардианов и uninstall c timelock. Хорошая практика — «freeze-кнопка» у владельца/совета хранителей.
Чек-лист внедрения (коротко)
- Определите модель владения (валидатор) и UX-паттерны (batch, сессии, лимиты).
- Выберите ядро 7579 и подготовьте allow-list модулей (адреса/версии/аудиты).
- Реализуйте видимые разрешения в кошельке: человеко-читаемая карточка модуля.
- Добавьте timelock/guardian на установку/удаление критичных модулей.
- Интегрируйте 4337 (bundler, paymaster) и симуляцию операции.
- Тестируйте на L2/тестнетах: газ, отказоустойчивость, reorg-кейсы.