«Секундна» еволюція Ethereum: від швидкого підтвердження до стиснення розрахунків, як Interop усуває час очікування?

Якщо ви часто переміщаєтесь між Base, Arbitrum або Optimism, ви напевно відчували певний «розрив» у досвіді.

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

Сортування L2 → відправлення на L1 → досягнення консенсусу на L1 та фінальна фіксація (Finality), загалом, у поточній архітектурі Ethereum фінальна фіксація на L1 зазвичай потребує двох Epoch (близько 13 хвилин). Це, безумовно, необхідно для безпеки, але для взаємодії (Interop) це надто повільно.

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

Саме на цьому тлі, у дорожній карті Ethereum Interop на етапі прискорення (Acceleration) чітко визначено три напрями тісної співпраці: правило швидкого підтвердження (Fast L1 Confirmation Rule), скорочення часу L1 Slot (Shorter L1 Slots), скорочення циклу фінального розрахунку на L2 (Shorter L2 Settlement). 

Можна сказати, що це не розрізнена оптимізація, а системна перебудова навколо «підтвердження, ритму та розрахунку».

1. Правило швидкого підтвердження: дати системі «довірену відповідь» до фінальної фіксації

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

Простіше кажучи, навіть якщо транзакція вже включена до блоку, системі потрібно чекати досить довго, щоб упевнитися, що вона не буде перебудована або відкочена. Наразі, щоб транзакція вважалася остаточною і не могла бути відкочена, потрібно приблизно два Epoch (близько 13 хвилин), а для більшості фінансових сценаріїв на ланцюгу це надто довго. 

Чи можемо ми дати додаткам і міжланцюговим системам «достатньо швидкий і достатньо надійний» сигнал підтвердження до настання Finality? Саме це і є завданням Project #4 у дорожній карті Ethereum Interop: Fast L1 Confirmation Rule (правило швидкого підтвердження).

Його основна мета дуже проста — дозволити додаткам і міжланцюговим системам отримати «сильний і перевіряємий» сигнал підтвердження L1 протягом 15–30 секунд, не чекаючи повних 13 хвилин до фінальної фіксації.

З точки зору механізму, правило швидкого підтвердження не вводить новий процес консенсусу, а повторно використовує голосування attester у кожному slot у системі PoS Ethereum. Коли певний блок вже на ранніх slot накопичив достатньо багато і достатньо розподілених голосів верифікаторів, навіть якщо він ще не досяг фінальної фіксації, його можна вважати «дуже малоймовірним для відкоту за розумної моделі атаки».

Простіше кажучи, цей рівень підтвердження не замінює Finality, а надає сильне підтвердження, офіційно визнане протоколом до настання Finality. Для Interop це особливо важливо: міжланцюгові системи, Intent Solver і гаманці більше не повинні сліпо чекати фінальної фіксації, а можуть безпечно переходити до наступної логіки протягом 15–30 секунд на основі сигналу підтвердження на рівні протоколу.

Наразі попереднє підтвердження (Preconfirmation), яке активно просувається у наративі Based Rollup, виконує важливу інженерну перехідну роль у цьому напрямку. Його логіка дуже проста, як випливає з назви, уявіть: 

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

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

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

2. Скорочення L1 Slot: прискорення «серцебиття» Ethereum

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

Якщо швидке підтвердження — це «розписка» до досягнення консенсусу, то скорочення часу L1 Slot — це пряме скорочення «циклу розрахунків» у бухгалтерській книзі. У дорожній карті Interop проміжна мета Project #5 дуже чітка: скоротити час Slot у основній мережі Ethereum з поточних 12 секунд до 6 секунд.

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

Вплив на реальний досвід користувача також дуже прямий: включаючи L1-взаємодію (наприклад, переказ ETH) — підтвердження відчувається швидше, ритм відправлення стану L2 на L1 стає щільнішим, а поєднання коротших slot із правилом швидкого підтвердження фактично створює «майже реальний зворотний зв'язок на ланцюгу», що дозволяє DApp, гаманцям і міжланцюговим протоколам створювати досвід підтвердження на рівні секунд.

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

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

Звичайно, подвоїти «серцебиття» — справа не з легких. Кілька робочих груп Ethereum Foundation одночасно просувають цей складний інженерний проєкт:

• Аналіз мережі: дослідницька команда (включаючи Maria Silva та інших) проводить ретельний аналіз даних, щоб переконатися, що коротші Slot не призведуть до серйозних ризиків перебудови (Reorg) через затримки мережі або не створять централізаційного тиску на домашні вузли з низькою пропускною здатністю;
• Реалізація клієнта: це повна перебудова як консенсусного, так і виконуючого шару. Варто зазначити, що ця робота незалежна від EIP-7732 (нативне розділення стейкерів і будівельників — ePBS), тобто незалежно від прогресу ePBS, план прискорення серцебиття може просуватися самостійно;

Загалом, коли 6-секундний Slot поєднується з правилом швидкого підтвердження, Ethereum дійсно може отримати «майже реальний зворотний зв'язок на ланцюгу», дозволяючи dApp і гаманцям створювати безпрецедентний досвід підтвердження на рівні секунд.

3. Скорочення циклу розрахунків L2: активи «миттєво доступні»

У дорожній карті Interop Project #6: Shorter L2 Settlement — це найбільш суперечлива, але й найбільш перспективна частина.

У поточній архітектурі Optimistic Rollup зазвичай покладається на 7-денний період оскарження, а навіть ZK Rollup обмежений ритмом генерації та перевірки доказів. Справедливо кажучи, такий дизайн бездоганний з точки зору безпеки, але на рівні взаємодії створює реальну проблему:

Активи та стани «заблоковані у часі» між ланцюгами. Це не лише підвищує вартість міжланцюгових операцій, а й значно збільшує навантаження на Solver щодо ребалансування, що врешті-решт відображається у вищих витратах для користувачів. Тому скорочення циклу розрахунків вважається одним із ключових важелів для масштабного впровадження Interop. Основні інженерні напрями наразі включають (детальніше читайте у статті ZK Route «Dawn Moment»: Is the Ethereum Endgame Roadmap Accelerating?):

• ЗК-реальні докази: завдяки апаратному прискоренню та розвитку рекурсивних доказів час генерації доказів скорочується з хвилин до секунд;
• Швидші механізми розрахунків: наприклад, впровадження безпечної моделі розрахунків 2-out-of-3;
• Спільний розрахунковий шар: дозволяє кільком L2 здійснювати зміну стану під єдиною розрахунковою семантикою, а не за схемою «виведення — очікування — поповнення»;

Звичайно, у дискусії про Interop є одне ключове питання: якщо для досягнення швидшого міжланцюгового підтвердження скоротити період оскарження з традиційних 7 днів до 1 години, чи не залишить це простір для зловмисників?

Теоретично це занепокоєння не безпідставне. На відміну від «сильної цензури» (колективне зловживання вузлами-верифікаторами), на практиці варто остерігатися саме такого м'якого цензурування, що здійснюється блок-білдерами: зловмиснику не потрібно контролювати консенсус, достатньо постійно перевищувати ціну захисника, щоб критична транзакція не потрапила до ланцюга. 

Цікаво, що наразі єдиний системний економічний аналіз таких сценаріїв — це стаття Offchain Labs, опублікована у лютому 2025 року «Economic Censorship Games in Fraud Proofs». У ній розглядаються три моделі — від найпесимістичнішої до відносно оптимістичної:

• Модель G¹: вміст блоку повністю визначає той, хто запропонував найвищу ціну;
• Модель G¹ₖ: частина верифікаторів завжди локально будує блоки;
• Модель Gᵐ: кілька верифікаторів разом визначають вміст блоку, і достатньо, щоб хоча б один з них вибрав транзакцію захисника.

На практиці, оскільки верифікатори можуть пропускати слоти (miss slots), деякі дизайни навіть можуть деградувати до більш песимістичного сценарію G¹, тому у статті аналіз проводиться з найгіршої позиції. 

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

Призначення цієї критичної транзакції дуже чітке: як тільки вона потрапляє до ланцюга, період оскарження автоматично подовжується з 1 години до традиційних 7 днів. Наприклад, якщо захисник виявляє аномалію стану L2, йому не потрібно виконувати всі складні перевірки за 1 годину, достатньо успішно подати спеціальну транзакцію на L1, яка, як сигнал тривоги, миттєво подовжує період оскарження до 7 днів.

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

Кількісні результати у статті також дуже наочні: якщо потужний зловмисник готовий витратити 100 millions доларів на постійну цензуру, то:

• протягом 1-годинного вікна захиснику достатньо мати бюджет на Gas у 33 millions доларів для контратаки;
• якщо вдасться активувати механізм відкладення, подовживши період оскарження до 7 днів, витрати захисника на контратаку можуть різко впасти до близько 200 тисяч доларів;

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

Саме така різниця у співвідношенні витрат на атаку та захист (Cost to Attack vs. Cost to Defend) гарантує, що навіть при значному скороченні циклу розрахунків Ethereum зберігає високу економічну стійкість. 

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

На завершення

Можливо, хтось подумає: навіщо так наполегливо оптимізувати ці кілька секунд чи хвилин затримки?

У гікову епоху Web3 ми звикли чекати, навіть вважаємо, що «очікування» — це премія, яку потрібно платити за децентралізацію. Але на шляху Web3 до масового користування користувачі не повинні і не мають перейматися, на якому ланцюгу вони працюють, і вже точно не повинні рахувати логіку фінальної фіксації L1.

Швидке підтвердження, 6-секундне «серцебиття» і асиметричний захисний механізм по суті роблять одне — стирають змінну «час» із сприйняття користувача.

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