EIP-8141 и ERC-4337: в чем разница?

Главное отличие между EIP-8141 и ERC-4337 — архитектура. ERC-4337 реализует абстракцию аккаунтов поверх существующей системы транзакций Ethereum, используя смарт-контрактные кошельки, UserOperations, bundlers, смарт-контракт EntryPoint и опциональные paymasters. В отличие от этого, EIP-8141 предлагает новый тип Frame Transaction на уровне протокола, позволяя выполнять в одной транзакции валидацию, оплату газа, развертывание и исполнение через несколько фреймов.

Оба стандарта обеспечивают схожие функции абстракции аккаунта: спонсируемые транзакции, пакетные операции, гибкие подписи, механизмы восстановления и более простой интерфейс кошелька. Отличие заключается в том, насколько глубоко эти функции интегрированы в Ethereum.

Основные выводы

• ERC-4337 работает без изменения нативного типа транзакции Ethereum, тогда как EIP-8141 внедряет Frame Transactions непосредственно в протокол.

• ERC-4337 использует UserOperations, bundlers, EntryPoint-контракт и paymaster-контракты.

• EIP-8141 применяет VERIFY, SENDER и другие фреймы для разделения процессов валидации, оплаты газа, развертывания и исполнения.

• Оба стандарта поддерживают абстракцию газа, пакетные транзакции, альтернативные подписи и спонсируемые операции.

• EIP-7702 предоставляет путь миграции для текущих EOAs, позволяя им использовать возможности смарт-контрактов и интегрироваться с обеими архитектурами абстракции аккаунта.

EIP-8141 vs. ERC-4337: абстракция аккаунта

ERC-4337 называет UserOperation псевдотранзакцией. В ней содержатся поля call data, лимиты газа, максимальная комиссия, подпись и данные paymaster. Затем bundler упаковывает её в стандартную транзакцию Ethereum для отправки в EntryPoint.

EIP-8141 модифицирует традиционный формат транзакции. Payload включает несколько фреймов, подписи, параметры комиссии и адрес отправителя, позволяя каждому фрейму иметь собственный режим исполнения и лимиты газа.

Как работают смарт-контрактные кошельки ERC-4337

ERC-4337 позволяет пользователю создавать или использовать смарт-аккаунт-контракт, выходя за рамки традиционного EOA.

Пользователь подписывает UserOperation с заданными данными вызова. Bundler собирает отложенные UserOperations и отправляет их через EntryPoint-контракт, который валидирует аккаунты и координирует исполнение. Paymaster-контракт может спонсировать газ, что позволяет приложениям создавать условные политики оплаты или давать пользователям возможность оплачивать транзакции токенами ERC-20.

Поскольку поле подписи интерпретируется смарт-аккаунтом, а не фиксируется правилами консенсуса Ethereum, ERC-4337 поддерживает session keys, мультиподписи, логику восстановления и модульные смарт-аккаунты.

Действующая архитектура абстракции аккаунта ERC-4337 предоставляет развитые функции смарт-контрактов без необходимости обновления протокола.

Как Frame Transaction EIP-8141 меняет модель

EIP-8141 переносит эти функции в нативный поток транзакций Ethereum.

Verify frame обеспечивает валидацию. Sender frame выполняет операцию пользователя в контексте отправителя. Deploy frame устанавливает код аккаунта до валидации при необходимости, дополнительные фреймы отвечают за оплату или пост-логика исполнения.

Опкод APPROVE позволяет коду валидации задавать область утверждения для исполнения, оплаты или обоих процессов. После авторизации исполнения остальные фреймы выполняют многошаговые операции.

Главное отличие Frame Transactions vs. ERC-4337: протокол сам понимает эти этапы, не зависая от отдельного UserOperation pipeline.

Оплата газа и учет газа

Оба стандарта поддерживают пользователей, которым не обязательно хранить ETH для каждой транзакции.

В ERC-4337 paymaster-контракт оплачивает газ и может возместить расходы пользователю в другой валюте. Провайдер кошелька или dApp задаёт условия спонсорства.

В EIP-8141 оплата газа интегрирована в процесс валидации транзакции. Спонсор-контракт может авторизовать оплату, а отправитель — исполнение. Плательщик не обязан быть отправителем.

EIP-8141 использует более явную модель газа: каждый фрейм получает лимит газа для исполнения и состояния, а транзакция ограничена максимальной стоимостью. Неиспользованный газ одного фрейма не переходит другим, что помогает ограничить стоимость симуляции и работу по валидации.

Пакетные транзакции и множественные операции

Смарт-аккаунты ERC-4337 уже реализуют пакетирование транзакций, позволяя пользователю выполнять несколько операций через одно действие.

EIP-8141 делает пакетные операции явными благодаря множеству фреймов. Атомарный пакет объединяет последовательные действия, чтобы они выполнялись или откатывались вместе. Если один фрейм откатывается, откатываются все связанные изменения.

Например, одобрение токена и обмен можно обработать как единую последовательность «всё или ничего», чтобы избежать неиспользованного одобрения при неудаче обмена.

Этот подход к многошаговым операциям — причина, почему EIP-8141 упрощает архитектуру смарт-аккаунтов.

EIP-7702 и путь миграции для внешних аккаунтов (EOA)

EIP-7702 позволяет EOA делегировать исполнение контрактному коду, сохраняя адрес. Это создает мост между традиционными аккаунтами и функциональностью смарт-аккаунта.

ERC-4337 поддерживает EIP-7702-аккаунты, не требуя пользователя переходить на новый контрактный адрес.

EIP-8141 предлагает код по умолчанию, предоставляя базовое поведение Frame Transaction даже при пустом месте хранения или отсутствии кода. Deploy frame устанавливает или делегирует код при необходимости.

EIP-7702, ERC-4337 и EIP-8141 — взаимосвязанные этапы миграции абстракции аккаунта Ethereum, а не три независимые системы.

Нативная абстракция аккаунта: что меняется на уровне протокола?

Глубокая интеграция EIP-8141 снижает зависимость от bundlers и офчейн-инфраструктуры для стандартных операций абстракции аккаунта.

Она приближает программируемую валидацию к уровню консенсуса. Логика валидации поддерживает политики восстановления, агрегацию подписей, разрешения session и постквантовую аутентификацию.

Обратной стороной становится сложность: публичные узлы должны безопасно оценивать Frame Transaction до включения. EIP-8141 определяет ограниченный валидационный префикс, лимитирует доступ к состоянию, ограничивает работу по валидации и различает paymasters для снижения риска массовой инвалидации и атак типа отказ в обслуживании.

Архитектура абстракции аккаунта Ethereum демонстрирует, почему UX кошельков движется от обходных решений к поддержке на уровне протокола.

Заключение

Если кратко: ERC-4337 строит абстракцию аккаунта вокруг Ethereum, EIP-8141 внедряет её непосредственно в Ethereum.

ERC-4337 использует смарт-контрактные кошельки, UserOperations, bundlers, EntryPoint и paymasters. EIP-8141 внедряет Frame Transactions с отдельными этапами валидации, отправки, развертывания, оплаты и исполнения.

ERC-4337 ценен тем, что уже предоставляет зрелую инфраструктуру абстракции аккаунтов без необходимости ждать обновлений протокола. EIP-8141 делает абстракцию газа, программируемую валидацию, пакетные операции и спонсируемые транзакции более нативными и менее зависимыми от отдельного pipeline транзакций.

Часто задаваемые вопросы

Заменяет ли EIP-8141 ERC-4337?

Нет. ERC-4337 уже поддерживает развернутые смарт-аккаунты и инфраструктуру. EIP-8141 изменяет нативные возможности Ethereum, и кошельки могут продолжить использовать компоненты ERC-4337 там, где это оправдано.

Требуется ли EntryPoint-контракт для EIP-8141?

Единый EntryPoint-контракт не нужен для основного потока Frame Transaction. Валидация и исполнение реализуются непосредственно через фреймы транзакции, а не через UserOperations, отправляемые через EntryPoint.

Могут ли оба стандарта поддерживать спонсируемые выплаты газа?

Да. ERC-4337 использует paymasters для спонсирования UserOperations. EIP-8141 позволяет валидации транзакции отдельно авторизовать отправителя и плательщика, что дает возможность спонсор-контракту покрывать оплату газа.

Может ли ERC-4337 поддерживать существующие EOAs?

Да, особенно через EIP-7702. EOA может делегировать функциональность смарт-контракта, сохраняя свой текущий адрес и избегая полной миграции аккаунта.

Почему EIP-8141 называют нативной абстракцией аккаунта?

Потому что процессы валидации, авторизации оплаты, развертывания и исполнения реализованы в новом формате транзакции Ethereum, а не вынесены во внешнюю инфраструктуру UserOperation.

Данный материал предназначен исключительно для образовательных целей. Стандарты Ethereum, обновления протокола, реализации кошельков и спецификации EIP могут изменяться.