Співзасновник Ethereum Віталік Бутерін 6 вересня окреслив довгострокову модель транзакцій, яка могла б дозволити мережі обробляти деякі роботи з валідації паралельно.
Його пропозиція розділяє ефекти, що створюються транзакціями, від умов, які повинні бути виконані, перш ніж ці ефекти можуть статися.
Бутерін описав два компоненти як «дії» та «залежності» у детальному дописі. Дії змінюють стан Ethereum, наприклад, переказ ETH або виклик контракту. Залежності охоплюють інформацію, необхідну для встановлення дійсності транзакції.
Цифровий підпис — один із прикладів залежності. Інші приклади включають докази Меркла, що показують наявність невитраченого виходу, докази з нульовим розголошенням та умови стану, які повинні залишатися істинними, коли транзакція входить у блок.
Бутерін стверджував, що чітке розмежування може допомогти Ethereum масштабуватися без відмови від його гнучкого середовища виконання. Однак пропозиція залишається частиною поточних досліджень протоколу. Розробники Ethereum не затвердили повний дизайн для розгортання.
Транзакції Ethereum наразі поєднують авторизацію, оплату комісії та виконання в єдиному потоці обробки. Вузли перевіряють, чи належним чином підписана транзакція, чи може відправник її оплатити та чи успішно виконуються її інструкції.
Деякі з цих перевірок не залежать від остаточних змін стану транзакції. Бутерін зазначив, що такі залежності можна обробляти окремо і, в багатьох випадках, одночасно.
Наприклад, валідатор може знадобитися підтвердити підпис перед прийняттям транзакції. Ця перевірка не обов'язково повинна чекати на непов'язані підписи, прикріплені до інших транзакцій. Якщо кілька незалежних перевірок відомі заздалегідь, клієнти можуть розподіляти роботу між доступними обчислювальними ресурсами.
Перевірки, що залежать від стану, вимагають більшої обережності. Умова, прив'язана до балансу облікового запису або слоту зберігання, може стати недійсною, якщо попередня транзакція змінить той самий стан. Бутерін зазначив, що мемпули могли б ефективніше міркувати про ці умови, коли транзакції оголошують, до яких частин стану вони звертаються.
Такий підхід винагороджував би передбачувані транзакції. Операції, які чітко визначають свої залежності, могли б отримувати нижчі витрати на газ, оскільки клієнти могли б перевіряти їх ефективніше. Транзакції, що вимагають динамічних викликів та непередбачуваного доступу до стану, залишалися б можливими, але могли б коштувати дорожче.
Бутерін оцінив, що понад 90% активності Ethereum за обсягом не потребує повного рівня динамічної гнучкості мережі. Ця цифра є його оцінкою, а не опублікованим вимірюванням мережі в дописі. Ширший аргумент полягає в тому, що звичайні перекази та рутинні взаємодії з контрактами могли б використовувати більш обмежувальні формати, не обмежуючи спеціалізовані застосунки.
Запропонована модель збереже гнучку систему облікових записів Ethereum для транзакцій, які її потребують. Більш передбачувана активність могла б використовувати статично аналізовані структури, що нагадують частини моделі транзакцій Bitcoin.
Bitcoin використовує модель невитрачених виходів транзакцій (UTXO), де транзакція ідентифікує виходи, які вона має намір витратити. Ethereum зазвичай використовує облікові записи з балансами, нонсами та програмованим сховищем контрактів. Бутерін не пропонує, щоб Ethereum замінив свою модель облікових записів архітектурою Bitcoin. Він описав спектр, що поєднує ідеї обох систем.
EIP-8141 — це проєкт пропозиції щодо покращення Ethereum для нового типу транзакцій, відомого як фреймова транзакція (Frame Transaction). Він розділяє транзакцію на фрейми викликів контракту, які можуть перевіряти повноваження, затверджувати оплату газу та виконувати користувацькі операції.
В офіційній пропозиції йдеться, що валідність транзакції та оплата комісії більше не залежатимуть виключно від стандартного підпису, прикріпленого до зовнішньої транзакції. Код облікового запису міг би натомість визначати необхідні правила авторизації та оплати.
Фреймові транзакції могли б підтримувати спонсоровані комісії, платежі токенами, відмінними від ETH, ротацію ключів та пакетування транзакцій. Вони також могли б дозволити зовнішнім обліковим записам (EOA) отримувати функції абстракції облікових записів без використання одного й того ж розгортання контракту в кожній сумісній мережі.
Згідно із запропонованою структурою, фрейми верифікації визначали б, чи відправник авторизував транзакцію. Окремі фрейми могли б встановлювати, хто сплачує комісії, а потім виконувати запитувані операції.
Ця структура узгоджується з поділом Бутеріна між залежностями та діями. Фрейми верифікації обробляють умови, які мають бути виконані. Фрейми відправника обробляють операції, які змінюють стан.
Формат також міг би покращити сумісність між мережами віртуальної машини Ethereum. Різні блокчейни могли б підтримувати ту саму мінімальну структуру транзакцій, застосовуючи власні інструменти верифікації, прекомпіляти або функції облікових записів.
Бутерін описав потенційний формат як базовий список викликів з прапорами, що ідентифікують їх функцію. Виклик міг би бути позначений як чиста залежність, верифікація, що залежить від стану, або дія. Транзакція також містила б стандартну інформацію, таку як її походження та нонс.
EIP-8141 залишається класифікованим як проєкт основної пропозиції. Його поточна специфікація включає детальні правила для допуску до мемпулу, виконання фреймів, квитанцій, підписів, обліку газу та поширення транзакцій. Ці деталі можуть змінюватися під час розгляду.
Розробники Ethereum також обговорювали технічні проблеми. До них належать ризики відмови в обслуговуванні (DoS), правила заміни транзакцій, зміни в інструментарії, обмеження на транзакції, що очікують, та обмеження, накладені на фрейми верифікації.
В одному обговоренні зазначалося, що запропонований публічний мемпул зазвичай зберігав би лише одну фреймову транзакцію, що очікує, для кожного відправника. Розробники ставили під сумнів, як це правило вплине на облікові записи, які регулярно надсилають кілька транзакцій в одному блоці.
Інші учасники розглядали, чи вводить формат додаткову складність для гаманців, будівельників блоків та інтерфейсів віддаленого виклику процедур (RPC) Ethereum. Ці питання мають бути вирішені, перш ніж команди клієнтів зможуть реалізувати стабільну специфікацію.
Довгострокова модель Бутеріна виходить за рамки EIP-8141. Він припустив, що залежності, які не вимагають доступу до стану, можна було б перевіряти один раз на рівні мемпулу замість того, щоб повторювати їх кожним валідатором.
Чиста залежність може включати криптографічний підпис або доказ, дійсність якого не змінюється зі станом Ethereum. Після її перевірки мережа могла б замінити кілька фрагментів роботи з верифікації рекурсивним STARKом, що підтверджує правильне виконання всіх перевірок.
STARK — це криптографічний доказ, який дозволяє одній стороні продемонструвати, що обчислення було виконано правильно. Рекурсивні докази можуть перевіряти інші докази, що дозволяє об'єднати багато перевірок у менше завдання верифікації.
Запропонований мемпул міг би агрегувати підписи транзакцій, докази валідності та інші залежності перед виконанням блоку. Потім валідатори перевіряли б агрегований доказ замість того, щоб незалежно повторювати кожне оригінальне обчислення.
Бутерін припустив, що такий підхід також може зменшити обсяг даних верифікації, розміщених в мережі. Якщо рекурсивний доказ встановлює, що всі залежності були дійсними, деякі оригінальні дані потенційно можуть бути опущені.
Цей результат не є частиною поточної специфікації EIP-8141. Він вимагав би додаткових досліджень, що охоплюють генерацію доказів, координацію мемпулу, доступність даних та захист від недійсної агрегації.
Дизайн також стосується підготовки Ethereum до постквантової криптографії. Квантово-стійкі підписи, як правило, більші та дорожчі для перевірки, ніж підписи ECDSA, що використовуються звичайними обліковими записами Ethereum.
EIP-8141 міг би дозволити обліковим записам визначати нові схеми авторизації, не чекаючи, поки Ethereum замінить єдиний фіксований стандарт підпису. Агрегація рекурсивних доказів могла б потім зменшити вартість перевірки великих постквантових підписів.
EIP-8141 міг би допомогти обліковим записам Ethereum прийняти постквантову авторизацію, якщо стануть доступними практичні системи підпису. Це залишається довгостроковим шляхом безпеки, а не негайною відповіддю на активну квантову загрозу.
Облікові записи Ethereum використовують послідовні нонси для запобігання повторному відтворенню транзакцій. Якщо обліковий запис надсилає транзакції з номерами 10, 11 та 12, мережа зазвичай обробляє їх у цьому порядку.
Послідовність може створити вузьке місце. Якщо транзакція 10 застрягне або стане недійсною, пізніші транзакції з того ж облікового запису також можуть чекати, навіть якщо їх операції не пов'язані між собою.
Ключовані нонси надавали б обліковому запису кілька незалежних послідовностей нонсів. Транзакції, призначені різним ключам, могли б виконуватися, не чекаючи на просування іншої послідовності.
Це могло б допомогти смарт-рахункам, системам конфіденційності та застосункам, які одночасно надсилають кілька незалежних операцій. Кожен робочий процес міг би отримати власний домен нонсів, зберігаючи при цьому захист від повторного відтворення.
Crypto.news раніше повідомляв, що ключовані нонси могли б запобігти блокуванню незалежних приватних транзакцій одна одною. Ця функція є частиною ширших зусиль щодо покращення конфіденційності транзакцій, гнучкості облікових записів та стійкості до цензури.
Бутерін також пов'язав роботу з транзакціями з альтернативними моделями стану, включаючи нативні UTXO-дизайни та структури стану на основі доказів. Ці проєкти досліджують, чи можуть деякі активи або операції використовувати передбачувані правила стану, тоді як складні контракти зберігають існуючу гнучкість Ethereum.
Такий підхід міг би створити кілька рівнів обробки. Прості, оголошені операції було б легше аналізувати, і вони могли б отримувати нижчі комісії. Динамічні виклики контрактів продовжували б працювати, але споживали б більше ресурсів, оскільки клієнти не можуть підготувати їх виконання так само.
Таке диференційоване ціноутворення намагалося б узгодити комісії з фактичними обмеженнями масштабування, створеними кожною транзакцією. Воно не гарантувало б нижчих комісій для кожного користувача або застосунку.
EIP-8141 має пройти кілька етапів, перш ніж він зможе вплинути на користувачів Ethereum. Основним розробникам спочатку потрібно погодитися, що фреймові транзакції пропонують кращий шлях, ніж конкуруючі дизайни абстракції облікових записів.
Пропозиція тоді вимагала б реалізацій клієнтів, мереж розробки, тестування сумісності, підтримки гаманців та аудиту безпеки. Розробникам також потрібно було б протестувати, як фреймові транзакції взаємодіють з будівельниками блоків, мемпулами, ринками комісій та існуючими смарт-контрактами.
Попередні дискусії розробників розглядали EIP-8141 для майбутнього оновлення Ethereum Hegotá. Однак crypto.news повідомляв, що фреймові транзакції залишалися на розгляді, а не були офіційно заплановані.
FOCIL, окрема пропозиція, спрямована на покращення стійкості до цензури за допомогою списків включення транзакцій, також обговорювалася поряд з EIP-8141. Ці дві пропозиції стосуються різних проблем. Фреймові транзакції стосуються авторизації та структури виконання, тоді як FOCIL стосується включення відповідних транзакцій у блоки.
Розробники стверджували, що їх спільне використання могло б забезпечити нативну абстракцію облікових записів з сильнішою стійкістю до цензури. Ця комбінація все ще є запропонованим пакетом, а не затвердженим зобов'язанням дорожньої карти Ethereum.
Таким чином, коментарі Бутеріна від 6 вересня описують можливий напрямок для дизайну транзакцій Ethereum. Вони не оголошують про завершене оновлення, дату активації або підтверджену зміну комісій за газ в основній мережі.
Наступними перевіряються етапами будуть офіційна підтримка розробників, включення до обсягу оновлення та робочі реалізації в мережах розробки. До того часу EIP-8141 та рекурсивні STARK-мемпули залишаються активними дослідницькими та інженерними пропозиціями.
EIP-8141 пропонує фреймові транзакції, які розділяють валідацію, затвердження комісії та виконання на окремі фрейми викликів контрактів.
Наразі це проєкт основної пропозиції. Розробники Ethereum все ще можуть змінити або відхилити її специфікацію.
Дія змінює стан Ethereum, наприклад, надсилання ETH або виклик контракту. Залежність — це умова, яка має бути дійсною, наприклад, підпис або доказ стану.
Їх поділ міг би дозволити одночасну обробку незалежних залежностей до виконання операцій, що змінюють стан.
Він міг би зробити передбачувані транзакції дешевшими для обробки, якщо розробники приймуть ціноутворення газу, яке винагороджує статично аналізовані операції.
Зниження комісії не підтверджено. Витрати залежатимуть від остаточної специфікації, реалізації клієнта та майбутніх рішень щодо оновлень.
ETH