Ethereum готовится получить новый транзакционный примитив, способный изменить то, как кошельки, dApps и смарт-контракты взаимодействуют с сетью. EIP-8141 вводит «Frame Transaction» — единую транзакцию, которую можно разбить до 64 программируемых суб-единиц, называемых фреймами, каждая из которых способна выполнять отдельные операции в рамках одного атомарного исполнения.

Предложение, соавторами которого являются Виталик Бутерин и несколько ключевых контрибьюторов, было впервые выдвинуто 29 января 2026 года. С тех пор оно получило статус «Scheduled» для включения в хардфорк Hegotá 2027 года, что означает прохождение ранней процедурной проверки, однако оно по-прежнему следует процессу Ethereum improvement proposal, в рамках которого запланированные предложения могут быть пересмотрены до окончательного включения в обновление сети.

Что на деле делают фрейм-транзакции

Новый тип транзакции, обозначенный 0x06, позволяет каждому фрейму работать в одном из трёх режимов. DEFAULT отвечает за стандартное развёртывание транзакций. VERIFY выполняет валидацию в режиме чтения, что полезно для проверки условий без изменения состояния. SENDER исполняется в контексте отправителя транзакции, открывая возможности, которые ранее требовали развёртывания выделенных кошельков-смарт-контрактов.

Каждый фрейм несёт внутреннюю стоимость 12 000 газа плюс 475 газа за фрейм. Для сравнения: базовый перевод Ethereum сегодня стоит 21 000 газа, поэтому накладные расходы на фрейм относительно невелики с учётом открываемой функциональности.

Предложение также вводит несколько новых опкодов. Опкод APPROVE (0xaa) отвечает за логику авторизации, а набор опкодов TXPARAM, FRAME и SIG даёт разработчикам детальный контроль над тем, как фреймы ссылаются друг на друга, передают параметры и проверяют подписи.

Почему это важно: нативная абстракция аккаунтов без обходных решений

Экосистема годами двигалась к абстракции аккаунтов через предложения вроде ERC-4337, представленного в 2021 году, который создал «альтернативный мемпул» для транзакций с абстракцией аккаунтов без изменения самого протокола. EIP-7702 пошёл другим путём, позволив EOA временно делегировать исполнение коду смарт-контракта; он был включён в обновление Pectra, запущенное в 2025 году. ERC-4337 добавляет сложность инфраструктуры в виде бандлеров и пеймастеров, тогда как EIP-7702 требует постоянных настроек делегирования.

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

Предложение явно дополняет, а не заменяет EIP-7702 и ERC-4337. Разработчики, уже построившие решения на этих стандартах, не обязаны удалять существующие интеграции.

Спонсорство газа и атомарный батчинг

С фрейм-транзакциями третья сторона может покрывать расходы на газ в рамках той же структуры транзакции. dApp сможет подключать новых пользователей с нулевым балансом ETH, спонсируя их первые взаимодействия — без внешних релейных сетей или офлайн-схем подписей.

Атомарный батчинг позволяет объединять операции approve-and-swap в единое атомарное действие: исполняется либо всё, либо ничего. Это устраняет существующий риск, когда успешное одобрение при неудачном свопе оставляет контракт авторизованным тратить токены.

Ещё одно заметное включение — оплата комиссий в ERC-20. Пользователи смогут платить комиссии в стейблкоинах или других токенах вместо ETH, при этом фрейм обрабатывает логику конвертации или оплаты внутри транзакции.

Пользователи также смогут создавать временные аккаунты под конкретные цели для отдельных транзакций без развёртывания постоянных смарт-аккаунтов или настройки делегирования.

Постквантовые последствия и долгосрочное позиционирование

Фрейм-транзакции создают естественную структуру для внедрения постквантовых схем подписей. Поскольку каждый фрейм может нести собственную логику проверки подписи, сеть сможет поддерживать квантово-устойчивые алгоритмы наряду с существующими подписями ECDSA без жёсткого переключения. Практическое внедрение, как и в случае предыдущих протокольных дополнений, будет зависеть от поддержки кошельков и инструментов после выхода хардфорка.