EIP-4337: абстракция аккаунта без изменения протокола
EOA негибки: один ключ, газ только в ETH, одно действие за раз. Абстракция аккаунта делает аккаунты программируемыми — и EIP-4337 добивается этого без единого изменения консенсуса, используя транзакцию более высокого уровня, отдельный мемпул, бандлеров и синглтон EntryPoint.
- EOA против контрактов
- мемпул
Есть два вида аккаунтов Ethereum: контракт (программируемый, но не может начать ничего сам — выполняется только при вызове) и аккаунт, управляемый извне (EOA — может начинать транзакции, но негибкий). Всё, что вы делаете, начинается с EOA, а EOA застрял с одним подписывающим ключом, газом только в ETH и одним действием за транзакцию. Люди хотели аккаунты, которые программируемы — мультиподпись, passkeys, социальное восстановление, батчинг, возможность дать кому-то другому оплатить ваш газ. Это абстракция аккаунта. Очевидный способ её получить — изменить протокол так, чтобы аккаунты могли быть контрактами со своими правилами, — хардфорк, годы согласований. EIP-4337 задаёт более острый вопрос: можно ли получить всё это при нулевых изменениях консенсуса? Давайте выведем, как.
Проблема: EOA — это смирительная рубашка
Каждая транзакция берёт начало от EOA, а EOA может делать ровно то, что жёстко закодировано в протоколе. Его правило валидности фиксировано: одна валидная подпись secp256k1 над транзакцией, правильный nonce и достаточно ETH. Это единственное правило исключает почти всё, чего хотят люди.
Один ключ означает, что его потеря — это потеря всего: ни мультиподписи, ни аппаратных passkeys, ни социального восстановления. Газ только в ETH означает, что вы обязаны заранее держать ETH, чтобы вообще что-то сделать: ни спонсора, ни оплаты в USDC. Одно действие за транзакцию означает, что approve, а затем swap — это две подписи, две комиссии. Аккаунт-контракт мог бы закодировать любое правило, какое захотите ( абстракция аккаунта (account abstraction) Возможность определять валидность аккаунта его собственным кодом — любая схема подписи, любая политика газа, батчинг — вместо единого фиксированного протокольного правила ECDSA-и-ETH. ) — но контракт не может инициировать транзакцию; он выполняется только тогда, когда его кто-то вызывает.
→ Шаг 2: изобретаем транзакцию, которая живёт на уровень выше.
Транзакция уровнем выше: UserOperation
Не трогаем то, что такое транзакция. Добавляем новый объект уровнем выше: UserOperation Структура 4337, описывающая, что смарт-аккаунт хочет сделать — аккаунт, calldata, лимиты газа и подпись, которую сам аккаунт проверит любой удобной ему схемой. Это не транзакция Ethereum; она путешествует в отдельном мемпуле. . Она описывает, что смарт-аккаунт хочет сделать — адрес аккаунта, callData (действие, которое может быть батчем), лимиты газа и signature, которую сам аккаунт проверит как ему угодно. Пользователь подписывает её любой схемой, которую использует его аккаунт, — ключом ECDSA, passkey телефона, мультиподписью 2 из 3, — и рассылает в отдельный, альтернативный мемпул только для UserOperation, отличный от обычного мемпула транзакций.
Здесь в консенсусе ничего не изменилось. UserOperation — не транзакция, которую понимает протокол, — это сообщение прикладного уровня в новой одноранговой сети. Что поднимает очевидную проблему:
→ Шаг 3: пусть кто-то упакует её и запустит.
Бандлеры их упаковывают; EntryPoint их запускает
Встречайте бандлер (bundler) Обычный узел (EOA), который следит за мемпулом UserOperation, упаковывает батч UserOp в одну обычную транзакцию к EntryPoint, авансирует газ L1 и получает возмещение из депозитов аккаунтов. : обычный узел — запустить его может кто угодно, — который следит за мемпулом UserOp, выбирает батч и упаковывает их в одну обычную транзакцию Ethereum. Он отправляет эту транзакцию синглтон-контракту EntryPoint Единственный аудированный контракт (один на сеть), через который 4337 маршрутизирует всё. Его handleOps проходит циклом по каждой UserOp, сначала валидируя, затем исполняя, и аккаунты/пеймастеры доверяют только ему. , который проходит циклом по каждой UserOp в двух строго разделённых фазах:
- Валидация — EntryPoint вызывает
validateUserOp(...)аккаунта, который выполняет любую кастомную логику, определённую аккаунтом (проверить подпись passkey, порог мультиподписи, сессионный ключ) и должен согласиться платить. - Исполнение — EntryPoint вызывает аккаунт с
callDataиз UserOp — реальным действием, которое может объединять несколько вызовов в один.
Бандлер авансирует газ L1 и получает возмещение от EntryPoint из предварительно пополненного депозита каждого аккаунта. Так почему же его нельзя обмануть, заставив включить UserOp, которая не заплатит? Он сначала симулирует валидацию каждой UserOp офчейн, а правила запрещают валидации читать хранилище других аккаунтов — поэтому UserOp не может изменить собственную валидность на основании состояния, которое может сдвинуть другая транзакция, и симуляция остаётся правдивой вплоть до включения.
→ Шаг 4: пусть третья сторона оплатит счёт.
Пеймастеры: платит кто-то другой, или платите любым токеном
Добавляем одну опциональную сторону: контракт-пеймастер. UserOperation может указать пеймастера, который соглашается покрыть её газ. Это открывает две вещи, которых люди действительно хотели. Dapp может спонсировать ваши транзакции — вы не держите вообще никакого ETH, и всё просто работает. Или пеймастер может позволить вам платить газ в ERC-20, например в USDC: он забирает у вас токен и платит газ в ETH от вашего имени. EntryPoint сводит счета в конце и возмещает бандлеру из депозита пеймастера (или аккаунта).