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

Автор: imToken

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

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

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

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

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

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

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

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

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

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

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

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

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

Зараз, наприклад, концепція Preconfirmation, популяризована у рамках Based Rollup, виконує цю роль — вона логічно проста: уявімо ситуацію:

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

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

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

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

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

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

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

Це безпосередньо впливає на досвід користувача: швидше підтвердження для ETH-переведень, швидше оновлення стану L2 у L1, і у поєднанні з правилом швидкого підтвердження — майже «реальний час» зворотного зв’язку у мережі. Це дозволить DApps, гаманцям і протоколам крос-ланцюгової взаємодії створювати «секундний досвід підтвердження».

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

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

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

Загалом, поєднання 6-секундних слотів і правил швидкого підтвердження дасть Ethereum можливість отримати «майже миттєвий» зворотній зв’язок, що дозволить створювати у мережі унікальний досвід підтвердження у секунду.

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

У рамках дорожньої карти Interop проект #6 — Shorter L2 Settlement — це найспірніша і найфантастичніша частина.

Зараз Optimistic Rollup зазвичай залежить від 7-денного Challenge Period, а ZK Rollup — від швидкості генерації і перевірки доказів. Це безперечно безпечно, але створює проблему: активи і стан «застрягають» між ланцюгами. Це підвищує вартість крос-ланцюгових операцій і збільшує навантаження Solver’ів, що відображається у вищих комісіях.

Зменшення циклу розрахунків — ключовий фактор масштабування Interop. Основні напрямки:

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

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

Теоретично, так. Але реальні дослідження, зокрема робота Offchain Labs «Economic Censorship Games in Fraud Proofs» (лютий 2025), показують, що найгірший сценарій — це коли блоки визначаються найвищим платником, або частина валідаторів формують блок локально, або кілька валідаторів спільно вирішують, що саме включити.

У реальності, через можливість пропуску слотів і інші фактори, найгірший сценарій — модель G¹, і дослідження пропонують захист у вигляді «відстрочки»: якщо валідатор виявляє аномалію, він може подати спеціальну транзакцію, яка автоматично подовжить Challenge Period з 1 години до 7 днів. Це створює «асиметрію» у витратах: атакуючий має витратити значно більше, щоб зірвати процес.

За підрахунками, якщо зловмисник має 100 мільйонів доларів, то для атаки потрібно:

• у 1-годинному вікні — близько 33 мільйонів доларів на Gas;
• при активації «відстрочки» — витрати зменшуються до приблизно 20 тисяч доларів.

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

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

( Підсумки

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

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

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

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