Як функціонують докази валідності транзакцій відповідно до EIP-8361?

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

Пояснення також показує відмінності EIP-8361 від двох основних типів безпеки ролапів: ZK-доказів, які підтверджують коректність до прийняття, і fraud proofs, що потребують процесу оскарження для виявлення недійсного переходу. Додатково уточнюються обмеження щодо підписів ECDSA, квантової безпеки, можливих ризиків квантових комп'ютерів і більш вузької ролі пропозиції порівняно з рішеннями масштабування. Цей технічний огляд орієнтований на команди гаманців, розробників клієнтів, операторів доказувачів і користувачів, які оцінюють потенціал транзакцій із доказами для складної валідації Ethereum, поки EIP-8361 залишається чернеткою мережевої пропозиції, а не активним правилом консенсусу.

Основні висновки

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

Що таке докази дійсності транзакцій EIP-8361?

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

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

За стандартного симульованого допуску кожен вузол, що отримує транзакцію, може потребувати виконати цей префікс для визначення, чи має транзакція потрапити до його мемпулу. EIP-8361 пропонує альтернативу: доказувач виконує префікс один раз офчейн і створює криптографічний доказ, який показує, що він завершується результатом APPROVE і визначеним платником.

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

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

Станом на 6 серпня 2026 року EIP-8361 подано як чернетку pull request №12075 у категорії Standards Track Networking. Він не вводить новий тип транзакції і сам по собі не змінює консенсус Ethereum.

Як працює криптографічний доказ EIP-8361?

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

У спрощеній формі доказувач має показати, що:

Префікс валідації транзакції T, коли оцінюється за задекларованими припущеннями і залежностями, слідує правилам трасування EIP-8141 і завершується APPROVE та платником P відповідно до задекларованих умов.

Запропоновані публічні входи прив'язують доказ до п'яти елементів:

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

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

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

Як використовується вектор припущень у валідації транзакції?

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

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

Визначено два типи порівняння:

• EQ-припущення вимагають, щоб поточне значення стану дорівнювало значенню, задекларованому в доказі.
• GEQ-припущення вимагають, щоб поточне значення стану залишалося більшим або рівним задекларованому порогу.

Точний запис EQ доречний для хеша коду, nonce або гілки сховища, чий зміст змінюється при зміні базового значення. GEQ-запис корисніший для монотонних вимог, наприклад, перевірки, що у платника достатньо коштів для попередньої оплати.

Наприклад, якщо префікс валідації смарт-акаунта схвалює транзакцію лише тоді, коли баланс paymaster щонайменше 0,2 ETH, доказувач може зафіксувати GEQ-припущення з порогом 0,2 ETH. Вузол може продовжувати застосовувати доказ, доки баланс становить 0,2 ETH або більше. Не потрібен новий доказ щоразу, коли баланс збільшується або змінюється понад цей поріг.

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

Як працюють докази дійсності транзакцій за EIP-8361?

Запропонований процес валідації транзакції слідує впорядкованій серії перевірок.

1. Виконайте безстанні перевірки. Вузол перевіряє внутрішню дійсність транзакції і підтверджує, що список залежностей або підписів правильно сформований. Неправильно сформована транзакція відхиляється до дорогої верифікації доказу.
2. Верифікуйте доказ допуску. Вузол верифікує STARK за призначеним ключем верифікації. Невдача означає, що заявлене обчислення валідації не підтверджено.
3. Верифікуйте зовнішні залежності. Доказ може передбачати, що підписи або інші задекларовані залежності дійсні. Вузол перевіряє ці залежності окремо і підтверджує, що їх список відповідає комітменту хеша залежностей.
4. Перевірте умови дійсності. Вузол оцінює задекларовані умови, які можуть включати дедлайни, вікна слотів або епох, діапазони закінчення терміну дії або вимоги до nonce.
5. Порівняйте припущення з живим станом. Кожен запис EQ перевіряється на рівність, а кожен запис GEQ — на відповідність порогу.
6. Допустіть транзакцію. Коли всі перевірки успішні, вузол може прийняти і розповсюдити транзакцію без симулювання повного префіксу валідації.

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

Що відбувається при зміні стану Ethereum?

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

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

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

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

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

Чому доказ відкидається після включення до блоку?

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

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

Відповідно, доказ допуску:

• не міститься у блоці;
• не додається до calldata транзакції;
• не з'являється у квитанції;
• не стає частиною Merkle-дерева або кореня стану;
• не створює постійної зміни ончейн стану;
• не потребує збереження після включення або видалення транзакції.

Відкидання дозволяє уникнути постійних витрат calldata і зростання стану для інформації, яка вже виконала свою мережеву функцію. Сама транзакція залишається ончейн, але її тимчасовий доказовий конверт — ні.

Система доказів EIP-8361 vs. ZK-rollup validity proofs

EIP-8361 використовує технологію криптографічних доказів, але його доказ допуску не слід плутати з доказами дійсності, які використовують ZK-ролапи.

ZK-ролапи зазвичай використовують ZK-SNARK-и або ZK-STARK-и для доведення коректності пакетів транзакцій. Після прийняття доказу контрактом Layer 1 ролап може фіналізувати відповідний перехід стану без очікування періоду оскарження fraud proof, який використовують оптимістичні ролапи.

EIP-8361 не доводить пакет L2, не авторизує негайні виведення ролапу і не гарантує, що ланцюг L2 ніколи не потрапить у недійсний стан. Його доказ — тимчасовий мережевий артефакт про валідацію до включення.

Так само, хоча zero-knowledge proofs можуть підтвердити твердження без розкриття всіх даних свідка, EIP-8361 не є насамперед пропозицією про приватність. “Лаконічний доказ” і “zero knowledge” — пов'язані, але не взаємозамінні властивості.

Виведення з Layer 2 до Layer 1 можуть бути швидшими з доказами дійсності, оскільки ZK-ролапи не потребують періоду оскарження fraud proof, який використовують оптимістичні ролапи. Остаточний час виведення все одно залежить від генерації доказу, верифікації Layer 1, правил моста і фіналізації Ethereum. EIP-8361 не надає цього механізму виведення; його доказ підтримує допуск до мемпулу окремої транзакції фрейму EIP-8141, а не розрахунок пакета транзакцій Layer 2.

Як працюють fraud proofs в оптимістичних ролапах?

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

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

Ключова різниця — у часі і сфері застосування:

• Доказ дійсності доводить заявлене твердження до прийняття.
• Fraud proof дозволяє оптимістичне твердження, якщо його не оскаржено успішно.
• Доказ допуску EIP-8361 стосується політики мемпулу.
• Fraud proof ролапу стосується коректності переходу стану L2.

Технічні компроміси між повторним виконанням EVM і лаконічною верифікацією розглядаються у EIP-8361 vs. симуляція транзакції, включаючи ситуації, де витрати на генерацію доказу замінюють витрати на симуляцію вузлом.

EIP-8361, складна валідація акаунтів і постквантова безпека

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

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

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

Відповідальність творців транзакцій, гаманців, доказувачів і клієнтів суттєво відрізняється, як підсумовано у впливі EIP-8361 на гаманці, вузли і розробників.

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

Ризики й обмеження

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

Механізм також вводить кілька технічних ризиків:

Концентрація генерації доказу: Створення STARK може вимагати спеціалізованого ПЗ і значних обчислень. Якщо лише кілька сервісів можуть ефективно генерувати докази, гаманці можуть стати залежними від централізованої інфраструктури доказувачів.

Тиск на відмову в обслуговуванні: Верифікація доказу дешевша за повторення початкового обчислення, але не безкоштовна. Клієнтам потрібні сталі обмеження розміру доказу, ліміти peer rate і атрибуція невдач для запобігання атакам із заливанням вузлів недійсними або надмірними доказами.

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

Застарілість стану: Доказ може залишатися криптографічно правильним, поки його задекларовані умови не відповідають поточному стану. Вузли мають продовжувати повторно перевіряти A і C, доки транзакція залишається у пулі.

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

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

Чи є EIP-8361 також пропозицією Tapered Issuance Burn?

Деякі ранні обговорення пов'язували номер EIP-8361 із окремою пропозицією монетарної політики Ethereum під назвою Tapered Issuance Burn. Згодом цю пропозицію ідентифікували як EIP-8363, тоді як EIP-8361 стосується доказів дійсності транзакцій у категорії мережі. Пропозиції не пов'язані: EIP-8361 стосується допуску до мемпулу на основі доказів, тоді як Tapered Issuance Burn змінює економіку винагород консенсусу відповідно до активного балансу стейкінгу.

Висновок

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

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

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

Як ZK-ролапи використовують докази дійсності?

ZK-ролапи обробляють транзакції офчейн, групують їх у пакети і обчислюють доказ дійсності для кожного пакета. Доказ, зазвичай побудований із ZK-SNARK-ів, ZK-STARK-ів або поліноміальних комітментів, дозволяє контракту Ethereum перевірити, що перехід стану коректний, без повторного виконання кожної транзакції.

Чи гарантують докази дійсності, що ланцюг L2 не стане недійсним?

Докази дійсності запобігають прийняттю недійсного переходу стану L1-вузлом, якщо схема, контракт-верифікатор, криптографія і реалізація працюють правильно. Вони не усувають ризики, пов'язані з помилковим кодом, доступністю даних, мостами, секвенсерами, управлінням чи контролем оновлень.

Чому виведення ZK-ролапів зазвичай швидше?

ZK-ролапи можуть фіналізувати виведення після подання і верифікації доказу дійсності, без очікування періоду оскарження fraud proof, який використовують оптимістичні ролапи. Виведення все одно залежить від генерації доказу, подання пакета, правил моста і фіналізації Ethereum, тому “негайно” не завжди означає миттєво.

Як докази дійсності відрізняються від fraud proofs?

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

Чи завжди zero-knowledge proofs приховують дані транзакції?

Ні. Zero-knowledge proofs можуть підтвердити твердження без розкриття приватного свідка, але приватність залежить від того, які входи залишаються прихованими. Багато ZK-ролапів використовують ZK-докази переважно для масштабованої перевірки транзакцій, а не для повністю приватних транзакцій.

У чому різниця між ZK-SNARK-ами і ZK-STARK-ами?

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

Що перевіряє Merkle-доказ?

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

Чи знижують докази дійсності споживання ончейн ресурсів?

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

Чи знижують докази дійсності ризик атаки 51%?

Не прямо. Докази дійсності захищають коректність перевірених переходів стану Layer 2, тоді як атака 51% стосується контролю над консенсусом Ethereum і вибором форку. Механізми вирішують різні ризики безпеки.

Чи є докази EIP-8361 такими ж, як докази ZK-ролапів?

Ні. Докази ZK-ролапів перевіряють пакети транзакцій Layer 2 і підтримують фінальність стану та виведення. Докази EIP-8361 підтримують допуск до мемпулу окремих транзакцій фрейму EIP-8141, залишаються поза блоком і відкидаються після включення або видалення.

Застереження

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