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

Оригінальна назва: «Чому Ethereum потребує ZK-VM: остаточний шлях до масштабування»

Оригінальний автор: Ebunker 中文

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

Оглядуючи всю мережу, V 神 та фонд Ethereum роблять найбільше ставок на ZK. ZK трохи схожий на найменшого сина в родині Ethereum, в якого вклали найбільше зусиль, але майбутнє якого є найменш зрозумілим.

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

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

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

Проблеми з підвищенням продуктивності: верифікація всіх учасників та ліміт GAS

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

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

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

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

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

ZK-версія Ethereum: від «все перевірено» до «все перевіряється один раз»

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

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

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

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

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

Після ZK, ви все ще подаєте заявку на відпустку (відправляєте транзакцію), система виявляє, що у вас є залишок відпустки, і прямо повідомляє всім керівникам «цей співробітник має відпустку», і керівники повністю вірять, що система не помиляється (ZK), тоді затвердження від керівників відбувається швидше (всі перевіряють).

Це причина, чому Ethereum має перейти на ZK.

Виклики та випадки криптографії

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

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

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

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

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

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

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

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

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

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

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

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

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