Віталік Бутерін представив редизайн транзакцій Ethereum

ETH
редизайн транзакційпаралельна обробкаVitalik ButerinSTARK-доказиEthereumEIP-8141
2026-09-06Джерело: crypto.news
Віталік Бутерін представив редизайн транзакцій Ethereum

Співзасновник Ethereum Віталік Бутерін 6 вересня окреслив довгострокову модель транзакцій, яка може дозволити мережі обробляти частину робіт з перевірки паралельно.

Підсумок

  • Бутерін запропонував відокремити дії транзакцій від залежностей, щоб Ethereum міг пізніше оптимізувати кожен компонент незалежно.
  • Залежності включають підписи, докази стану та умови дійсності, які транзакції повинні задовольняти до початку виконання.
  • Чисті залежності можуть бути перевірені один раз мемпулами, а пізніше стиснуті в рекурсивні STARK-докази.
  • EIP-8141 пропонує фреймові транзакції з програмованою перевіркою, виконанням та оплатою газу в одному форматі транзакцій.
  • Розробники Ethereum ще не схвалили EIP-8141 для оновлення основної мережі та не опублікували дати розгортання.

Його пропозиція відокремлює ефекти, що створюються транзакціями, від умов, які повинні бути виконані до того, як ці ефекти можуть відбутися.

Бутерін описав ці два компоненти як «дії» та «залежності» у детальному дописі. Дії змінюють стан Ethereum, наприклад, переказ ETH або виклик контракту. Залежності охоплюють інформацію, необхідну для встановлення дійсності транзакції.

Цифровий підпис є одним із прикладів залежності. Інші приклади включають докази Меркла, що показують існування невитраченого виходу, докази з нульовим розголошенням та умови стану, які повинні залишатися істинними, коли транзакція потрапляє в блок.

Бутерін стверджував, що явне розмежування може допомогти Ethereum масштабуватися, не відмовляючись від свого гнучкого середовища виконання. Однак пропозиція залишається частиною поточних протокольних досліджень. Розробники Ethereum ще не схвалили повний дизайн для розгортання.

Ethereum може обробляти залежності транзакцій паралельно

Транзакції Ethereum наразі поєднують авторизацію, оплату комісії та виконання в загальному процесі обробки. Вузли перевіряють, чи правильно підписана транзакція, чи може відправник оплатити її, та чи успішно виконуються її інструкції.

Деякі з цих перевірок не залежать від кінцевих змін стану транзакції. Бутерін сказав, що такі залежності можуть оброблятися окремо і, в багатьох випадках, одночасно.

Наприклад, валідатору може знадобитися підтвердити підпис перед прийняттям транзакції. Ця перевірка не обов'язково повинна чекати на непов'язані підписи, прикріплені до інших транзакцій. Якщо кілька незалежних перевірок відомі заздалегідь, клієнти можуть розподілити роботу між доступними обчислювальними ресурсами.

Перевірки, що залежать від стану, вимагають більшої обережності. Умова, пов'язана з балансом рахунку або коміркою сховища, може стати недійсною, якщо попередня транзакція змінить той самий стан. Бутерін сказав, що мемпули можуть ефективніше міркувати про ці умови, коли транзакції оголошують, до яких частин стану вони звертаються.

Цей підхід винагороджував би передбачувані транзакції. Операції, які чітко визначають свої залежності, могли б отримати нижчі витрати на газ, оскільки клієнти могли б перевіряти їх ефективніше. Транзакції, що вимагають динамічних викликів та непередбачуваного доступу до стану, залишалися б можливими, але могли б коштувати дорожче.

Бутерін оцінив, що понад 90% активності Ethereum за обсягом не потребує повного рівня динамічної гнучкості мережі. Ця цифра є його оцінкою, а не опублікованим вимірюванням мережі в дописі. Ширший аргумент полягає в тому, що звичайні перекази та рутинні взаємодії з контрактами могли б використовувати більш обмежувальні формати, не обмежуючи спеціалізовані застосунки.

Запропонована модель зберегла б гнучку систему рахунків Ethereum для транзакцій, які цього потребують. Більш передбачувана активність могла б використовувати статично аналізовані структури, що нагадують частини моделі транзакцій Bitcoin.

Bitcoin використовує модель невитрачених виходів транзакцій, у якій транзакція визначає виходи, які вона має намір витратити. Ethereum зазвичай використовує акаунти з балансами, nonce та програмованим сховищем контрактів. Бутєрін не пропонує замінити модель акаунтів Ethereum на архітектуру Bitcoin. Він описав спектр, що поєднує ідеї з обох систем.

EIP-8141 надає загальну структуру транзакцій

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

Офіційна пропозиція стверджує, що дійсність транзакції та оплата комісії більше не залежатимуть виключно від стандартного підпису, прикріпленого до зовнішньої транзакції. Код акаунта замість цього може визначати необхідні правила авторизації та оплати.

Frame Transactions можуть підтримувати спонсоровані комісії, платежі в токенах, відмінних від ETH, ротацію ключів та пакетування транзакцій. Вони також можуть дозволити зовнішнім акаунтам отримувати функції абстракції акаунтів без покладання на те саме розгортання контракту в усіх сумісних мережах.

За запропонованою структурою, фрейми перевірки визначатимуть, чи авторизував відправник транзакцію. Окремі фрейми можуть встановлювати, хто сплачує комісії, а потім виконувати запитувані операції.

Ця структура узгоджується з поділом Бутєріна на залежності та дії. Фрейми перевірки обробляють умови, які мають бути виконані. Фрейми відправника обробляють операції, що змінюють стан.

Формат також може покращити інтероперабельність між мережами віртуальної машини Ethereum. Різні ланцюги можуть підтримувати ту саму мінімальну структуру транзакцій, застосовуючи власні інструменти перевірки, прекомпіляції або функції акаунтів.

Бутєрін описав потенційний формат як базовий список викликів із прапорцями, що визначають їх функцію. Виклик може бути позначений як чиста залежність, перевірка, що залежить від стану, або дія. Транзакція також міститиме стандартну інформацію, таку як її походження та nonce.

EIP-8141 залишається класифікованим як чернетка Core-пропозиції. Його поточна специфікація включає детальні правила для прийому в мемпул, виконання фреймів, квитанцій, підписів, обліку газу та розповсюдження транзакцій. Ці деталі можуть змінюватися під час розгляду.

Розробники Ethereum також обговорювали технічні проблеми. Вони включають ризики відмови в обслуговуванні, правила заміни транзакцій, зміни інструментів, обмеження на очікуючі транзакції та обмеження, накладені на фрейми перевірки.

В одному обговоренні зазначалося, що запропонований публічний мемпул зазвичай зберігатиме лише одну очікуючу Frame Transaction для кожного відправника. Розробники поставили під сумнів, як це правило вплине на акаунти, які регулярно надсилають кілька транзакцій в одному блоці.

Інші учасники досліджували, чи вносить формат додаткову складність для гаманців, будівельників блоків та інтерфейсів виклику віддалених процедур Ethereum. Ці питання мають бути вирішені, перш ніж команди клієнтів зможуть впровадити стабільну специфікацію.

Рекурсивні STARK можуть усунути повторну перевірку

Довгострокова модель Бутєріна виходить за межі EIP-8141. Він припустив, що залежності, які не потребують доступу до стану, можуть перевірятися один раз на рівні мемпула, а не повторюватися кожним валідатором.

Чиста залежність може включати криптографічний підпис або доказ, чия дійсність не змінюється зі станом Ethereum. Після перевірки мережа могла б замінити кілька частин роботи з перевірки рекурсивним STARK, що підтверджує, що всі перевірки були виконані правильно.

STARK — це криптографічний доказ, який дозволяє одній стороні продемонструвати, що обчислення було виконано правильно. Рекурсивні докази можуть перевіряти інші докази, що дозволяє об'єднати багато перевірок у менше завдання перевірки.

Запропонований мемпул міг би агрегувати підписи транзакцій, докази дійсності та інші залежності перед виконанням блоку. Валідатори потім перевіряли б агрегований доказ замість того, щоб незалежно повторювати кожне оригінальне обчислення.

Бутєрін припустив, що цей підхід також може зменшити обсяг даних перевірки, розміщених у ланцюжку. Якщо рекурсивний доказ встановлює, що всі залежності були дійсними, деякі оригінальні дані потенційно можуть бути опущені.

Цей результат не є частиною поточної специфікації EIP-8141. Він потребуватиме додаткових досліджень, що охоплюють генерацію доказів, координацію мемпула, доступність даних та захист від недійсної агрегації.

Дизайн також пов'язаний з підготовкою Ethereum до постквантової криптографії. Квантовостійкі підписи зазвичай більші та дорожчі у перевірці, ніж підписи ECDSA, які використовуються звичайними акаунтами Ethereum.

EIP-8141 може дозволити акаунтам визначати нові схеми авторизації, не чекаючи, поки Ethereum замінить єдиний фіксований стандарт підписів. Рекурсивна агрегація доказів могла б тоді зменшити вартість перевірки великих постквантових підписів.

EIP-8141 може допомогти акаунтам Ethereum прийняти постквантову авторизацію, якщо стануть доступними практичні системи підписів. Це залишається довгостроковим шляхом безпеки, а не негайною відповіддю на активну квантову загрозу.

Ключові nonce можуть усунути вузькі місця транзакцій

Акаунти Ethereum використовують послідовні nonce для запобігання повтору транзакцій. Якщо акаунт надсилає транзакції з номерами 10, 11 та 12, мережа зазвичай обробляє їх у такому порядку.

Послідовність може створювати вузьке місце. Якщо транзакція 10 застрягне або стане недійсною, пізніші транзакції з того ж акаунта також можуть чекати, навіть якщо їх операції не пов'язані між собою.

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

Це могло б допомогти смарт-акаунтам, системам конфіденційності та застосункам, які одночасно надсилають кілька незалежних операцій. Кожен робочий процес міг би отримати власну область nonce, зберігаючи захист від повтору.

Crypto.news раніше повідомляв, що ключові nonce можуть запобігти блокуванню незалежних приватних транзакцій одна одною. Ця функція є частиною ширших зусиль з покращення конфіденційних транзакцій, гнучких акаунтів та стійкості до цензури.

Бутерін також пов'язав роботу над транзакціями з альтернативними моделями стану, включаючи нативні UTXO-дизайни та структури стану на основі доказів. Ці проекти досліджують, чи можуть деякі активи або операції використовувати передбачувані правила стану, тоді як складні контракти зберігають існуючу гнучкість Ethereum.

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

Таке диференційоване ціноутворення намагалося б узгодити комісії з фактичними обмеженнями масштабування, створюваними кожною транзакцією. Воно не гарантувало б нижчих комісій для кожного користувача чи застосунку.

EIP-8141 все ще потребує схвалення розробників та тестування

EIP-8141 має пройти кілька етапів, перш ніж він зможе вплинути на користувачів Ethereum. Спочатку основні розробники повинні погодитися, що Frame Transactions пропонують кращий шлях, ніж конкуруючі дизайни абстракції акаунтів.

Потім пропозиція вимагатиме реалізацій клієнтів, тестових мереж, тестування інтероперабельності, підтримки гаманців та перевірки безпеки. Розробникам також потрібно буде протестувати, як Frame Transactions взаємодіють з будівельниками блоків, мемпулами, ринками комісій та існуючими смарт-контрактами.

Раніше обговорення розробників розглядали EIP-8141 для майбутнього оновлення Hegotá в Ethereum. Однак crypto.news повідомив, що Frame Transactions залишалися на розгляді, а не були формально заплановані.

FOCIL, окрема пропозиція, спрямована на покращення стійкості до цензури через списки включення транзакцій, також обговорювалася разом з EIP-8141. Ці дві пропозиції вирішують різні проблеми. Frame Transactions стосуються структури авторизації та виконання, тоді як FOCIL стосується включення відповідних транзакцій у блоки.

Розробники стверджували, що їх спільне використання могло б забезпечити нативну абстракцію акаунтів з сильнішою стійкістю до цензури. Ця комбінація все ще є запропонованим пакетом, а не затвердженим зобов'язанням у дорожній карті Ethereum.

Тому коментарі Бутеріна від 6 вересня описують можливий напрямок дизайну транзакцій Ethereum. Вони не оголошують про завершене оновлення, дату активації чи підтверджену зміну комісій за газ у мейннеті.

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

Поширені запитання

Що таке EIP-8141?

EIP-8141 пропонує фреймові транзакції, які розділяють перевірку, схвалення комісії та виконання на окремі кадри викликів контракту.
Наразі це проєкт пропозиції рівня Core. Розробники Ethereum все ще можуть змінити або відхилити його специфікацію.

Яка різниця між дією та залежністю?

Дія змінює стан Ethereum, наприклад, надсилання ETH або виклик контракту. Залежність — це умова, яка має бути дійсною, наприклад, підпис або доказ стану.
Їх розділення може дозволити обробляти незалежні залежності одночасно перед виконанням операцій, що змінюють стан.

Чи знизить EIP-8141 комісії за транзакції Ethereum?

Це може зробити передбачувані транзакції дешевшими в обробці, якщо розробники приймуть ціноутворення на газ, яке винагороджує статично аналізовані операції.
Жодне зниження комісії не підтверджено. Витрати залежатимуть від остаточної специфікації, реалізації клієнта та майбутніх рішень щодо оновлень.