Что представляют собой транзакции эфириум Frame?

Если Вы только начинаете знакомство с понятием «Frame Transactions» в контексте Ethereum и Hegotá, проще всего представить такую транзакцию как последовательность нескольких согласованных этапов. Один фрейм проверяет отправителя, другой — подтверждает оплату, а последующие фреймы выполняют фактическое пользовательское действие. В данном материале рассматривается базовая структура Frame Transactions, а не весь спектр предложений EIP-8141.

Основные положения

• EIP-8141 вводит новый тип Frame Transaction, которому присвоен тип 0x06.

• В одной транзакции может быть до 64 фреймов, каждый из которых задаёт собственный режим исполнения и лимит газа.

• Фреймы разделяют этапы проверки транзакции, оплаты газа и выполнения пользовательских действий.

• Опкод APPROVE позволяет отдельно авторизовать выполнение, оплату или оба действия одновременно.

• Абстракция фреймов обеспечивает встроенную абстракцию аккаунта, атомарные объединения, спонсорство газа и программируемую верификацию подписи.

Что такое Frame Transaction по стандарту EIP-8141?

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

Payload транзакции включает адрес отправителя, подписи, комиссии и список фреймов. Каждый фрейм содержит свой режим, флаги, целевой адрес, лимиты исполнения и лимиты state-gas (state-gas — лимиты состояния газа), величину и данные. Текущая спецификация задаёт MAX_FRAMES равным 64 и FRAME_TX_TYPE равным 0x06.

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

Как устроены режимы исполнения Frame Transaction?

Каждый фрейм по стандарту EIP-8141 работает в одном из трёх режимов исполнения:

Режим исполнения определяет контекст работы фрейма. Фрейм VERIFY выполняет логику проверки до начала исполнения фреймов отправителя; режим SENDER позволяет выполнять операции от адреса отправителя; режим DEFAULT предоставляет нейтральную идентичность на уровне протокола.

Такая модульная структура лежит в основе встроенной абстракции аккаунта, поскольку проверка больше не привязана к одному приватному ключу или схеме подписи.

Что делает опкод APPROVE?

EIP-8141 вводит опкод APPROVE, который обновляет контекст авторизации транзакции.

В логике проверки можно использовать разные области авторизации:

• APPROVE_PAYMENT разрешает оплату газа.

• APPROVE_EXECUTION разрешает выполнение следующих фреймов отправителя.

• APPROVE_EXECUTION_AND_PAYMENT разрешает оба действия.

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

Это разделение позволяет контракту-спонсору или платёжному агенту авторизовать максимальные расходы газа, а пользовательская логика отдельно разрешает выполнение.

Какие семь опкодов фрейма определены в EIP-8141?

В спецификации представлены семь новых инструкций для работы с фреймами:

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

Как устроены оплата и учет газа?

Frame Transactions разделяют оплату газа и отправителя. Фрейм VERIFY может авторизовать другой аккаунт или контракт-спонсор для оплаты, что обеспечивает нативный механизм спонсорства газа.

Например, пользователь хранит стейблкоины, а другой аккаунт становится плательщиком газа. Frame Transaction может перевести токены ERC-20 для компенсации спонсору, а расходы на транзакцию Ethereum покрываются назначенным плательщиком.

Каждый фрейм также получает лимиты на исполнение и лимиты state-gas (state-gas — лимиты состояния газа). Неиспользованный газ уменьшает итоговую сумму списания с плательщика, а не становится дополнительной мощностью для следующих фреймов.

Как атомарное объединение делает фреймы неделимыми?

Атомарное объединение связывает несколько фреймов так, что они выполняются или откатываются вместе.

Например, сначала идёт одобрение ERC-20, затем обмен. Если установлен флаг атомарного объединения и фрейм обмена откатывается, то и предыдущее одобрение отменяется. Это предотвращает нежелательное разрешение токенов после неудачной транзакции.

Frame Transactions упрощают многошаговые взаимодействия со смарт-контрактами.

Почему Frame Transactions важны для абстракции аккаунта?

Текущий фреймворк абстракции аккаунта ERC-4337 в Ethereum использует смарт-аккаунты, bundlers, операции пользователя и платёжных агентов для программируемого поведения кошелька. Frame Transactions дают большую гибкость непосредственно на уровне протокола.

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

Гибкость приводит к компромиссам. Произвольная логика проверки может создавать риски отказа в обслуживании пула транзакций или массового аннулирования, поэтому публичные правила mempool ограничивают префикс проверки и обработку ожидающих Frame Transactions.

Заключение

Frame Transaction в Ethereum — это одна транзакция, состоящая из нескольких программируемых фреймов. Вместо жесткой привязки проверки, оплаты газа и выполнения к одной роли, EIP-8141 позволяет разделить эти задачи между фреймами.

Это основное отличие: EIP-8141 — это предложение к протоколу; Frame Transactions — новый формат транзакции, который оно вводит. Модульная структура позволяет реализовать спонсорство газа, атомарное объединение, программируемую проверку, гибкие подписи и абстракцию аккаунта без создания отдельных систем транзакций для каждой функции.

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

Является ли режим VERIFY только для чтения в Frame Transaction?

Да. Режим VERIFY предназначен для проверки транзакции и работает без постоянных изменений состояния. Это помогает узлам безопасно моделировать проверку перед решением о включении или сохранении ожидающей Frame Transaction в публичном mempool.

Может ли Ethereum заранее знать плательщика газа до исполнения Frame Transaction?

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

Когда утверждается плательщик в Frame Transaction по EIP-8141?

Сначала подтверждается авторизация отправителя, затем отдельно — авторизация оплаты для аккаунта или платёжного агента, который покрывает расходы на газ. Это позволяет одному лицу авторизовать выполнение, а другому — оплату газа.

Может ли одна Frame Transaction использовать остаток газа другого фрейма?

Нет. Учёт газа в Frame Transaction не позволяет одному фрейму заимствовать неиспользованный лимит газа другого. Каждый фрейм имеет собственные лимиты исполнения и лимиты state-gas (state-gas — лимиты состояния газа), а общий лимит газа транзакции включает intrinsic-gas и соответствующие лимиты исполнения фреймов.

В чем разница между каноническим и неканоническим платёжным агентом?

Канонический платёжный агент реализован по спецификации протокола, и его код соответствует требованиям. Узлы могут отслеживать его обязательства по газу более предсказуемо. Для неканонических платёжных агентов действуют более строгие ограничения mempool, включая лимит на одну ожидающую транзакцию, чтобы снизить риски массового аннулирования и отказа в обслуживании.

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