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

Перша частина плану стосується дерева стану Ethereum. Якщо спростити, це як індексна система, через яку система постійно шукає дані. Проблема в тому, що поточна структура — та сама шестишляхова Keccak Merkle tree — занадто громіздка. EIP-7864, який пропонує Vitalik, замінює її на бінарне дерево. Замість вибору з шести напрямків, ви просто вибираєте ліво або право. Результат? Довжина merkle tree скорочується в чотири рази. Для легких клієнтів це означає значне зниження вимог до пропускної здатності.

Але це ще не все. Vitalik хоче змінити й саму хеш-функцію. На столі два кандидати: Blake3, який дає стабільне прискорення, і Poseidon, який теоретично може збільшити ефективність доказів у десятки разів, хоча безпека все ще перевіряється. Цей план фактично замінює Verkle Trees, які роками обговорювалися спільнотою, але втратили популярність через загрозу квантових обчислень.

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

Vitalik заявив, що дерево стану та віртуальна машина разом становлять понад 80% обмежень доведення Ethereum. Без цих змін масштабування в епоху ZK просто не рушитиме з місця.

Але не всі згідні. Команда Arbitrum Offchain Labs опублікувала детальне технічне заперечення. Їхня позиція: RISC-V добре для ZK-доказів, але не обов'язково добре як формат для контрактів. Вони провели розмежування між набором інструкцій для доставки (dISA) і набором інструкцій для доведення (pISA). На їхню думку, це не має бути одне й те саме. Вони пропонують WebAssembly для рівня контрактів, а потім компіляцію в RISC-V для доказів. Вже запустили прототип на Arbitrum, і це працює. Плюс вони вказали на ризик: технології ZK змінюються швидко, і якщо зараз зафіксувати RISC-V на L1, що буде через два роки?

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

Сам Vitalik визнав, що консенсусу щодо заміни EVM ще немає. Реформа дерева станів далі просунулася — EIP-7864 вже має конкретний проект. Але заміна на RISC-V? Це поки що на рівні дорожної карти. Хард-форк Glamsterdam очікувався на першу половину 2026 року, за ним Hegota. Конкретні деталі ще не затверджені, але реформа дерева стану та оптимізація рівня виконання — це визначені напрями.

Історія Ethereum завжди була про те, що можливо. Від переходу PoW до PoS, від L1 до Rollup — система вже довела, що готова розбирати двигуни на висоті десяти тисяч метрів. Цього разу йдеться про глибші речі: не додавання функцій, а переливання самого фундаменту. Чи це ретельно спланований ремонт, чи яма, що ускладнюється? Відповідь з'явиться не раніше 2027 року. Але одне ясно: Ethereum не збирається бути старою системою з патчами. Сама ця суперечка про те, як розібрати патчі та який двигун встановити — можливо, цінніша за будь-який висновок.