Чому Ethereum потрібен ZK-VM: остаточний шлях масштабування

Автор: Ebunker

Серед багатьох підходів до масштабування Ethereum, ZK є найскладнішим і водночас найважливішим напрямком.

Якщо подивитися на всю мережу, Vitalik Buterin та Ethereum Foundation роблять найбільшу ставку саме на ZK. ZK трохи схожий на наймолодшого сина в родині Ethereum, в якого вкладено найбільше зусиль, але майбутнє якого найбільш невизначене.

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

Отже, чому Ethereum так наполегливо потребує ZK-VM?

Відповідь дуже проста: задля підвищення продуктивності, а не ціною безпеки.

Вузьке місце підвищення продуктивності: загальна верифікація та ліміт GAS

Раніше ми згадували, що найбільш очевидний спосіб підвищити продуктивність Ethereum — це збільшити ліміт GAS, тобто зробити блоки більшими.

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

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

Якщо ліміт GAS значно підвищити, обсяг обчислень для кожного вузла також різко зросте.

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

Ethereum після ZK: від “загальної повної перевірки” до “загальної одноразової перевірки”

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

Особливість ZK у тому, що створення доказу повільне, але перевірка — надзвичайно швидка. Тому вузлам потрібно лише один раз перевірити правильність доказу, не повторюючи виконання всіх транзакцій у блоці.

Це означає, що Ethereum може значно підвищити ліміт GAS без істотного збільшення навантаження на вузли.

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

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

Після ZK ви все ще подаєте заявку на відпустку (відправка транзакції), система бачить, що у вас залишилися дні відпустки, і одразу повідомляє всім керівникам: “ця людина має відпустку”, і керівники повністю довіряють системі (ZK), тому схвалення відбувається набагато швидше (загальна одноразова перевірка).

Ось чому Ethereum прагне до впровадження ZK.

Криптографічні виклики та приклади

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

Brevis protocol, згаданий дослідником Ethereum Foundation Джастіном, є одним із провідних прикладів у цій галузі.

Brevis спеціалізується на ZK-VM, а його новітня технологія Pico Prism — одне з найшвидших рішень для генерації ZK-доказів за заданих умов.

Згідно з тестовими даними, при поточному розмірі блоку Ethereum у 45M GAS, Brevis із використанням 64 RTX 5090 GPU може завершити 99,6% доказів блоку за 12 секунд, з яких 96,8% блоків можуть бути доведені за 10 секунд.

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

Хоча більш потужні GPU (наприклад, H200 або B200) можуть генерувати докази ще швидше, це значно підвищить поріг входу. Поточний дизайн Brevis якраз вкладається у ці обмеження.

Чому “10-секундне покриття” також надзвичайно важливе? Тому що MEV-блоки зазвичай генеруються за 1–3 секунди, а додаткові 10 секунд на доказ якраз заповнюють 12-секундний інтервал між блоками.

Підсумок: логіка шляху ZK для Ethereum

Щоб прискорити підвищення продуктивності L1, Ethereum повинен підвищити ліміт GAS;

Щоб безпечно підвищити ліміт GAS, необхідно впроваджувати ZK;

А щоб елегантно впровадити ZK (генерація доказу за 10 секунд, вартість обладнання нижче 100 тисяч доларів), потрібні спільні зусилля криптографічної спільноти та криптоекосистеми.

ZK — це найскладніший, але й найвизначальніший напрямок у масштабуванні Ethereum.

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