Ethereum має змінити двигун

Публікація: Сірий лангуст, Deep Tide TechFlow

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

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

1 березня Віталік Бутерін у X опублікував довгий пост, який остаточно розкрив цю завісу. Його основна ідея: вся цінність Ethereum полягає у його універсальності. Якщо EVM недостатньо хороша, потрібно прямо вирішити цю проблему і створити кращу віртуальну машину.

Він запропонував два конкретних рішення.

Перше: змінити “структуру даних”

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

Проблема в тому, що дерево стало занадто “товстим”. Ethereum використовує структуру під назвою “шестіркова Keccak Меркл-патерна” (довга назва, схожа на закляття). Пропозиція Віталіка — EIP-7864 — замінити її на більш просте бінарне дерево.

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

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

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

Друге: змінити “віртуальну машину”, перетворивши EVM у смарт-контракт

Більш сміливе і спірне рішення — замінити EVM архітектурою RISC-V.

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

Інтерпретатор RISC-V — всього кілька сотень рядків коду. Віталік каже, що саме так має виглядати віртуальна машина блокчейну.

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

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

Якщо підсумувати, наскільки важливі ці зміни? Віталік назвав цифру: станове дерево і віртуальна машина разом становлять понад 80% обмежень у доказах Ethereum. Іншими словами, без їхньої модернізації масштабування у епоху ZK залишиться на місці.

Arbitrum не погоджується: не можна через те, що склад у складі використовує вила, змушувати кур’єра їздити на вилах.

Але це не всім подобається.

У листопаді минулого року команда Offchain Labs опублікувала детальну технічну критику. Чотири дослідники стверджують: RISC-V дійсно підходить для ZK-стверджень, але не для формату доставки контрактів.

Вони пропонують розрізняти “інструкційний набір для доставки” (dISA) і “інструкційний набір для доказів” (pISA). Відповідно, склад у складі може використовувати вила, а кур’єр — ні. Це не означає, що потрібно використовувати один і той самий набір для всього.

Offchain Labs пропонують використовувати WebAssembly (WASM) для контрактів, оскільки він має високий рівень продуктивності на стандартному обладнанні і вже має зрілу екосистему інструментів. Вони вже протестували прототип: контракти у форматі WASM компілюються у RISC-V для ZK-стверджень, і обидві системи працюють незалежно.

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

Більше того, у контексті — L2 починають “відлучатися” від основної лінії.

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

Місяць тому Віталік відкрито поставив під сумнів необхідність “спеціальної дорожньої карти для L2”, що викликало реакцію у спільноті L2. CEO Espresso Systems Бен Фіш сказав у CoinDesk: “Ідея Віталіка — що L2 спочатку створювалися для масштабування Ethereum, але тепер, коли Ethereum сама стає швидшою, їхня роль має змінитися”.

Цікаво, що L2-спільноти не панікують, а навпаки — починають “відокремлюватися” від Ethereum. Співзасновник OP Labs Джін Ванг порівнює L2 із незалежним сайтом, а Ethereum — з базовим стандартом відкритих розрахунків. Генеральний директор Polygon Марк Бойрон прямо каже: “Головне — не масштабування, а створення унікального простору для платежів”.

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

Чи вдасться це?

Віталік сам зізнається, що заміна віртуальної машини ще не має широкої підтримки серед розробників. Зміни у станового дерева більш зрілі, є конкретний проект EIP-7864 і команда, що його просуває. Але заміна EVM на RISC-V — поки що на рівні “дорожньої карти”, до коду ще далеко.

Проте минулого тижня Віталік зробив важливу заяву: Ethereum вже один раз “змінив двигун у польоті” (мається на увазі The Merge), і може зробити ще близько чотирьох таких змін — у становому дереві, у спрощеній згоді, у ZK-EVM і у віртуальній машині.

Очікується, що оновлення Glamsterdam відбудеться у першій половині 2026 року, а Hegota — слідом. Деталі цих хардфорків ще не остаточно визначені, але зміни у становому дереві та оптимізація виконавчого рівня — основні напрямки.

Історія Ethereum ніколи не була питанням “можна чи ні”. Від PoW до PoS, від L1 до Rollup — він уже довів, що здатен зняти і замінити двигун на висоті.

Цього разу мова йде про глибші зміни — не додавання нових функцій, а розкопування і переплавлення старих фундаментів. Чи це масштабна модернізація, чи бездонна яма ускладнень — відповідь, ймовірно, стане ясною лише до 2027 року.

Але одне можна сказати точно: Ethereum не має наміру залишатися “старою системою з патчами” у епоху ZK. Як саме знімати патчі і який двигун ставити — ця дискусія, можливо, важливіша за самі висновки.