Пропозиція Віталіка Бутеріна: заміна EVM Ethereum на RISC-V

У квітні 2025 року співзасновник Ethereum Віталік Бутерін представив сміливу пропозицію щодо оновлення основного механізму виконання Ethereum. Він пропонує замінити Віртуальну машину Ethereum (EVM) – середовище виконання смарт-контрактів – на RISC-V, відкритий стандарт архітектури команд процесора. Бутерін стверджує, що така зміна може суттєво підвищити ефективність (особливо для доказів з нульовим знанням) і спростити рівень виконання Ethereum у довгостроковій перспективі. Важливо, що це не означає відмову від облікової моделі чи мов смарт-контрактів Ethereum – вони залишаться незмінними. Замість цього пропонується змінити низькорівневу “машинну мову”, якою виконуються контракти. У цьому вступі пояснюється, з якими проблемами стикається EVM сьогодні, чому розглядається RISC-V, як перехід може бути реалізований без значних потрясінь та які переваги й компроміси пов’язані з цією пропозицією.

Еволюція шару виконання Ethereum

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

• 2015: Запуск Ethereum із EVM як середовищем виконання смарт-контрактів. EVM – це 256-бітна стекова віртуальна машина, спеціально розроблена для Ethereum.
• 2018: Спільнота Ethereum досліджує eWASM (варіант WebAssembly для Ethereum) як потенційну заміну EVM у майбутній Ethereum 2.0. Це мало б дозволити виконувати смарт-контракти у віртуальній машині WebAssembly для підвищення продуктивності. Однак цей план так і не був впроваджений на першому рівні, і EVM залишилася основним середовищем.
• 2022: Відбувається “Злиття” (перехід Ethereum на Proof-of-Stake), при цьому для виконання смарт-контрактів все ще використовується EVM. Заплановані зміни “Ethereum 2.0” щодо механізму виконання було відкладено, оскільки увагу зосередили на масштабованості через другі рівні.
• 2023: Поштовх розвитку ZK-EVM – проєкти другого рівня (наприклад, Scroll, Polygon zkEVM) реалізують сумісні з EVM ролапи з використанням доказів з нульовим знанням. Примітно, що багато ZK-EVM для генерації доказів внутрішньо компілюють байткод EVM у інструкції RISC-V, оскільки доведення виконання традиційної EVM безпосередньо є неефективним. Це на практиці продемонструвало переваги RISC-V для обчислень типу Ethereum.
• 2025: Віталік Бутерін пропонує використовувати RISC-V безпосередньо як віртуальну машину для смарт-контрактів Ethereum. Це перша масштабна пропозиція на рівні L1, яка радикально змінює шар виконання з часів створення Ethereum.

Поточні недоліки EVM

Віртуальна машина Ethereum (EVM) успішно забезпечила виконання смарт-контрактів, але має недоліки, що стають все помітнішими зі зростанням мережі та появою нових технологій (таких як zk-SNARK). Основні проблеми включають:

• Надлишковість виконання: EVM виконує байткод контрактів на основі стекової архітектури з розрядністю 256 біт, що не є настільки ефективним, як стандартні архітектури CPU. Складні обчислення або цикли працюють набагато повільніше в EVM, ніж у рідному машинному коді. Наприклад, виконання інтенсивних обчислень (як-от розрахунок чисел Фібоначчі великого порядку) у EVM може бути до 800 разів повільнішим, ніж на рідній машині RISC-V. Така надлишковість означає вищі витрати газу для складних завдань.
• Вузьке місце для ZK-доказів: Оскільки Ethereum робить ставку на докази з нульовим знанням (для ролапів з нульовим знанням та конфіденційності), EVM стала вузьким місцем для генераторів доказів. Цифрові докази транзакцій Ethereum фактично потребують емуляції виконання EVM, що є ресурсомістким процесом. За останніми даними, приблизно половина часу побудови zk-доказу витрачається на імітацію виконання смарт-контрактів EVM. Через це багато проектів zkEVM перетворюють байткод EVM на інструкції RISC-V, щоб спростити обчислювальні схеми доказів. Необхідність емуляції EVM заради доказів ускладнює і уповільнює процес їх генерації.
• Складність та підтримка: Дизайн EVM специфічний для Ethereum і містить багато опкодів (інструкцій) та нюансів, накопичених за роки (наприклад, спеціальні опкоди для SHA3, особливості SELFDESTRUCT тощо). Внесення навіть незначних змін до EVM (таких як видалення або зміна опкоду SELFDESTRUCT) виявилось дуже складним без порушення зворотної сумісності. Така складність може гальмувати розвиток Ethereum – специфікація шару виконання досить заплутана, що збільшує навантаження на розробників клієнтів та аудиторів безпеки.
• Обмежені інструменти: Оскільки EVM унікальна для Ethereum, інструментарій розробника та доступні оптимізації обмежені порівняно з тими, що існують для поширених апаратних архітектур. Мови смарт-контрактів (Solidity, Vyper) компілюються в байткод EVM, але не можна легко написати смарт-контракт Ethereum загальнопрограмною мовою на кшталт C чи Rust і скомпілювати його в EVM без спеціальних засобів. Це обмежує запозичення оптимізацій і рішень ззовні екосистеми Ethereum.

Чому саме RISC-V?

RISC-V (читається як “риск-файв”) – це відкритий стандарт архітектури комп’ютера зі скороченим набором команд (RISC), що набуває популярності у світі ІТ. RISC-V визначає простий, модульний набір інструкцій процесора, який кожен може реалізувати в апаратурі безкоштовно. Запропонувавши RISC-V як нове середовище виконання для смарт-контрактів Ethereum, Бутерін сподівається використати декілька його переваг:

• Кардинальне підвищення ефективності доказів: Простіші інструкції RISC-V набагато зручніші для генерації доказів з нульовим знанням. Доведення базових операцій RISC-V (простих додавань, завантаження з пам’яті тощо) відбувається легше, ніж доведення складних опкодів EVM. Бутерін зазначає, що якщо контракти виконуватимуться безпосередньо на віртуальній машині RISC-V, загальні витрати на побудову zk-доказів можуть знизитися більше ніж у 100 разів. Адже нинішні системи zkEVM вже несуть накладні витрати на трансляцію EVM у RISC-V; усунення “посередника” (EVM) означає менше кроків для доведення. Дані свідчать, що обчислення на базі EVM можуть бути в сотні разів менш ефективними, ніж на “рідному” рівні – приміром, виконання важкого циклу в EVM проти рідного RISC-V відрізнялося до 800× у одному тесті. Перейшовши на RISC-V, Ethereum зможе безпосередньо скористатися продуктивністю більш “легкого” машинного коду, зробивши zk-ролапи та перевірку на першому рівні значно масштабованішими.
• Стандартизація та інструменти: На відміну від EVM, RISC-V – це стандартний ISA, який широко використовується в академії та промисловості. Це означає, що вже існує величезна екосистема інструментів розробки (компілятори, налагоджувачі, оптимізатори). Теоретично, розробники зможуть писати смарт-контракти мовами на кшталт Rust чи C і компілювати їх у RISC-V, або ж продовжувати використовувати Solidity/Vyper, які під капотом генеруватимуть RISC-V код. Крива навчання для більшості розробників смарт-контрактів буде мінімальною – вони можуть навіть не помітити різниці, якщо їхня мова високого рівня просто компілюється в RISC-V замість EVM. Водночас Ethereum виграє від багаторічних напрацювань у галузі компіляторів і навіть від спеціальної апаратної підтримки, доступної для RISC-V. Наприклад, RISC-V підтримує розширення (зокрема, інструкції для криптографії), які можуть прискорити хешування чи перевірку підписів у смарт-контрактах​. Тобто шар виконання Ethereum перестане бути вузькоспецифічною віртуальною машиною, а перейде на сучасну, добре підтримувану архітектуру.
• Модульність та надійність у майбутньому: Модульний дизайн RISC-V (базовий набір інструкцій з опційними розширеннями) забезпечує гнучкість. Ethereum може почати з мінімального підмножини RISC-V для смарт-контрактів і за потреби активувати певні розширення (наприклад, для арифметики чи криптографії) задля оптимізації продуктивності. Більше того, впровадження RISC-V може відкрити двері для підтримки кількох мов/ВМ на Ethereum. Бутерін згадує ідею системи “інтерпретаторів ВМ”, де EVM може бути лише однією з багатьох віртуальних машин, що працюють поверх базового RISC-V. У майбутньому можна буде підтримувати нові мови контрактів (наприклад, Move від Facebook чи контракти на базі WebAssembly) шляхом реалізації для них інтерпретатора на RISC-V. Така модулярність означає, що базовий шар Ethereum стане нейтральним – він виконуватиме інструкції RISC-V, а будь-яка мова зможе бути використана поверх через компіляцію або інтерпретацію. Досягти такої гнучкості з EVM сьогодні важко.
• Простіша семантика виконання: Заміна EVM на чисту, чітко визначену модель RISC-V може значно спростити специфікацію шару виконання Ethereum. Наразі клієнти Ethereum повинні реалізувати всю специфікацію EVM з усіма її тонкощами. Якщо ж Ethereum перейде на RISC-V, значна частина поведінки виконання визначатиметься стандартом RISC-V, і специфічна для Ethereum логіка зведеться до кількох системних викликів (для дій, специфічних для блокчейну, таких як доступ до зберігання стану, баланси тощо, які стануть “системними викликами RISC-V” замість таких опкодів, як SLOAD, CALL). Віталік вважає, що спрощення шару виконання таким чином може бути єдиним практичним шляхом до довгострокової підтримуваності, зважаючи на те, наскільки складно давалося поступове спрощення дотепер. “Стрункіший” базовий шар означає менше критичних для консенсусу змін та простішу підтримку з часом.

Порівняння ефективності RISC-V та EVM

Нижче наведено таблицю, що підкреслює деякі відмінності між поточною EVM та віртуальною машиною на базі RISC-V у контексті Ethereum:

Зворотна сумісність та план міграції

Критично важливе питання – як впровадити RISC-V, не порушуючи роботу незліченних існуючих смарт-контрактів та dApp, що вже працюють у мережі Ethereum. Пропозиція Бутеріна робить акцент на поступовому переході з повним збереженням зворотної сумісності. Практично це може бути досягнуто через підхід двох ВМ та розумні механізми трансляції:

• Співіснування двох ВМ: Ethereum може підтримувати дві віртуальні машини паралельно – існуючу EVM та нову RISC-V ВМ. Нові смарт-контракти можуть розгортатися з використанням RISC-V, тоді як усі існуючі контракти залишаться на EVM. Обидва середовища зможуть викликати одне одного безперешкодно. Наприклад, контракт на RISC-V зможе викликати функцію контракту на EVM так, ніби він робить системний виклик або звичайний зовнішній виклик, і навпаки, EVM-контракт зможе звернутися до контракту на RISC-V аналогічно. Така двостороння інтероперабельність означає, що розробникам не доведеться переносити весь код одразу. Існуючі контракти на Solidity працюватимуть, як і раніше, а з часом дедалі більше проектів зможуть обирати RISC-V заради продуктивності. Протягом цього періоду вузли Ethereum виконуватимуть як EVM-, так і RISC-V-код, підтримуючи єдиний стан і простір облікових записів.
• Інтерпретатор EVM (перехідне рішення): Ще один варіант – конвертувати або «обгорнути» існуючі EVM-контракти так, щоб вони внутрішньо працювали на ВМ RISC-V. Бутерін пропонує розгорнути інтерпретатор EVM, написаний на RISC-V. По суті, ідея полягає в тому, що байткод кожного старого контракту на рівні протоколу може бути замінений на заглушку, яка викликає універсальний контракт-інтерпретатор EVM, передаючи йому код контракту та вхідні дані. Цей інтерпретатор (що працює на RISC-V ВМ) виконуватиме байткод EVM і повертатиме результат. Таким чином, блокчейн Ethereum зрештою зможе виконувати весь код контрактів на ВМ RISC-V, навіть для старих контрактів, без необхідності ручного переписування цих контрактів. Це радикальніший підхід, але він уніфікував би виконання під одним двигуном (RISC-V), водночас зберігаючи семантику існуючих контрактів.
• Поетапне впровадження: У будь-якому випадку перехід на RISC-V здійснюватиметься поетапно. Наприклад, оновлення мережі (хардфорк) може впровадити ВМ RISC-V як опцію, зберігаючи EVM за замовчуванням. Розробники зможуть почати розгортати окремі контракти на RISC-V для апробації. З часом – можливо, протягом кількох років – якщо RISC-V зарекомендує себе як стабільний та вигідний, спільнота може вирішити зробити його середовищем виконання за замовчуванням для нових контрактів. Завершальним кроком (якщо він колись настане) може стати відміна підтримки EVM, коли нею майже ніхто не користуватиметься – але це перспектива далекого майбутнього. Бутерін прямо зазначає, що EVM не буде відразу вилучена, і обидві ВМ мають тривалий час співіснувати. Такий обережний підхід гарантує, що існуюча екосистема Ethereum не буде раптово зламана цією зміною.

Підтримання зворотної сумісності є першочерговим завданням для довіри до системи. Користувачі та розробники повинні мати змогу самі обирати момент переходу на нову систему. Завдяки стратегії двох ВМ або інтерпретатора, Ethereum може поступово мігрувати на RISC-V з мінімальними перешкодами. По суті, Ethereum додасть RISC-V як нову основу, водночас несучи на своїх “плечах” EVM, доки не стане безпечно її відпустити.

Переваги та компроміси

Перехід виконавчого шару Ethereum на RISC-V обіцяє очевидні вигоди: різке покращення продуктивності доказів, узгодження зі стандартизованими технологіями та більш чисту, модульну архітектуру. Це може зробити Ethereum більш стійким у майбутньому, спростивши і підвищивши гнучкість його ядра. Якщо задум буде успішним, така зміна може суттєво знизити витрати газу на першому рівні для складних транзакцій (оскільки зменшаться накладні витрати на доведення і виконання) та задати новий рівень продуктивності Ethereum у порівнянні з іншими блокчейнами. Це сміливий крок, який, як відзначають деякі, може “переформатувати ефективність виконання смарт-контрактів” і допомогти Ethereum зберегти свою конкурентну перевагу.

Втім, варто врахувати важливі компроміси та виклики:

• Складність реалізації: Впровадження системи з двома ВМ або on-chain інтерпретатора – завдання нетривіальне. ПЗ-клієнти Ethereum повинні інтегрувати рушій виконання RISC-V та гарантувати його детерміновану роботу на всіх вузлах. Це додає роботи з розробки та підтримки. Інструменти та інфраструктура (блок-експлорери, налагоджувачі тощо) потребуватимуть оновлення для розуміння коду контрактів на RISC-V.
• Навантаження перехідного періоду: У проміжний період підтримки двох ВМ оператори вузлів можуть зіштовхнутися з більшим споживанням ресурсів (адже доведеться виконувати і EVM-, і RISC-V-транзакції). Можуть виникнути приховані помилки або проблеми безпеки в механізмі викликів між ВМ, які потребуватимуть ретельного аудиту.
• Продуктивність на реальному залізі: Деякі розробники висловлюють занепокоєння, як добре RISC-V-код виконуватиметься на апаратному забезпеченні, яке сьогодні використовують вузли Ethereum (переважно процесори x86_64). EVM, будучи високорівневою, має деякі операції (наприклад, 256-бітну арифметику), що клієнти Ethereum часто оптимізують за допомогою нативних бібліотек або розширень CPU. Якщо все буде виражено в RISC-V (який, ймовірно, базується на 64-бітних операціях), ці операції розіб’ються на багато дрібніших інструкцій. Це може зробити звичайне виконання блоків повільнішим на реальному залізі, якщо не використовувати JIT-компілятори чи інші оптимізації. Іншими словами, ми обмінюємо частину швидкодії L1-виконання на виграш у швидкості доведення. Цей компроміс потрібно буде виміряти й оптимізувати – наприклад, клієнти можуть застосувати JIT-компіляцію, щоб на льоту переводити RISC-V у код x86 для швидкого виконання на вузлах.
• Прийняття екосистемою: Навіть якщо протокол підтримуватиме RISC-V, ще потрібно, щоб його прийняла спільнота. Розробники мають відчути впевненість і почати розгортати контракти на новій ВМ. Інструменти аудиту та найкращі практики повинні еволюціонувати. Може минути час, перш ніж контракти на RISC-V стануть такими ж перевіреними боями, як контракти EVM. Можливий певний опір або повільне впровадження, особливо якщо переваги в основному відчуватимуться у сфері zk-доказів, яку багато прикладних розробників безпосередньо не відчувають.
• Довгострокова підтримка: Якщо Ethereum у підсумку повністю перейде на RISC-V, йому доведеться взяти на себе відповідальність за підтримку версії стандарту RISC-V для потреб блокчейну. Хоча RISC-V є стабільним, все ж Ethereum, можливо, доведеться визначити, які розширення інструкцій дозволити, як здійснювати оновлення тощо. Позитивний момент в тому, що ядро логіки виконання Ethereum може стати простішим (мета, яку підкреслював Віталік: зберегти обсяг коду базового рівня невеликим), але частина складності зміститься на вищі рівні (наприклад, в інтерпретатори для EVM чи інших ВМ).

Загалом, переваги можуть переважити недоліки за умови обережної реалізації, але це вимагатиме ретельної координації та тестування. Ethereum вже здійснив подібний амбіційний перехід під час “Злиття” (переходу на PoS), і той успіх додає впевненості. Втім, зміна шару виконання впливає на кожен контракт і транзакцію, тому вона повинна проводитися вкрай обережно та за умови широкої підтримки спільноти.

Висновок

Пропозиція Віталіка Бутеріна замінити EVM на RISC-V є масштабним баченням довгострокового розвитку Ethereum. Вона покликана вирішити нагальні неефективності нинішнього шару виконання – особливо в контексті доказів з нульовим знанням та масштабованості – шляхом переходу Ethereum на легку, широко підтримувану архітектуру машинного рівня. Ця зміна обіцяє ефективніший механізм доведення, спрощену модель виконання та більшу гнучкість для майбутнього смарт-контрактів. Водночас вона підкреслює відданість Ethereum прагматизму: зворотна сумісність і поступова міграція є невід’ємною частиною плану, що гарантує можливість мережі працювати стабільно протягом всього перехідного періоду.

Якщо спільнота Ethereum зрештою підтримає цей підхід, це може стати одним з найфундаментальніших оновлень в історії Ethereum, своєрідним “обміном апаратури” для “світового комп’ютера”. Але такий перехід вимагатиме багаторічної ретельної роботи, досліджень і досягнення консенсусу. Майбутні обговорення та прототипи (наприклад, експерименти команд клієнтів Ethereum з виконанням на RISC-V чи тестові мережі з підтримкою двох ВМ) нададуть цінну інформацію. Ця пропозиція закликає дослідників, розробників та учасників екосистеми переосмислити, яким може бути шар виконання Ethereum, якщо звільнити його від початкових обмежень дизайну.

Підсумовуючи, перехід від EVM до RISC-V може відкрити нові горизонти продуктивності та простоти для Ethereum, допомагаючи забезпечити, що платформа залишатиметься міцною та адаптивною в наступному десятилітті. Це смілива ставка на перевірену технологію (RISC-V) задля закріплення позицій Ethereum у майбутньому, де на перший план виходять ефективність і модульність. У міру розвитку цієї ідеї спільнота зважуватиме переваги та витрати, але сам факт її обговорення демонструє готовність Ethereum до еволюції. Шар виконання, що започаткувався у 2015 році, можливо, вже не буде тим, який Ethereum використовуватиме у 2030-му – і це може стати зміною на краще.