Автор: сіра омара, 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. Іншими словами, без їхнього оновлення масштабування Ethereum у епоху ZK залишатиметься на місці.
Arbitrum не погоджується: не можна через те, що склад з вилкою, змушувати кур’єра їздити на вилці
Але це не історія, яку всі підтримують.
Минулого листопада команда Offchain Labs, розробники Arbitrum, опублікувала детальну технічну критику. Чотири дослідники стверджують: RISC-V дійсно підходить для ZK-підтверджень, але не підходить для формату доставки контрактів.
Вони пропонують важливий розподіл: “інструкційний набір для доставки” (dISA) і “інструкційний набір для підтверджень” (pISA) не обов’язково мають бути однаковими. Ваш склад може ефективно використовувати вилку для транспортування вантажів, але це не означає, що кур’єр має їздити на вилці.
Offchain Labs пропонують використовувати WebAssembly (WASM) для контрактів, і мають вагомі аргументи: WASM швидко виконується на стандартному обладнанні, більшість нод Ethereum не працює на RISC-V, тому потрібно емулятор; WASM має зрілі механізми безпеки типів; інструментарій 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 має змінюватися.
Цікаво, що L2-спільноти не панікують, а навпаки — починають активно “відокремлюватися” від Ethereum. Зокрема, Jing Wang з OP Labs порівнює L2 із незалежним сайтом, а Ethereum — із базовим стандартом відкритих розрахунків. Марк Бойрон з Polygon прямо каже: справжній виклик — не масштабування, а створення унікального простору для платежів.
Інакше кажучи, ця велика зміна у виконанні — частина ширшого тренду: Ethereum повертає контроль над своїми ключовими можливостями, а L2 починають знаходити причини для самостійного існування.
Чи можливо це?
Віталік сам зізнається, що заміна віртуальної машини наразі не має широкої підтримки серед розробників. Реформа станового дерева більш зріла, і EIP-7864 вже має конкретний проект і команду. Але заміна EVM на RISC-V? Це ще на рівні “дорожньої карти”, і до коду ще далеко.
Проте минулого тижня Віталік зробив важливу заяву: Ethereum вже один раз “змінив двигун” під час The Merge, і може зробити ще близько чотирьох таких оновлень — реформи станового дерева, оптимізація консенсусу, ZK-EVM і заміна VM.
Оновлення Glamsterdam заплановане на першу половину 2026 року, а Hegota — одразу після. Деталі ще не остаточно визначені, але реформи станового дерева і оптимізація виконання — основні напрямки.
Історія Ethereum ніколи не була питанням “можна чи ні”. Від PoW до PoS, від L1 до Rollup — він уже довів, що здатен знімати двигуни на висоті.
Цього разу йдеться про глибші зміни — не додавання нових функцій, а розкриття старих фундаментів. Це може бути ретельна модернізація або ж бездонна яма ускладнень. Відповідь, ймовірно, з’явиться лише до 2027 року.
Але одне точно — Ethereum не має наміру залишатися “старою системою з патчами” у епоху ZK. Як саме будуть знімати патчі і який двигун ставити — ця дискусія, можливо, важливіша за самі рішення.
