Що таке EIP-8361? Докази валідності Ethereum: пояснення

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

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

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

• EIP-8361 стандартизує дані доказу валідності транзакцій для peer-to-peer розповсюдження. Frame-транзакція може містити STARK, що підтверджує, що її префікс валідації досягає схваленого стану.

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

• Доказ залишається поза консенсусом. Він транспортується разом із транзакцією, використовується для допуску в mempool і відкидається, коли більше не потрібний.

• Дизайн підтримує складну валідацію смарт-акаунтів. Наприклад: правила мультипідпису, альтернативні системи підпису, paymaster-и і авторизацію з доказами.

• EIP-8361 залишається драфтом. Це не активоване оновлення і не слід плутати з EIP-7701, EIP-7702, доказами валідності ролапів чи пропозиціями щодо винагород за стейкінг.

Що таке EIP-8361?

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

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

Пропозиція відповідає на конкретне питання:

Як вузол може безпечно допустити транзакцію, чия авторизація є дорогою у виконанні, без необхідності для кожного peer повторювати ці обчислення?

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

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

Чому складна валідація транзакцій Ethereum є проблематичною

Звичайний зовнішньо керований акаунт (EOA) контролюється приватним ключем і відповідним відкритим ключем. Акаунт авторизує транзакцію підписом ECDSA, а транзакція визначає поля, такі як nonce відправника, адреса призначення, вартість, chain ID, ліміт газу і ціну газу чи параметри комісії EIP-1559.

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

Смарт-акаунти створюють ширшу поверхню для валідації. Замість одного приватного ключа смарт-акаунт може використовувати:

• кілька відкритих ключів;

• ліміти витрат;

• сесійні ключі;

• делеговані контракти;

• правила paymaster-а;

• постквантові підписи;

• умови відновлення;

• докази з нульовим розголошенням;

• авторизаційний код для застосунку.

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

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

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

Як працюють proof-carrying транзакції EIP-8361

EIP-8361 пропонує два шляхи допуску frame-транзакції EIP-8141:

1. Симульований допуск: вузол виконує префікс валідації напряму.

2. Допуск із доказом: вузол перевіряє STARK, що підтверджує схвалення префіксу валідації.

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

1. Транзакція визначає свою логіку валідації

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

Префікс валідації може викликати смарт-контракт, пов’язаний із відправником, або інший делегований контракт. Такий контракт може перевіряти підписи, дозволи, баланси, умови закінчення терміну дії чи інші правила перед викликом операції APPROVE.

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

2. Доказувач виконує префікс валідації

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

• підпис відповідає відповідному відкритому ключу;

• акаунт відправника має достатньо коштів;

• баланс paymaster-а перевищує потрібну вартість;

• слот сховища контракту містить очікуваний дозвіл;

• chain ID відповідає потрібній мережі Ethereum;

• nonce запобігає повторним атакам;

• код валідації завершується схваленням.

Доказувач створює STARK, який фіксує відповідну транзакцію, залежності, припущення, платника і умови валідності.

3. Доказ декларує припущення стану

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

Умова рівності може визначати, що хеш коду контракту, nonce або значення сховища має точно співпадати із заявленим значенням. Умова “більше або дорівнює” може визначати, що баланс акаунта має залишатися вище мінімуму.

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

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

4. Вузли перевіряють STARK

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

Сучасні системи доказів можуть створювати докази, що швидше перевіряються, ніж повторне виконання оригінальних обчислень. Один доказ може замінити повторну симуляцію багатьма peer-ами, зменшуючи надмірні обчислення у peer-to-peer мережі.

Це не означає, що створення доказу є дешевим. Генерація STARK може вимагати значних обчислень, пам’яті і спеціалізованого ПЗ. Пропозиція переміщує обчислення, а не ліквідує їх.

5. Транзакція потрапляє у mempool

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

Доказ залишається метаданими peer-to-peer. Він не додається у calldata транзакції, не зберігається розгорнутим смарт-контрактом, не записується у стан акаунта і не включається у Merkle root блоку.

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

Що доводить доказ валідності EIP-8361?

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

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

Ця різниця важлива:

• EIP-8361 доводить валідацію, пов’язану з допуском.

• Доказ валідності ролапу доводить один або кілька офчейн переходів стану.

• Доказ Merkle доводить включення у автентичну структуру даних.

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

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

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

EIP-8361 проти доказів валідності ZK-ролапів

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

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

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

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

Докази валідності EIP-8361 проти fraud proofs

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

Системи доказів валідності діють навпаки: новий комітмент стану приймається лише після підтвердження криптографічного доказу коректного виконання. Це часто дозволяє швидше знімати кошти, оскільки користувачам не потрібно чекати на період оскарження fraud proof.

Однак стверджувати, що докази валідності завжди “більш безпечні”, ніж fraud proofs, — надто узагальнено. Ключові відмінності включають складність доказувача, безпеку верифікатора, доступність даних, довірені налаштування, припущення щодо спору і зрілість впровадження.

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

EIP-8361 проти делегації акаунтів за EIP-7702

EIP-7702 дозволяє існуючим EOA встановлювати індикатор делегації у полі коду, щоб виклики до акаунта виконували код із призначеного смарт-контракту. Він ввів транзакцію типу 4, що містить authorization_list.

Кожен authorization tuple включає:

• chain_id;

• адресу делегованого контракту;

• nonce акаунта;

• поля підпису.

Авторизація підписується приватним ключем EOA. Підписувач може відрізнятися від tx.origin, і одна транзакція може містити авторизації від кількох EOA. Кожна авторизація може оновити відповідний індикатор делегації акаунта перед звичайним виконанням транзакції.

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

EIP-7702 також створює питання безпеки. Chain ID із нульовим значенням може зробити авторизацію дійсною на різних ланцюгах, а nonce і підписані поля допомагають обмежити повторні атаки. Делегований код може впливати на припущення щодо tx.origin, незавершених транзакцій, сховища і балансів акаунта.

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

EIP-8361 проти нативної абстракції акаунтів за EIP-7701

EIP-7701 був створений 1 травня 2024 року як пропозиція щодо нативної абстракції акаунтів. Він розділив обробку транзакцій на етапи валідації, виконання і пост-операцій та запропонував новий тип транзакції EIP-2718.

Його дизайн використовував нативну адресу entry-point протоколу 0x7701, рольові опкоди, окрему валідацію відправника і paymaster-а, а також оплату газу під контролем контракту. Пропозиція не вимагала окремого потоку ERC-4337 bundler для свого нативного типу транзакції.

EIP-7701 був відкликаний, оскільки його замінив EIP-8141 — не просто позначений як “Stagnant”. Опублікована специфікація прямо вказує причину відкликання. Твердження, що EIP-7701 зараз вимагає контракти у форматі EOF, також не є частиною фінальної специфікації.

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

EIP-2718 забезпечує типізовану оболонку транзакції, яку використовують такі пропозиції, як EIP-7701, EIP-7702 і EIP-8141. Він визначає транзакцію як TransactionType || TransactionPayload, де тип транзакції визначає, як слід інтерпретувати непрозорий payload. Включення типу у підписані дані також зменшує ризик повторного підпису між типами.

Практичний вплив на гаманці, вузли і розробників

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

Розробники вузлів мають впровадити:

• транспортування доказу через peer-to-peer з’єднання;

• версійовані ключі перевірки;

• ліміти розміру доказу;

• перевірки припущень і залежностей;

• ліміти на peer;

• видалення застарілих доказів;

• резервну поведінку симуляції.

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

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

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

Питання безпеки і обмеження

EIP-8361 вводить кілька питань безпеки.

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

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

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

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

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

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

Що не пропонує EIP-8361

Декілька заявлених тверджень належать до інших пропозицій і не мають відношення до EIP-8361.

EIP-8361 не:

• визначає 18-місячний перехідний період;

• скасовує мінімальний прибуток від стейкінгу;

• обмежує винагороди валідаторам;

• віднімає винагороди при наближенні стейкінгу до 50%;

• створює ринкову рівновагу стейкінгу;

• вводить список авторизації EIP-7702;

• вводить нативну точку входу EIP-7701;

• створює новий тип транзакції EIP-2718;

• гарантує приватність;

• фіналізує батчі ZK-ролапу;

• замінює fraud proofs;

• скасовує договірні чи пов’язані права користувачів.

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

Висновок

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

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

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

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

Чи створює EIP-8361 новий тип транзакції?

Ні. Він застосовує допуск із доказами до frame-транзакцій EIP-8141. EIP-2718 забезпечує загальну типізовану оболонку транзакції, але EIP-8361 не вводить новий envelope транзакції.

Чи є докази EIP-8361 доказами з нульовим розголошенням?

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

Чи може один доказ охоплювати кілька транзакцій?

Системи доказів можуть агрегувати обчислення чи використовувати рекурсивні докази, а ролапи можуть стискати кілька доказів транзакцій в один. Поточний дизайн EIP-8361 зосереджений на допуску конкретної frame-транзакції, а не на стандартизації агрегації батчів транзакцій.

Чи зменшує EIP-8361 комісії газу?

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

Чим EIP-8361 відрізняється від EIP-7702?

EIP-7702 дозволяє EOA делегувати виконання коду через підписані авторизаційні tuples. EIP-8361 пропонує доказову схему допуску транзакцій із дорогою програмованою валідацією.

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

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