Розробники Ethereum дотримуються негласного правила: уникати EVM, якщо це можливо.
Останніми роками, коли на блокчейні виникала потреба у новій криптографічній операції, розробники не впроваджували її у EVM, а запитували “попередньо скомпільований контракт” — обхідний шлях, який минає віртуальну машину та закладає операцію на протоколі.
1 березня Віталік Бутерін опублікував розгорнуту тему на X, відкрито порушивши це неписане правило. Він фактично заявив: цінність Ethereum — в універсальності. Якщо EVM недостатній, проблему слід вирішувати безпосередньо та створити кращу віртуальну машину.
Він запропонував два конкретні рішення.
Перше рішення: зміна “структури даних”
Перша зміна стосується дерева стану Ethereum — системи індексації реєстру мережі. Кожен раз, коли хтось перевіряє баланс чи підтверджує транзакцію, він проходить це дерево.
Проблема в тому, що поточне дерево надто “масивне”. Ethereum використовує структуру під назвою “шестирічне Keccak Merkle Patricia дерево” (назва звучить як заклинання). Пропозиція Віталіка EIP-7864 передбачає заміну його більш компактним бінарним деревом.
Для порівняння: раніше, щоб отримати дані, потрібно було обирати між шістьма напрямками на кожному вузлі. Тепер вибір — лише ліворуч чи праворуч. Результат: довжина гілки Merkle скорочується до чверті початкового розміру. Для легких клієнтів вимоги до пропускної здатності для верифікації даних суттєво зменшуються.
Віталік не зупиняється лише на зміні структури дерева. Він також хоче змінити “шрифт на листках” — хеш-функцію. Кандидати: Blake3 і Poseidon. Blake3 забезпечує стабільне підвищення швидкості; Poseidon більш радикальний і теоретично може підвищити ефективність доказів у десятки разів, хоча його безпека потребує додаткового аудиту.
Варто зазначити, що ця пропозиція замінює раніше обговорювані Verkle Trees. Verkle був основним кандидатом для хардфорку 2026 року, але криптографія на основі еліптичних кривих піддається загрозам з боку квантових обчислень. З середини 2024 року Verkle поступово втрачає популярність, а рішення з бінарним деревом набирає обертів.
Друге рішення: зміна “віртуальної машини” — перетворення EVM на смарт-контракт
Друге рішення — ще сміливіше і більш суперечливе: у перспективі замінити EVM на архітектуру RISC-V.
RISC-V — відкритий набір інструкцій, спочатку не пов’язаний із блокчейном, але зараз майже всі системи ZK-доказів використовують його внутрішньо. Логіка Віталіка очевидна: якщо доводчики вже використовують RISC-V, навіщо віртуальній машині використовувати щось інше, створюючи шар перекладу? Усунення цього шару підвищує ефективність.
Інтерпретатор RISC-V потребує лише кілька сотень рядків коду. Віталік стверджує, що саме такою має бути віртуальна машина блокчейну.
Його план складається з трьох етапів: спочатку використовувати нову віртуальну машину для попередньо скомпільованих контрактів, переписавши 80% існуючих precompile-контрактів на новий код; далі дозволити розробникам розгортати контракти для нової VM, які працюватимуть паралельно з EVM; на завершення — вивести EVM з експлуатації не шляхом ліквідації, а переписавши її як смарт-контракт, що працює на новій віртуальній машині, забезпечивши повну зворотну сумісність.
Існуючим користувачам не потрібно змінювати свої автомобілі — лише двигун тихо замінюється, а кермо залишається тим самим.
Наскільки значущі ці дві зміни разом? Віталік навів цифру: дерево стану та віртуальна машина разом становлять понад 80% вузького місця для доказів Ethereum. Якщо ці дві області не вирішити, масштабування Ethereum у ZK-епоху зупиниться.
Arbitrum не погоджується: те, що склад використовує навантажувачі, не означає, що кур’єри мають їздити на навантажувачах
Однак не всі погоджуються.
У листопаді минулого року основна команда розробників Arbitrum — Offchain Labs — опублікувала детальну технічну відповідь. Чотири дослідники зазначили, що хоча RISC-V добре підходить для ZK-доказів, він не є оптимальним “форматом доставки” для контрактів.
Вони ввели важливе розмежування: “набір інструкцій доставки” (dISA) та “набір інструкцій доказу” (pISA) не обов’язково мають бути однаковими. Використання навантажувачів на складі максимізує ефективність, але це не означає, що кур’єри мають використовувати навантажувачі для доставки посилок до дверей.
Offchain Labs виступає за використання WebAssembly (WASM) на рівні контрактів, наводячи вагомі аргументи: WASM ефективно виконується на стандартному обладнанні, і більшість вузлів Ethereum не працюють на чипах RISC-V — примусова заміна вимагатиме емуляторів; WASM забезпечує зрілу перевірку типів; екосистема інструментів WASM перевірена у мільярдах середовищ виконання.
Важливо, що це не лише теорія. Offchain Labs вже запустили прототип на Arbitrum: використання WASM як формату доставки контрактів, після чого компіляція у RISC-V для ZK-доказів. Два рівні працюють незалежно.
Вони також підняли важливу проблему: технологія ZK-доказів стрімко розвивається, і нещодавно реалізації RISC-V перейшли з 32-бітної архітектури на 64-бітну. Якщо зараз закріпити RISC-V у Ethereum L1, що станеться, якщо через два роки з’явиться краща архітектура доказів? Ставити на стрімко змінювану ціль — не в стилі Ethereum.
Ширший контекст: L2 починають “відвикати”
Щоб зрозуміти цю пропозицію, потрібен ширший погляд.
Місяць тому Віталік публічно поставив питання, чи потрібна Ethereum “спеціальна L2-дорожня карта”, що викликало колективну реакцію екосистеми L2. Генеральний директор Espresso Systems Бен Фіш сказав CoinDesk: Віталік має на увазі, що L2 спочатку були створені для масштабування Ethereum, але тепер, коли сам Ethereum стає швидшим, роль L2 природно змінюється.
Цікаво, що замість паніки L2 активно “де-Ethereumізуються”. Співзасновник OP Labs Джин Ванг порівняла L2 з незалежними вебсайтами, а Ethereum — з базовим відкритим стандартом розрахунків. Генеральний директор Polygon Марк Бойрон висловився прямо: справжній виклик — не масштабування, а створення унікального блок-простору для реальних сценаріїв, таких як платежі.
Інакше кажучи, оновлення виконуваного рівня від Віталіка — це технічна примітка до ширшої тенденції: Ethereum повертає контроль над ключовими можливостями, а L2 змушені — або нарешті знаходять — власні причини для незалежного існування.
Чи може це вдастися?
Сам Віталік визнає, що заміна віртуальної машини не отримала широкої підтримки розробників. Реформа дерева стану більш зріла: EIP-7864 вже має чернетку та виділену команду. А заміна EVM на RISC-V? Це поки що на рівні “дорожньої карти”, далеко від впровадження.
Минулого тижня Віталік зробив пам’ятну заяву: Ethereum вже замінив реактивний двигун у польоті (мається на увазі The Merge) і може зробити це ще близько чотирьох разів — дерево стану, спрощений консенсус, перевірка ZK-EVM та заміна віртуальної машини.
Оновлення Ethereum Glamsterdam очікується у першій половині 2026 року, за ним слідує Hegota. Точний зміст двох хардфорків ще не визначено, але реформа дерева стану та оптимізація виконуваного рівня підтверджені як основні теми.
Історія Ethereum ніколи не була про “чи можна це зробити”. Від PoW до PoS, від L1 all-in до Rollup-центрованого підходу — він довів свою здатність і сміливість розбирати двигуни на крейсерській висоті.
Цього разу йдеться про щось глибше — не про додавання нових функцій, а про розбирання старого фундаменту та прокладання нового. Чи це ретельно продумана реконструкція, чи нескінченно поглиблювана яма складності? Відповідь, ймовірно, не буде очевидною до 2027 року.
Але одне точно: Ethereum не має наміру бути “заплаткою старої системи” у ZK-епоху. Щодо того, як прибрати ці заплатки і який двигун встановити — сама дискусія може бути ціннішою за остаточний висновок.
Відмова від відповідальності:
-
Ця стаття повторно опублікована з TechFlow, авторське право належить оригінальному автору [Gray Lobster]. Якщо у вас є заперечення щодо цієї повторної публікації, зверніться до команди Gate Learn, яка оперативно розгляне питання відповідно до чинних процедур.
-
Відмова від відповідальності: думки та погляди, викладені в цій статті, належать виключно автору і не є інвестиційною порадою.
-
Інші мовні версії цієї статті перекладені командою Gate Learn. Без явної згадки про Gate не копіюйте, не розповсюджуйте та не плагіюйте перекладені статті.
