Віталік Ознайомлює Ethereum EVM та State Tree: Радикальна Трансформація Попереду

Останні тижні спричинили глибокі дискусії в спільноті Ethereum щодо найважливішої частини архітектури блокчейну. У першому кварталі 2025 року Віталік Бутерін опублікував всебічний аналіз, як слід змінити Ethereum з основи. Його теза проста: EVM і структура станового дерева недостатні для майбутнього Ethereum у часи доказів нульової знаності. Професійна спільнота розгортала реакцію — від підтримки до прямого заперечення основних пропозицій.

Чому потрібно змінювати EVM? Величезне вузьке місце у продуктивності

Щоб зрозуміти терміновість змін, потрібно знати, де зараз проблема. Більше десяти років EVM (Ethereum Virtual Machine) був центром екосистеми Ethereum. Але з ростом мережі та появою передових технологій, таких як ZK-докази, його обмеження стають очевидними.

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

Два основні кроки: структурна перебудова станового дерева та повна заміна EVM

Віталік пропонує два взаємопов’язані рішення, які не слід розглядати окремо. Кожне з них вирішує різні аспекти проблеми продуктивності.

Перший крок: заміна станового дерева на бінарну структуру

Зараз Ethereum використовує складну структуру під назвою «hexary Keccak Merkle Patricia tree» — назва відображає її складність. Пропозиція EIP-7864 має на меті змінити її на простішу бінарну дерево.

Практичний ефект значний. У поточній системі для визначення конкретної транзакції або балансу потрібно робити багато рішень на кожному рівні дерева — шість можливих напрямків у кожному вузлі. У бінарному дереві — лише два варіанти: ліворуч або праворуч. Результат очевидний: довжина Меркле-ветки зменшується до чотирьох разів.

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

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

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

Другий крок: перенесення EVM на архітектуру RISC-V

Другий пропозиція більш масштабна і спірна: довгострокова заміна EVM на архітектуру інструкцій RISC-V.

RISC-V — відкритий, енергоефективний набір інструкцій, що виник із академічних досліджень і зараз став стандартом у системах доказів нульової знаності. Логіка Віталіка проста: якщо генератори ZK-доказів говорять мовою RISC-V, чому віртуальна машина блокчейну має говорити іншою мовою і додавати проміжний рівень перекладу? Вилучити зайвий шар — і підвищити ефективність.

Технічна реалізація не така складна, як здається. Інтерпретатор RISC-V можна написати за кілька сотень рядків коду. Для Віталіка це правильна філософія дизайну для блокчейну: простота, орієнтована на продуктивність.

План переходу має три етапи:

1. Використовувати RISC-V для запуску попередньо скомпільованих контрактів. 80% існуючих контрактів можна переписати на RISC-V.

2. Дозволити розробникам безпосередньо розгортати контракти на новій VM. Новий механізм і EVM працюватимуть паралельно, забезпечуючи поступовий перехід.

3. Згодом видалити EVM — але не зникне. Його конвертують у смарт-контракт, що працює на RISC-V, забезпечуючи повну зворотну сумісність. Образ Віталіка поетичний: кермо залишиться тим самим, але двигун під ним тихо зміниться.

Основний вузький момент: без змін у EVM — немає масштабованості

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

У часи масштабування на основі ZK ця архітектурна обмеженість стане «ланцюгом на нозі». Ethereum прагне еволюціонувати поза межі патчів.

Контрпропозиція: виклик Arbitrum RISC-V стратегії

Але історія не така проста. У листопаді минулого року команда Offchain Labs — головні розробники Arbitrum — опублікувала детальний технічний заперечення.

Їх головне зауваження — нюансоване і важливе: так, RISC-V ідеально підходить для ZK-доказів, але не слід робити його «форматом виконання» для смартконтрактів. Вони зробили важливий розподіл: «інструкційний набір доставки» (dISA) і «інструкційний набір доказу» (pISA) не обов’язково мають збігатися.

Їхня аналогія — складське приміщення має найвищу ефективність з вилкою, але це не означає, що кур’єр має використовувати вилку для доставки. Кожен інструмент має свій контекст.

Для рівня виконання контрактів Offchain Labs пропагують WebAssembly (WASM) як кращий варіант. Їхня технічна логіка міцна:

1. WASM має доведену високу ефективність на стандартному обладнанні. Більшість вузлів Ethereum не працює на RISC-V спеціалізованих чипах, і емуляція додасть великих накладних витрат.

2. WASM має зрілий механізм типобезпечної верифікації, доведений у мільйонах середовищ виконання.

3. Екосистема інструментів WASM вже сформована, з широкою підтримкою розробників.

Що ще важливіше — вони не лише теоретизують. Offchain Labs вже створили прототип: використовують WASM для контрактів, потім компілюють їх у RISC-V для ZK-доказів. Кожен рівень виконує свою спеціалізовану задачу без конфліктів.

Вони також підкреслюють ризик: технологія ZK швидко розвивається. Сам RISC-V за останні роки перейшов із 32-бітної до 64-бітної архітектури. Якщо зараз зафіксувати RISC-V для Ethereum L1, що робити, якщо з’явиться краща архітектура доказів за два роки? Беттинг на рухому ціль — не стиль Ethereum.

Більший промисловий зсув: Ethereum і Layer 2 віддаляються

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

Минулого місяця Віталік висловив скепсис щодо необхідності «спеціальної дорожньої карти Layer 2 для Ethereum». Це викликало глибоку рефлексивну реакцію операторів Layer 2.

Бен Фіш, CEO Espresso Systems, пояснив у медіа: початкова мета Layer 2 — допомогти Ethereum масштабуватися. Але тепер, коли Ethereum сам прагне масштабування, позиціонування Layer 2 має змінитися. Це вже не допоміжний шар, а більш незалежна екосистема.

Оператори Layer 2 не панікують. Вони активізувалися у переорієнтації. Співзасновник OP Labs описав Layer 2 як «незалежні сайти», тоді як Ethereum — стандарт періодичних розрахунків. Прямо висловився керівник Polygon: головна проблема — не лише масштабування, а й створення спеціалізованого простору для справжніх кейсів — наприклад, платіжної інфраструктури.

Інакше кажучи, цей великий технічний зсув у виконанні Ethereum відображає ширший структурний тренд: Ethereum повертається під контроль власних ключових компетенцій, тоді як Layer 2 або рухаються вперед, або остаточно знаходять свою raison d’être.