Ізраїль зараз дійсно готується до серйозних змін, основне питання — як буде вирішено проблему EVM.

Останній виклик, який висунув Віталік, дуже цікавий. До цього часу розробники Ethereum надавали перевагу тому, щоб не торкатися безпосередньо EVM кожного разу, коли потрібна нова криптографічна операція, а натомість жорстко закодовували попередньо скомпільовані контракти на рівні протоколу. Це був своєрідний обхідний шлях. Але Віталік вважає, що це не є корінним рішенням.

Він запропонував два підходи. Перший — спростити дерево стану, перейшовши з нинішньої шестикутної структури до більш простої двійкової (EIP-7864). Це зменшить довжину Меркле-дерева в чотири рази, а обсяг даних для перевірки у легких клієнтів значно зменшиться. Другий — більш радикальний — замінити саму EVM архітектурою RISC-V. Логіка проста — системи ZK-доказів вже використовують RISC-V, тоді чому віртуальна машина має залишатися на іншій мові? Відсутність рівня перекладу автоматично підвищує ефективність.

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

Загалом, це пов’язано з переосмисленням ролі L2 і Ethereum. Після того, як Віталік поставив під сумнів необхідність окремої дорожньої карти для L2, ці рішення почали рухатися до більш незалежної ролі у екосистемі. Голова Polygon зазначив, що справжнє завдання — створити унікальний простір для кожного L2, а не просто масштабувати.

Чи станеться це насправді? Віталік визнав, що наразі немає широкої згоди щодо заміни EVM. Реформа дерева стану — більш зріла ідея (є конкретні проєкти і команда), тоді як перехід на RISC-V ще на рівні дорожньої карти. Але він зробив цікаву заяву: Ethereum вже один раз замінив свій двигун під час переходу на «Мердж» (Merge), і у майбутньому можна зробити ще близько чотирьох таких змін — щодо дерева стану, спрощення консенсусу, перевірки ZK-EVM і заміни віртуальної машини.

Оновлення Glimmer планується випустити вже цього року, а потім — Hegatha. Деталі ще не визначені, але основними темами будуть реформа дерева стану і оптимізація рівня виконання.

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