
Для початківців, які вперше стикаються з “Frame Transactions” в обговореннях Ethereum і Hegotá, найзручніше розглядати це як транзакцію, що складається з кількох узгоджених етапів. Один фрейм перевіряє відправника, інший — авторизує оплату, а наступні фрейми виконують дію користувача. У статті розглядається базова структура, а не повна пропозиція EIP-8141.
EIP-8141 визначає новий тип Frame Transaction із поточним типом транзакції 0x06.
Одна транзакція може містити до 64 фреймів, кожен із власним режимом виконання та лімітами газу.
Фрейми розділяють валідацію транзакції, оплату газу та виконання дій користувача.
Оператор APPROVE окремо авторизує виконання, оплату або обидва процеси.
Абстракція фреймів дозволяє нативну абстракцію акаунтів, атомарне батчування, спонсорування газу та програмовану перевірку підпису.
Офіційна специфікація Frame Transaction EIP-8141 описує нову транзакцію, валідність і оплату газу якої можна визначати абстракцією. Специфікація EIP-8141
Payload транзакції містить адресу відправника, підписи, комісії та список фреймів. Кожен фрейм задає режим, прапорці, ціль, ліміти виконання та state-gas, 'value' і дані. Поточна специфікація встановлює MAX_FRAMES як 64 та FRAME_TX_TYPE як 0x06.
Традиційна транзакція має структуру “відправник підписує — відправник платить”. Абстракція фреймів перетворює це на програмовану послідовність.
Кожен фрейм EIP-8141 має один із трьох режимів виконання:
| Режим | Базове призначення |
|---|---|
| VERIFY | Валідація транзакції |
| SENDER | Виконання від імені відправника транзакції |
| DEFAULT | Виконання від імені протокольної ідентичності ENTRY_POINT |
Режим виконання визначає контекст фрейму. VERIFY запускає перевірку перед виконанням фреймів відправника, SENDER дозволяє операціям діяти від відправника, DEFAULT забезпечує нейтральну ідентичність на рівні протоколу.
Модульна структура забезпечує нативну абстракцію акаунтів, оскільки перевірка не прив’язана до одного приватного ключа чи схеми підпису.
EIP-8141 додає оператор APPROVE, що оновлює контекст схвалення транзакції.
Логіка валідації використовує різні сфери схвалення:
APPROVE_PAYMENT — авторизація оплати газу.
APPROVE_EXECUTION — авторизація виконання фреймів відправника.
APPROVE_EXECUTION_AND_PAYMENT — авторизація обох процесів.
Визначена ціль має бути викликом APPROVE, що обмежує коло осіб, які можуть надати авторизацію. Після схвалення виконання наступні фрейми SENDER виконуються у контексті відправника.
Це дозволяє контракту-спонсору чи paymaster авторизувати максимальні витрати газу, водночас логіка користувача окремо авторизує виконання.
Поточна специфікація містить сім нових інструкцій для фреймів:
| Оператор | Функція |
|---|---|
| APPROVE | Авторизація оплати та/або виконання |
| TXPARAM | Зчитування параметрів транзакції |
| FRAMEDATALOAD | Завантаження даних із заданого фрейму |
| FRAMEDATACOPY | Копіювання вхідних даних фрейму у пам’ять |
| FRAMEPARAM | Зчитування параметрів фрейму і статусу виконання |
| SIGPARAM | Зчитування метаданих підпису |
| SIGDATACOPY | Копіювання підтримуваних даних підпису |
Наприклад, TXPARAM показує інформацію транзакції: відправника, максимальну комісію, хеш підпису, кількість фреймів. FRAMEPARAM розкриває деталі фрейму — режим виконання, прапорці, витрачений газ, наявність прапорця атомарного батчу. Базові пошукові операції мають газ-вартість 2.
Frame Transactions розділяють оплату газу і роль відправника. VERIFY-фрейм може авторизувати інший акаунт або контракт-спонсор для оплати, створюючи механізм спонсорування газу.
Наприклад, користувач зберігає стейблкоїни, а інший акаунт — платник газу. Frame Transaction може переказати токени ERC-20 для компенсації спонсору, а базові витрати транзакції Ethereum покриває визначений платник.
Кожен фрейм отримує ліміти виконання і state-gas. Невикористаний газ зменшує кінцеву суму платника газу, а не збільшує ресурс для наступних фреймів.
Атомарне батчування об’єднує кілька фреймів виконання так, що вони або виконуються разом, або всі відхиляються.
Наприклад, схвалення ERC-20, а потім своп. Якщо встановлений прапорець атомарного батчу і своп-фрейм відкочується, попереднє схвалення також відкочується. Це запобігає небажаному залишку дозволу токену після невдалої транзакції.
Frame Transactions спрощують багатокрокові Взаємодія зі смарт-контрактами.
Фреймворк абстракції акаунтів ERC-4337 Ethereum використовує смарт-акаунти, bundlers, UserOperations, paymasters для програмованої поведінки Гаманця. Frame Transactions забезпечують цю гнучкість безпосередньо на рівні протоколу.
Програмована валідація EIP-8141 підтримує різні схеми підпису, ротацію ключів, агрегацію підписів у майбутньому та шлях до постквантової готовності. Default code (типовий код) дозволяє акаунтам без розгорнутого коду брати участь, фрейм розгортання підтримує розгортання акаунтів перед перевіркою.
Гнучкість породжує компроміси. Довільна логіка валідації може спричинити відмова в обслуговуванні (denial-of-service) чи масові відхилення у пулі транзакцій, тому публічні правила mempool обмежують валідаційний префікс і регулюють обробку Frame Transactions.
Frame Transaction в Ethereum — це одна транзакція, що складається з кількох програмованих фреймів. Замість жорсткої прив’язки валідації, оплати газу та виконання до однієї ролі транзакції, EIP-8141 дозволяє кожній функції виконуватись в окремому фреймі.
Це ключова відмінність: EIP-8141 — це пропозиція протоколу; Frame Transactions — новий формат транзакції, який вона впроваджує. Модульна структура забезпечує спонсорування газу, атомарне батчування, програмовану валідацію, гнучкі підписи та нативну абстракцію акаунтів без створення окремої системи транзакцій для кожної функції.
Так. Режим VERIFY використовується для валідації транзакції і призначений для роботи без постійних змін стану. Це дозволяє вузлам безпечно симулювати валідацію перед вирішенням щодо Frame Transaction у публічному mempool.
Не завжди. У EIP-8141 платник визначається програмованою логікою валідації, тому його не можна встановити лише за даними транзакції. Схвалення оплати встановлюється під час процесу валідації транзакції.
Авторизацію відправника встановлюють першою, після чого підтверджується схвалення оплати для акаунта чи paymaster, який покриває витрати газу. Це розділення дає можливість одній стороні авторизувати виконання, а іншому акаунту — оплату газу.
Ні. Облік газу у Frame Transaction не дозволяє одному фрейму запозичувати невикористаний бюджет газу іншого. Кожен фрейм має визначені ліміти виконання і state-gas, а загальний ліміт газу транзакції складається з intrinsic gas і відповідних лімітів фреймів.
Канонічний paymaster відповідає реалізації, визначеній протоколом, і код контракту має співпадати із специфікацією. Вузли можуть передбачувано відстежувати його зобов’язання щодо газу. Неканонічні paymasters мають суворіші обмеження у mempool, зокрема ліміт на одну транзакцію, щоб знизити ризики масових відхилень і відмова в обслуговуванні (denial-of-service).
Цей контент призначено лише для освітніх цілей. EIP-8141 є частиною дорожньої карти розвитку Ethereum, і деталі специфікації можуть змінитися до активації в основна мережа.











