Ethereum переживає найважливішу архітектурну трансформацію з моменту свого створення: заміна Ethereum Virtual Machine (EVM) на RISC-V. Основною причиною цього зміни є те, що в епоху нульових знань (ZK) EVM стала найбільшим вузьким місцем:
Поточний zkEVM залежить від виконання інтерпретатора, що призводить до зниження швидкості на 50–800 разів;
Пре-компільовані контракти (Precompiles) ускладнюють протокол і збільшують ризики;
Дизайн стеку на 256 біт має дуже низьку ефективність у доказах.
стало фактичним стандартом zkVM (90% проєктів використовують);
Формалізована специфікація SAIL (на відміну від двозначної жовтої книги) може підтримувати строгі перевірки;
Шлях апаратного доказу (ASIC/FPGA) вже тестується (SP1, Nervos, Cartesi).
Міграція відбувається в три етапи:
RISC-V як заміна для попередньо скомпільованих контрактів (низькоризикове тестування);
Двійна віртуальна машина: EVM + RISC-V мають повну взаємодію;
EVM повторно реалізовано всередині RISC-V (аналогічно стратегії Rosetta).
Екосистемний вплив:
Оптимістичні ролапи не постраждають; основна мережа RISC-V не скасує доказ шахрайства, існуючі програми доказів можуть бути скомпільовані для RISC-V (в даний час базуються на MIPS); шлях міграції: розширити поточну інфраструктуру помилок до цільового RISC-V, а не повністю переробляти.
Розробники можуть безпосередньо використовувати бібліотеки Rust/Go/Python на L1;
Користувачі можуть отримати знижку на вартість доказу приблизно в 100 разів, що дозволить їм наблизитися до рівня Gigagas (приблизно 10 тис. TPS) на шляху до L1.
Зрештою, Ethereum еволюціонуватиме з «віртуальної машини смарт-контрактів» у мінімальний, перевіряний рівень довіри в Інтернеті, де кінцева мета – «усе має бути ZK-Snark».
Ефіріум перебуває на роздоріжжі
З кінцевою метою "усе має бути ZK-Snark" візією, Ethereum зараз перебуває на порозі найважливішої еволюції архітектури з моменту свого створення. Це обговорення більше не обмежується поступовими оновленнями, а стосується основного перетворення його обчислювального ядра — заміни Ethereum Virtual Machine (EVM). Ця ініціатива є основою більшого бачення "Спростити Ethereum" (Lean Ethereum), яке має на меті систематично спростити весь протокол, розділивши його на три основні компоненти: спрощений консенсус (Lean Consensus), спрощені дані (Lean Data) та спрощене виконання (Lean Execution). А основне питання спрощеного виконання полягає в тому: чи стала EVM, як двигун революції смарт-контрактів, основною перешкодою для майбутнього розвитку Ethereum?
Як зазначив Джастін Дрейк з Фонду Ефіріуму, довгостроковою метою Ефіріуму завжди було «перетворити все на Snark», що є потужним інструментом для посилення всіх рівнів протоколу. Але протягом тривалого часу ця мета більше нагадувала «повітряну замок», оскільки для її досягнення необхідно було реалізувати концепцію в реальному часі. А тепер, коли реалізація в реальному часі поступово стає реальністю, теоретична неефективність EVM перетворилася на термінову проблему, яку потрібно вирішити.
Цей аналіз розгляне технічні та стратегічні аргументи щодо міграції Ethereum L1 на архітектуру команд RISC-V (ISA), що має на меті забезпечити безпрецедентну масштабованість, спростити структуру протоколу та узгодити Ethereum з майбутнім перевірених обчислень.
Що насправді змінилося?
Перш ніж поглиблено досліджувати «чому», спочатку потрібно зрозуміти, «що» саме змінюється.
EVM є середовищем виконання смарт-контрактів Ethereum, це «світовий комп'ютер», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн мав революційний характер, створивши платформу без дозволу, яка сприяла розвитку цілого екосистеми DeFi та NFT. Однак ця спеціалізована архітектура, що існує майже десять років, наразі накопичила значний технічний борг.
В порівнянні, RISC-V не є продуктом, а відкритим стандартом — безкоштовним, універсальним дизайном процесорів «алфавіту». Як підкреслив Джеремі Бруестл на конференції Ethproofs, його ключові принципи роблять його ідеальним вибором для цієї ролі:
Екстремальний мінімалізм: базовий набір команд надзвичайно простий, містить лише близько 40-47 команд. Джеремі описує його як «майже ідеальний приклад надзвичайно спрощеної універсальної машини, яка нам потрібна».
Модульність: додавання більш складних функцій за допомогою опціональних розширень. Це вкрай важливо, оскільки дозволяє мати просту основу, яка може бути розширена за потреби, не навантажуючи базовий протокол зайвою складністю;
Відкита екосистема: вона має величезну та зрілу підтримку інструментальних ланцюгів, включаючи компілятор LLVM, що дозволяє розробникам використовувати популярні мови, такі як Rust, C++ та Go. Як сказав Джастін Дрейк: «Існує багато інструментів, пов'язаних з компіляторами, і створення компілятора надзвичайно складне... Тому наявність цих інструментів для компіляторів має велику цінність.» RISC-V дозволяє Ethereum безкоштовно успадковувати ці готові інструменти.
Проблема витрат інтерпретатора
Необхідність заміни EVM не походить з єдиного дефекту, а викликана низкою фундаментальних обмежень, які в контексті майбутнього, орієнтованого на нульові знання (ZK), стали нестерпними. Ці проблеми охоплюють серйозні вузькі місця в системах доказів ZK, а також ризики, пов'язані з дедалі зростаючою складністю всередині протоколу.
Проблема накладних витрат інтерпретатора
Цим перетворенням найбільш терміновим стимулом є вроджена неефективність EVM в системах нульового знання. Оскільки Ethereum поступово переходить до моделі верифікації стану L1 через ZK-докази, продуктивність доказувача стане кінцевим вузьким місцем.
Проблема полягає в поточному принципі роботи zkEVM. Вони не здійснюють нульове знання безпосередньо для EVM, а замість цього доводять роботу інтерпретатора EVM, який сам був скомпільований у RISC-V. Віталік Бутерін влучно вказав на цю ключову проблему:
"Якщо реалізація zkVM полягає в компіляції виконання EVM в коду RISC-V, то чому не відкрити розробникам смарт-контрактів нижній рівень RISC-V? Це дозволить повністю усунути витрати на зовнішню віртуальну машину."
Цей додатковий шар пояснень призводить до величезних втрат продуктивності. За оцінками, цей шар може призвести до зниження продуктивності на 50 до 800 разів у порівнянні з нативними програмами. Після оптимізації інших вузьких місць (наприклад, переходу на алгоритм хешування Poseidon) ця частина «виконання блоків» все ще споживатиме 80–90% часу на доказ, роблячи EVM остаточною і найупертішою перешкодою для розширення L1. Якщо цей шар буде видалено, Віталік прогнозує, що ефективність виконання може зрости на 100 разів.
Щоб вирішити проблему недостатньої продуктивності EVM у певних криптографічних операціях, Ethereum впровадив попередньо скомпільовані контракти — функції, які спеціально кодуються безпосередньо в протокол. Хоча це було практичним рішенням на той час, сьогодні це спричинило те, що Віталік Бутерін назвав «катастрофічною» ситуацією:
«Попередня компіляція була для нас катастрофічною... вона значно розширила надійний код Ethereum... і на межі провалу консенсусу вона не раз ставила нас на грань краху.»
Складність цього вражає. Віталік, порівнюючи упаковку коду окремого попередньо скомпільованого контракту (modexp) з повним інтерпретатором RISC-V, зазначив, що логіка попередньо скомпільованого коду насправді є більш складною. Додавання нових попередньо скомпільованих контрактів проходить повільний і сповнений політичних ігор процес жорсткого хардфорка, що серйозно заважає інноваціям у застосуваннях, які залежать від нових криптографічних примітивів.
Отже, Віталік зробив тверде висновок: «Я насправді вважаю, що ми повинні негайно припинити створення будь-яких нових попередньо скомпільованих контрактів.»
Технологічний борг архітектури Ethereum
Ядро дизайну EVM відображає застарілі вимоги епохи, але воно вже не може адаптуватися до сучасних обчислень. EVM обрала 256-бітну архітектуру для обробки криптографічних значень, що є вкрай неефективним для 32-бітних або 64-бітних цілих чисел, які зазвичай використовуються в смарт-контрактах. Ціна цієї неефективності особливо висока в системах нульових знань.
Як пояснив Віталік: «Коли використовуються менші числа, кожне число насправді не економить жодних ресурсів, а складність зростає в 2-4 рази.»
Крім того, архітектура стеку EVM менш ефективна, ніж архітектури регістрів RISC-V та сучасних процесорів. Для виконання тих самих операцій потрібно більше інструкцій, що також ускладнює оптимізацію компілятора.
Ці комплексні фактори, включаючи вузькі місця продуктивності ZK-доказів, складність попередньої компіляції та застарілі вибори архітектури, разом створюють переконливу та термінову причину для переходу Ethereum за межі EVM.
RISC-V план: створення більш міцної основи
Переваги RISC-V походять не лише від недоліків EVM, але й з його дизайнерської філософії та вроджених переваг. Його архітектура забезпечує надійну, просту та перевірену основу, що робить його дуже придатним для таких високоризикованих середовищ, як Ethereum.
Чому відкриті стандарти переважають над індивідуальним дизайном
На відміну від індивідуально налаштованих архітектур інструкцій (ISA), які потрібно будувати з нуля, RISC-V є зрілим відкритим стандартом, який може надати три ключові переваги:
досвідчена екосистема
Завдяки впровадженню RISC-V, Ethereum в повній мірі скористався колективними досягненнями в галузі комп'ютерних наук за десятиліття. Як пояснив Джастін Дрейк, це надає Ethereum можливість безпосередньо використовувати світового класу інструменти: «Існує компонент інфраструктури під назвою LLVM, це набір інструментів компілятора, який дозволяє розробникам компілювати мови високого рівня на різні бекенди. RISC-V є одним із підтримуваних бекендів. Отже, якщо ви підтримуєте RISC-V, ви автоматично підтримуєте всі мови високого рівня, які підтримує LLVM.»
Це значно знизило бар'єр для входу для мільйонів розробників, які знайомі з такими мовами, як Rust, C та Go.
Філософія дизайну мінімалізму
Мінімалізм RISC-V є навмисною ознакою, а не обмеженням. Його базовий набір інструкцій містить лише близько 47 інструкцій, що робить ядро віртуальної машини надзвичайно простим. Ця простота є величезною перевагою для безпеки, оскільки менша довірена база коду легше піддається аудитам і формальній верифікації.
Фактичний стандарт у сфері ZK
Більш важливо, що екосистема zkVM вже зробила самостійний вибір. Як підкреслив Джастін Дрейк, з даних Ethproofs можна побачити чітку тенденцію: «RISC-V є провідною ISA для бекенду zkVM.»
В 10 zkVM, які можуть підтвердити блоки Ethereum, 9 обрали RISC-V як цільову архітектуру. Це ринкове зближення випускає потужний сигнал: використання RISC-V в Ethereum не є спекулятивною спробою, а слідування перевіреному ринковому стандарту.
Спроектовано для довіри, не лише для виконання
Окрім екосистеми, внутрішня архітектура RISC-V також особливо підходить для створення безпечних та перевіряємих систем.
По-перше, RISC-V має офіційну, машинозчитувану специфікацію, яка називається SAIL. Це є величезним покращенням у порівнянні зі специфікацією Ethereum Virtual Machine (EVM), яка в основному існує у вигляді документації (жовта книга) і може містити неоднозначності. Специфікація SAIL надає «золотий стандарт», здатний надати математичні докази, які є критично важливими для коректності протоколу, що є ключовим для захисту протоколів з величезною вартістю. Як зазначив Алекс Хікс з Фонду Ethereum (EF) під час телефонної конференції Ethproofs, це дозволяє zkVM схемам перевіряти «відповідно до офіційної специфікації RISC-V».
По-друге, RISC-V містить привілейовану архітектуру, яка часто ігнорується, але є критично важливою для безпеки. Вона визначає різні рівні виконання, головним чином включаючи користувацький режим (для ненадійних застосунків, таких як смарт-контракти) та режим нагляду (для надійних "виконавчих ядер").
У моделі RISC-V смарт-контракти, що працюють в режимі користувача, не можуть безпосередньо отримати доступ до стану блокчейну. Натомість вони повинні надсилати запит до довіреного ядра, що працює в режимі моніторингу, через спеціальну інструкцію ECALL (виклик середовища). Цей механізм створює безпечну межу, яка забезпечується апаратним забезпеченням, що робить його більш надійним і легшим для перевірки, ніж чисто програмна модель пісочниці EVM.
Візія Віталіка
Ця трансформація задумана як поступовий, багатоступеневий процес для забезпечення стабільності системи і зворотної сумісності. Цей підхід, описаний Віталіком Бутеріним, спрямований на досягнення поступового розвитку, а не революційних змін.
Перший крок: попередня компіляція заміни
На початковому етапі слід застосувати найбільш консервативний підхід, впроваджуючи обмежені функції нової віртуальної машини (VM). Як запропонував Віталік, «ми можемо почати з обмежених сценаріїв використання нової віртуальної машини, наприклад, замінивши функціонал попередньої компіляції». Це передбачає призупинення нових функцій EVM попередньої компіляції, натомість реалізуючи необхідні функції за допомогою програм RISC-V, схвалених через білий список. Цей підхід дозволяє новій віртуальній машині проводити польові випробування в основній мережі в умовах низького ризику, при цьому клієнт Ethereum виступає посередником між двома середовищами виконання.
Другий крок: спільне існування двох віртуальних машин
На наступному етапі буде «безпосередньо відкрито нову віртуальну машину для користувачів». Під час розгортання смарт-контракту можна додати мітку, щоб вказати, чи є його байт-код EVM або RISC-V. Ключова особливість полягає в забезпеченні безшовної взаємодії: «два типи контрактів зможуть викликати один одного». Це буде реалізовано через системні виклики (ECALL), при цьому клієнт Ethereum виступає в ролі посередника виконавчого середовища.
Третій крок: EVM як імітаційний контракт («Rosetta» стратегія)
Кінцевою метою є досягнення остаточного спрощення протоколу. На цьому етапі «ми реалізуємо EVM як одну з реалізацій нової віртуальної машини». Нормативний EVM стане формально перевіреним смарт-контрактом, що працює на рідному RISC-V L1. Це не тільки забезпечує постійну підтримку старих додатків, але й дозволяє розробникам клієнтів підтримувати лише один спрощений виконавчий механізм.
Цепна реакція всього екосистеми
Перехід від EVM до RISC-V - це не лише основний протокол, він матиме глибокий вплив на всю екосистему Ethereum, потенційно перетворюючи досвід розробників, кардинально змінюючи конкурентне середовище рішень другого рівня та відкриваючи нові моделі економіки доказів.
Перебудова ролапу: шляхове розмежування між Optimistic та ZK
Перехід на виконавчий шар RISC-V на L1 матиме радикально різний вплив на два основні типи Rollups.
Модель безпеки оптимістичних роллапів (такі як Arbitrum, Optimism) залежить від повторного виконання спірних транзакцій на Layer-1 для вирішення доказів шахрайства. Навіть якщо Layer-1 Ethereum перейде на RISC-V, ці системи не зазнають кардинальних змін. Як пояснив один із співзасновників Optimism: «Якщо ми перенесемо Ethereum на RISC-V, ланцюги Optimistic також не зупиняться. Вам просто потрібно скомпілювати віртуальну машину RISC-V в програму доказу. Також не потрібно використовувати Asterisc. Існуюча система доказів на базі MIPS також не зупиниться — вам просто потрібно скомпілювати віртуальну машину RISC-V в MIPS.
Це означає, що модель протидії шахрайству залишилася неушкодженою. Коригування є технічними: інтеграція нової віртуальної машини RISC-V в існуючу інфраструктуру, а не повне пер redesign системи. Залишилися виклики інженерних деталей, такі як облік газу, ефективність і вартість.
У порівнянні, ZK Rollups отримають величезну стратегічну перевагу. Абсолютна більшість ZK Rollups вже використовує RISC-V як свою внутрішню ISA. Використання тієї ж рідної мови L1 дозволяє досягти більш тісної та ефективної інтеграції. Джастін Дрейк описав майбутнє «рідних Rollups», де L2 по суті є спеціалізованим екземпляром середовища виконання L1, яке використовує вбудовану L1 VM для безшовного розрахунку. Ця інтеграція призведе до наступних змін:
Спрощений технічний стек: усунення складного моста між внутрішнім виконанням RISC-V рівня L2 та EVM;
Реалізація повторного використання інструментів та коду: компілятори, налагоджувачі та інструменти формальної верифікації, розроблені для середовища L1 RISC-V, можуть безпосередньо використовуватися L2 для зниження витрат на розробку.
Скоординовані економічні стимули: витрати Gas на L1 будуть точніше відображати фактичні витрати на виконання ZK-доказів RISC-V, що дозволить створити більш обґрунтовану економічну модель.
Нова ера для розробників і користувачів
Для розробників екосистеми Ethereum це перетворення буде поступовим, а не руйнівним.
Для розробників ключова перевага полягає в тому, що вони можуть увійти в більш широкий і зрілий світ розробки програмного забезпечення. Як зазначив Віталік Бутерін, розробники «зможуть писати контракти на Rust, і ці дві мови почнуть співіснувати». Водночас він прогнозує, що «Solidity і Vyper залишаться популярними протягом довгого часу», оскільки вони мають елегантну логіку розумних контрактів. Можливість використовувати основні мови та їх багаті бібліотеки через інструментальний набір LLVM стане революційною зміною. Віталік описує це як «досвід, схожий на Node.JS», в якому розробники в основному можуть використовувати одну й ту ж мову для написання коду на блокчейні та поза ним.
Для користувачів остаточна вигода полягає в більш економічній та потужній мережі. Очікується, що витрати на підтвердження зменшаться приблизно в 100 разів — з кількох доларів за транзакцію до кількох центів — що безпосередньо призведе до зниження витрат на розрахунок Layer-1 та Layer-2. Ця економічна доцільність відкриє перспективи «Gigagas L1», метою якого є досягнення приблизно 10000 TPS на L1, що надасть підтримку для більш складних та цінних застосувань на блокчейні в майбутньому.
Succinct Labs та SP1: доведення того, що майбутнє вже тут
Теоретичні переваги RISC-V вже були реалізовані командами, такими як Succinct Labs, і їхні результати стали потужним прикладом для всієї пропозиції.
SP1, розроблений Succinct Labs, є високопродуктивним, відкритим zkVM, побудованим на основі RISC-V, який перевіряє життєздатність нового архітектурного підходу. Він використовує концепцію «попередньо скомпільованого централізованого» дизайну, що ідеально вирішує криптографічні обмеження EVM. На відміну від традиційних повільних, жорстко закодованих методів попередньої компіляції, SP1 розвантажує інтенсивні операції, такі як хешування Keccak, через стандартні команди ECALL, а також спеціально розроблені та вручну оптимізовані ZK-кола. Це забезпечує продуктивність налаштованого апаратного забезпечення разом з гнучкістю програмного забезпечення.
Вплив практики команди чітко проявився, їхній продукт OP Succinct використовує SP1 для реалізації "ZK-офікації" (ZK-ify) Optimistic Rollup. Як пояснила співзасновниця Succinct Ума Рой:
«Ваш OP Stack Rollup не потрібно чекати 7 днів для завершення остаточного підтвердження та виведення... тепер це займає лише 1 годину. Це значно підвищує швидкість остаточного підтвердження, це просто чудово.»
Це вирішує одну з ключових проблем усього екосистеми OP Stack. Крім того, інфраструктура Succinct «Succinct Prover Network» була розроблена як децентралізований ринок для генерації доказів, що демонструє життєздатну економічну модель для майбутнього верифікованих обчислень. Їхня робота — це не лише перевірка концепції, а й реальний план на майбутнє, описаний у цій статті.
Як Ethereum знижує ризики
Ключова перевага RISC-V полягає в тому, що вона робить кінцеву мету формалізованої верифікації — доведення правильності системи за допомогою математики — досяжною метою. Специфікація EVM написана природною мовою в Жовтій книзі (Yellow Paper), що ускладнює формалізацію. Натомість RISC-V має офіційну, машиночитну специфікацію SAIL, яка надає чітке «золоте посилання» для її поведінки.
Це відкриває чіткий шлях до більшої безпеки. Як зазначив Алекс Хікс з Фонду Ethereum, наразі проводиться робота над "екстракцією zkVM RISC-V схем з офіційної специфікації RISC-V до Lean для формальної верифікації". Це знаковий прогрес, який переносить довіру з схильних до помилок людських реалізацій на перевірювані математичні докази, що забезпечує прорив у безпеці.
Основні ризики трансформації
Хоча архітектура RISC-V має багато переваг у L1, вона також зіткнеться з новими складними викликами.
Проблема вимірювання газу: створення детермінованої та справедливої моделі газу для універсальної ISA є однією з найскладніших проблем. Простий спосіб підрахунку інструкцій піддається загрозі атаки відмови в обслуговуванні. Наприклад, зловмисник може створити програму, що повторно викликає кешовану програму, тим самим досягаючи високого використання ресурсів за дуже низьку плату за газ.
Проблеми безпеки інструментальних засобів та «відтворювального збірки»: це, можливо, найбільший і недооцінений ризик у процесі трансформації. Модель безпеки переходить від віртуальної машини довіри до довіри до компілятора, що використовується кожним розробником (наприклад, LLVM), і ці компілятори є надзвичайно складними, і відомо, що в них є вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на перший погляд безпечний вихідний код на шкідливий байт-код. Крім того, забезпечити, щоб двійкові файли після компіляції в ланцюзі повністю відповідали певному відкритому вихідному коду, тобто проблема «відтворювальної збірки», також надзвичайно важко, оскільки незначні відмінності в середовищі зборки можуть призвести до різних двійкових файлів.
стратегії пом'якшення
Дорога вперед вимагає багатоетапної стратегії захисту.
Поетапний запуск: Поетапний та багатофазний план переходу є основною стратегією пом'якшення ризиків. Спочатку впроваджуючи RISC-V як попередньо скомпільовану альтернативу, а потім здійснюючи розгортання у двовіртуальному середовищі, спільнота може накопичувати операційний досвід та будувати впевненість у низькоризиковому середовищі до того, як відбудуться будь-які незворотні зміни.
Повна перевірка: нечітке тестування та формальна верифікація. Хоча формальна верифікація є остаточною метою, вона повинна супроводжуватися постійним, інтенсивним тестуванням. Як показав Валентин з Diligence Security на телефонній конференції Ethproofs, їхній нечіткий тестер Argus вже виявив 11 ключових вразливостей цілісності та коректності в провідному zkVM. Це доводить, що навіть у найкращих системах є вразливості, які можна виявити лише через суворе протистояння тестуванню.
Стандартизація: для уникнення фрагментації екосистеми спільнота повинна єдино прийняти єдиний, стандартизований профіль RISC-V. Це, ймовірно, буде комбінація ABI, сумісна з RV64 GC та Linux, оскільки ця комбінація може забезпечити найширшу підтримку з основних мов та інструментів, що дозволить максимально використати переваги нової екосистеми.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Технічний борг накопичується, як Ethereum може відновити технічну архітектуру за допомогою RISC-V, знайти шлях до вирішення?
Автор: jaehaerys.eth
Переклад: Глендон, Techub News
ТЛ; ДОКТОР
Ethereum переживає найважливішу архітектурну трансформацію з моменту свого створення: заміна Ethereum Virtual Machine (EVM) на RISC-V. Основною причиною цього зміни є те, що в епоху нульових знань (ZK) EVM стала найбільшим вузьким місцем:
Поточний zkEVM залежить від виконання інтерпретатора, що призводить до зниження швидкості на 50–800 разів;
Пре-компільовані контракти (Precompiles) ускладнюють протокол і збільшують ризики;
Дизайн стеку на 256 біт має дуже низьку ефективність у доказах.
RISC-V може вирішити ці проблеми:
Мінімалізм (приблизно 47 базових команд) + зріла екосистема LLVM (підтримує Rust, C++, Go);
стало фактичним стандартом zkVM (90% проєктів використовують);
Формалізована специфікація SAIL (на відміну від двозначної жовтої книги) може підтримувати строгі перевірки;
Шлях апаратного доказу (ASIC/FPGA) вже тестується (SP1, Nervos, Cartesi).
Міграція відбувається в три етапи:
RISC-V як заміна для попередньо скомпільованих контрактів (низькоризикове тестування);
Двійна віртуальна машина: EVM + RISC-V мають повну взаємодію;
EVM повторно реалізовано всередині RISC-V (аналогічно стратегії Rosetta).
Екосистемний вплив:
Оптимістичні ролапи не постраждають; основна мережа RISC-V не скасує доказ шахрайства, існуючі програми доказів можуть бути скомпільовані для RISC-V (в даний час базуються на MIPS); шлях міграції: розширити поточну інфраструктуру помилок до цільового RISC-V, а не повністю переробляти.
ZK Rollup суттєво виграє (Polygon, zkSync, Scroll → дешевше, швидше, простіше);
Розробники можуть безпосередньо використовувати бібліотеки Rust/Go/Python на L1;
Користувачі можуть отримати знижку на вартість доказу приблизно в 100 разів, що дозволить їм наблизитися до рівня Gigagas (приблизно 10 тис. TPS) на шляху до L1.
Зрештою, Ethereum еволюціонуватиме з «віртуальної машини смарт-контрактів» у мінімальний, перевіряний рівень довіри в Інтернеті, де кінцева мета – «усе має бути ZK-Snark».
Ефіріум перебуває на роздоріжжі
З кінцевою метою "усе має бути ZK-Snark" візією, Ethereum зараз перебуває на порозі найважливішої еволюції архітектури з моменту свого створення. Це обговорення більше не обмежується поступовими оновленнями, а стосується основного перетворення його обчислювального ядра — заміни Ethereum Virtual Machine (EVM). Ця ініціатива є основою більшого бачення "Спростити Ethereum" (Lean Ethereum), яке має на меті систематично спростити весь протокол, розділивши його на три основні компоненти: спрощений консенсус (Lean Consensus), спрощені дані (Lean Data) та спрощене виконання (Lean Execution). А основне питання спрощеного виконання полягає в тому: чи стала EVM, як двигун революції смарт-контрактів, основною перешкодою для майбутнього розвитку Ethereum?
Як зазначив Джастін Дрейк з Фонду Ефіріуму, довгостроковою метою Ефіріуму завжди було «перетворити все на Snark», що є потужним інструментом для посилення всіх рівнів протоколу. Але протягом тривалого часу ця мета більше нагадувала «повітряну замок», оскільки для її досягнення необхідно було реалізувати концепцію в реальному часі. А тепер, коли реалізація в реальному часі поступово стає реальністю, теоретична неефективність EVM перетворилася на термінову проблему, яку потрібно вирішити.
Цей аналіз розгляне технічні та стратегічні аргументи щодо міграції Ethereum L1 на архітектуру команд RISC-V (ISA), що має на меті забезпечити безпрецедентну масштабованість, спростити структуру протоколу та узгодити Ethereum з майбутнім перевірених обчислень.
Що насправді змінилося?
Перш ніж поглиблено досліджувати «чому», спочатку потрібно зрозуміти, «що» саме змінюється.
EVM є середовищем виконання смарт-контрактів Ethereum, це «світовий комп'ютер», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн мав революційний характер, створивши платформу без дозволу, яка сприяла розвитку цілого екосистеми DeFi та NFT. Однак ця спеціалізована архітектура, що існує майже десять років, наразі накопичила значний технічний борг.
В порівнянні, RISC-V не є продуктом, а відкритим стандартом — безкоштовним, універсальним дизайном процесорів «алфавіту». Як підкреслив Джеремі Бруестл на конференції Ethproofs, його ключові принципи роблять його ідеальним вибором для цієї ролі:
Екстремальний мінімалізм: базовий набір команд надзвичайно простий, містить лише близько 40-47 команд. Джеремі описує його як «майже ідеальний приклад надзвичайно спрощеної універсальної машини, яка нам потрібна».
Модульність: додавання більш складних функцій за допомогою опціональних розширень. Це вкрай важливо, оскільки дозволяє мати просту основу, яка може бути розширена за потреби, не навантажуючи базовий протокол зайвою складністю;
Відкита екосистема: вона має величезну та зрілу підтримку інструментальних ланцюгів, включаючи компілятор LLVM, що дозволяє розробникам використовувати популярні мови, такі як Rust, C++ та Go. Як сказав Джастін Дрейк: «Існує багато інструментів, пов'язаних з компіляторами, і створення компілятора надзвичайно складне... Тому наявність цих інструментів для компіляторів має велику цінність.» RISC-V дозволяє Ethereum безкоштовно успадковувати ці готові інструменти.
Проблема витрат інтерпретатора
Необхідність заміни EVM не походить з єдиного дефекту, а викликана низкою фундаментальних обмежень, які в контексті майбутнього, орієнтованого на нульові знання (ZK), стали нестерпними. Ці проблеми охоплюють серйозні вузькі місця в системах доказів ZK, а також ризики, пов'язані з дедалі зростаючою складністю всередині протоколу.
Проблема накладних витрат інтерпретатора
Цим перетворенням найбільш терміновим стимулом є вроджена неефективність EVM в системах нульового знання. Оскільки Ethereum поступово переходить до моделі верифікації стану L1 через ZK-докази, продуктивність доказувача стане кінцевим вузьким місцем.
Проблема полягає в поточному принципі роботи zkEVM. Вони не здійснюють нульове знання безпосередньо для EVM, а замість цього доводять роботу інтерпретатора EVM, який сам був скомпільований у RISC-V. Віталік Бутерін влучно вказав на цю ключову проблему:
"Якщо реалізація zkVM полягає в компіляції виконання EVM в коду RISC-V, то чому не відкрити розробникам смарт-контрактів нижній рівень RISC-V? Це дозволить повністю усунути витрати на зовнішню віртуальну машину."
Цей додатковий шар пояснень призводить до величезних втрат продуктивності. За оцінками, цей шар може призвести до зниження продуктивності на 50 до 800 разів у порівнянні з нативними програмами. Після оптимізації інших вузьких місць (наприклад, переходу на алгоритм хешування Poseidon) ця частина «виконання блоків» все ще споживатиме 80–90% часу на доказ, роблячи EVM остаточною і найупертішою перешкодою для розширення L1. Якщо цей шар буде видалено, Віталік прогнозує, що ефективність виконання може зрости на 100 разів.
Заборгованість пастки попередньо скомпільованих контрактів
Щоб вирішити проблему недостатньої продуктивності EVM у певних криптографічних операціях, Ethereum впровадив попередньо скомпільовані контракти — функції, які спеціально кодуються безпосередньо в протокол. Хоча це було практичним рішенням на той час, сьогодні це спричинило те, що Віталік Бутерін назвав «катастрофічною» ситуацією:
«Попередня компіляція була для нас катастрофічною... вона значно розширила надійний код Ethereum... і на межі провалу консенсусу вона не раз ставила нас на грань краху.»
Складність цього вражає. Віталік, порівнюючи упаковку коду окремого попередньо скомпільованого контракту (modexp) з повним інтерпретатором RISC-V, зазначив, що логіка попередньо скомпільованого коду насправді є більш складною. Додавання нових попередньо скомпільованих контрактів проходить повільний і сповнений політичних ігор процес жорсткого хардфорка, що серйозно заважає інноваціям у застосуваннях, які залежать від нових криптографічних примітивів.
Отже, Віталік зробив тверде висновок: «Я насправді вважаю, що ми повинні негайно припинити створення будь-яких нових попередньо скомпільованих контрактів.»
Технологічний борг архітектури Ethereum
Ядро дизайну EVM відображає застарілі вимоги епохи, але воно вже не може адаптуватися до сучасних обчислень. EVM обрала 256-бітну архітектуру для обробки криптографічних значень, що є вкрай неефективним для 32-бітних або 64-бітних цілих чисел, які зазвичай використовуються в смарт-контрактах. Ціна цієї неефективності особливо висока в системах нульових знань.
Як пояснив Віталік: «Коли використовуються менші числа, кожне число насправді не економить жодних ресурсів, а складність зростає в 2-4 рази.»
Крім того, архітектура стеку EVM менш ефективна, ніж архітектури регістрів RISC-V та сучасних процесорів. Для виконання тих самих операцій потрібно більше інструкцій, що також ускладнює оптимізацію компілятора.
Ці комплексні фактори, включаючи вузькі місця продуктивності ZK-доказів, складність попередньої компіляції та застарілі вибори архітектури, разом створюють переконливу та термінову причину для переходу Ethereum за межі EVM.
RISC-V план: створення більш міцної основи
Переваги RISC-V походять не лише від недоліків EVM, але й з його дизайнерської філософії та вроджених переваг. Його архітектура забезпечує надійну, просту та перевірену основу, що робить його дуже придатним для таких високоризикованих середовищ, як Ethereum.
Чому відкриті стандарти переважають над індивідуальним дизайном
На відміну від індивідуально налаштованих архітектур інструкцій (ISA), які потрібно будувати з нуля, RISC-V є зрілим відкритим стандартом, який може надати три ключові переваги:
досвідчена екосистема
Завдяки впровадженню RISC-V, Ethereum в повній мірі скористався колективними досягненнями в галузі комп'ютерних наук за десятиліття. Як пояснив Джастін Дрейк, це надає Ethereum можливість безпосередньо використовувати світового класу інструменти: «Існує компонент інфраструктури під назвою LLVM, це набір інструментів компілятора, який дозволяє розробникам компілювати мови високого рівня на різні бекенди. RISC-V є одним із підтримуваних бекендів. Отже, якщо ви підтримуєте RISC-V, ви автоматично підтримуєте всі мови високого рівня, які підтримує LLVM.»
Це значно знизило бар'єр для входу для мільйонів розробників, які знайомі з такими мовами, як Rust, C та Go.
Філософія дизайну мінімалізму
Мінімалізм RISC-V є навмисною ознакою, а не обмеженням. Його базовий набір інструкцій містить лише близько 47 інструкцій, що робить ядро віртуальної машини надзвичайно простим. Ця простота є величезною перевагою для безпеки, оскільки менша довірена база коду легше піддається аудитам і формальній верифікації.
Фактичний стандарт у сфері ZK
Більш важливо, що екосистема zkVM вже зробила самостійний вибір. Як підкреслив Джастін Дрейк, з даних Ethproofs можна побачити чітку тенденцію: «RISC-V є провідною ISA для бекенду zkVM.»
В 10 zkVM, які можуть підтвердити блоки Ethereum, 9 обрали RISC-V як цільову архітектуру. Це ринкове зближення випускає потужний сигнал: використання RISC-V в Ethereum не є спекулятивною спробою, а слідування перевіреному ринковому стандарту.
Спроектовано для довіри, не лише для виконання
Окрім екосистеми, внутрішня архітектура RISC-V також особливо підходить для створення безпечних та перевіряємих систем.
По-перше, RISC-V має офіційну, машинозчитувану специфікацію, яка називається SAIL. Це є величезним покращенням у порівнянні зі специфікацією Ethereum Virtual Machine (EVM), яка в основному існує у вигляді документації (жовта книга) і може містити неоднозначності. Специфікація SAIL надає «золотий стандарт», здатний надати математичні докази, які є критично важливими для коректності протоколу, що є ключовим для захисту протоколів з величезною вартістю. Як зазначив Алекс Хікс з Фонду Ethereum (EF) під час телефонної конференції Ethproofs, це дозволяє zkVM схемам перевіряти «відповідно до офіційної специфікації RISC-V».
По-друге, RISC-V містить привілейовану архітектуру, яка часто ігнорується, але є критично важливою для безпеки. Вона визначає різні рівні виконання, головним чином включаючи користувацький режим (для ненадійних застосунків, таких як смарт-контракти) та режим нагляду (для надійних "виконавчих ядер").
У моделі RISC-V смарт-контракти, що працюють в режимі користувача, не можуть безпосередньо отримати доступ до стану блокчейну. Натомість вони повинні надсилати запит до довіреного ядра, що працює в режимі моніторингу, через спеціальну інструкцію ECALL (виклик середовища). Цей механізм створює безпечну межу, яка забезпечується апаратним забезпеченням, що робить його більш надійним і легшим для перевірки, ніж чисто програмна модель пісочниці EVM.
Візія Віталіка
Ця трансформація задумана як поступовий, багатоступеневий процес для забезпечення стабільності системи і зворотної сумісності. Цей підхід, описаний Віталіком Бутеріним, спрямований на досягнення поступового розвитку, а не революційних змін.
Перший крок: попередня компіляція заміни
На початковому етапі слід застосувати найбільш консервативний підхід, впроваджуючи обмежені функції нової віртуальної машини (VM). Як запропонував Віталік, «ми можемо почати з обмежених сценаріїв використання нової віртуальної машини, наприклад, замінивши функціонал попередньої компіляції». Це передбачає призупинення нових функцій EVM попередньої компіляції, натомість реалізуючи необхідні функції за допомогою програм RISC-V, схвалених через білий список. Цей підхід дозволяє новій віртуальній машині проводити польові випробування в основній мережі в умовах низького ризику, при цьому клієнт Ethereum виступає посередником між двома середовищами виконання.
Другий крок: спільне існування двох віртуальних машин
На наступному етапі буде «безпосередньо відкрито нову віртуальну машину для користувачів». Під час розгортання смарт-контракту можна додати мітку, щоб вказати, чи є його байт-код EVM або RISC-V. Ключова особливість полягає в забезпеченні безшовної взаємодії: «два типи контрактів зможуть викликати один одного». Це буде реалізовано через системні виклики (ECALL), при цьому клієнт Ethereum виступає в ролі посередника виконавчого середовища.
Третій крок: EVM як імітаційний контракт («Rosetta» стратегія)
Кінцевою метою є досягнення остаточного спрощення протоколу. На цьому етапі «ми реалізуємо EVM як одну з реалізацій нової віртуальної машини». Нормативний EVM стане формально перевіреним смарт-контрактом, що працює на рідному RISC-V L1. Це не тільки забезпечує постійну підтримку старих додатків, але й дозволяє розробникам клієнтів підтримувати лише один спрощений виконавчий механізм.
Цепна реакція всього екосистеми
Перехід від EVM до RISC-V - це не лише основний протокол, він матиме глибокий вплив на всю екосистему Ethereum, потенційно перетворюючи досвід розробників, кардинально змінюючи конкурентне середовище рішень другого рівня та відкриваючи нові моделі економіки доказів.
Перебудова ролапу: шляхове розмежування між Optimistic та ZK
Перехід на виконавчий шар RISC-V на L1 матиме радикально різний вплив на два основні типи Rollups.
Модель безпеки оптимістичних роллапів (такі як Arbitrum, Optimism) залежить від повторного виконання спірних транзакцій на Layer-1 для вирішення доказів шахрайства. Навіть якщо Layer-1 Ethereum перейде на RISC-V, ці системи не зазнають кардинальних змін. Як пояснив один із співзасновників Optimism: «Якщо ми перенесемо Ethereum на RISC-V, ланцюги Optimistic також не зупиняться. Вам просто потрібно скомпілювати віртуальну машину RISC-V в програму доказу. Також не потрібно використовувати Asterisc. Існуюча система доказів на базі MIPS також не зупиниться — вам просто потрібно скомпілювати віртуальну машину RISC-V в MIPS.
Це означає, що модель протидії шахрайству залишилася неушкодженою. Коригування є технічними: інтеграція нової віртуальної машини RISC-V в існуючу інфраструктуру, а не повне пер redesign системи. Залишилися виклики інженерних деталей, такі як облік газу, ефективність і вартість.
У порівнянні, ZK Rollups отримають величезну стратегічну перевагу. Абсолютна більшість ZK Rollups вже використовує RISC-V як свою внутрішню ISA. Використання тієї ж рідної мови L1 дозволяє досягти більш тісної та ефективної інтеграції. Джастін Дрейк описав майбутнє «рідних Rollups», де L2 по суті є спеціалізованим екземпляром середовища виконання L1, яке використовує вбудовану L1 VM для безшовного розрахунку. Ця інтеграція призведе до наступних змін:
Спрощений технічний стек: усунення складного моста між внутрішнім виконанням RISC-V рівня L2 та EVM;
Реалізація повторного використання інструментів та коду: компілятори, налагоджувачі та інструменти формальної верифікації, розроблені для середовища L1 RISC-V, можуть безпосередньо використовуватися L2 для зниження витрат на розробку.
Скоординовані економічні стимули: витрати Gas на L1 будуть точніше відображати фактичні витрати на виконання ZK-доказів RISC-V, що дозволить створити більш обґрунтовану економічну модель.
Нова ера для розробників і користувачів
Для розробників екосистеми Ethereum це перетворення буде поступовим, а не руйнівним.
Для розробників ключова перевага полягає в тому, що вони можуть увійти в більш широкий і зрілий світ розробки програмного забезпечення. Як зазначив Віталік Бутерін, розробники «зможуть писати контракти на Rust, і ці дві мови почнуть співіснувати». Водночас він прогнозує, що «Solidity і Vyper залишаться популярними протягом довгого часу», оскільки вони мають елегантну логіку розумних контрактів. Можливість використовувати основні мови та їх багаті бібліотеки через інструментальний набір LLVM стане революційною зміною. Віталік описує це як «досвід, схожий на Node.JS», в якому розробники в основному можуть використовувати одну й ту ж мову для написання коду на блокчейні та поза ним.
Для користувачів остаточна вигода полягає в більш економічній та потужній мережі. Очікується, що витрати на підтвердження зменшаться приблизно в 100 разів — з кількох доларів за транзакцію до кількох центів — що безпосередньо призведе до зниження витрат на розрахунок Layer-1 та Layer-2. Ця економічна доцільність відкриє перспективи «Gigagas L1», метою якого є досягнення приблизно 10000 TPS на L1, що надасть підтримку для більш складних та цінних застосувань на блокчейні в майбутньому.
Succinct Labs та SP1: доведення того, що майбутнє вже тут
Теоретичні переваги RISC-V вже були реалізовані командами, такими як Succinct Labs, і їхні результати стали потужним прикладом для всієї пропозиції.
SP1, розроблений Succinct Labs, є високопродуктивним, відкритим zkVM, побудованим на основі RISC-V, який перевіряє життєздатність нового архітектурного підходу. Він використовує концепцію «попередньо скомпільованого централізованого» дизайну, що ідеально вирішує криптографічні обмеження EVM. На відміну від традиційних повільних, жорстко закодованих методів попередньої компіляції, SP1 розвантажує інтенсивні операції, такі як хешування Keccak, через стандартні команди ECALL, а також спеціально розроблені та вручну оптимізовані ZK-кола. Це забезпечує продуктивність налаштованого апаратного забезпечення разом з гнучкістю програмного забезпечення.
Вплив практики команди чітко проявився, їхній продукт OP Succinct використовує SP1 для реалізації "ZK-офікації" (ZK-ify) Optimistic Rollup. Як пояснила співзасновниця Succinct Ума Рой:
«Ваш OP Stack Rollup не потрібно чекати 7 днів для завершення остаточного підтвердження та виведення... тепер це займає лише 1 годину. Це значно підвищує швидкість остаточного підтвердження, це просто чудово.»
Це вирішує одну з ключових проблем усього екосистеми OP Stack. Крім того, інфраструктура Succinct «Succinct Prover Network» була розроблена як децентралізований ринок для генерації доказів, що демонструє життєздатну економічну модель для майбутнього верифікованих обчислень. Їхня робота — це не лише перевірка концепції, а й реальний план на майбутнє, описаний у цій статті.
Як Ethereum знижує ризики
Ключова перевага RISC-V полягає в тому, що вона робить кінцеву мету формалізованої верифікації — доведення правильності системи за допомогою математики — досяжною метою. Специфікація EVM написана природною мовою в Жовтій книзі (Yellow Paper), що ускладнює формалізацію. Натомість RISC-V має офіційну, машиночитну специфікацію SAIL, яка надає чітке «золоте посилання» для її поведінки.
Це відкриває чіткий шлях до більшої безпеки. Як зазначив Алекс Хікс з Фонду Ethereum, наразі проводиться робота над "екстракцією zkVM RISC-V схем з офіційної специфікації RISC-V до Lean для формальної верифікації". Це знаковий прогрес, який переносить довіру з схильних до помилок людських реалізацій на перевірювані математичні докази, що забезпечує прорив у безпеці.
Основні ризики трансформації
Хоча архітектура RISC-V має багато переваг у L1, вона також зіткнеться з новими складними викликами.
Проблема вимірювання газу: створення детермінованої та справедливої моделі газу для універсальної ISA є однією з найскладніших проблем. Простий спосіб підрахунку інструкцій піддається загрозі атаки відмови в обслуговуванні. Наприклад, зловмисник може створити програму, що повторно викликає кешовану програму, тим самим досягаючи високого використання ресурсів за дуже низьку плату за газ.
Проблеми безпеки інструментальних засобів та «відтворювального збірки»: це, можливо, найбільший і недооцінений ризик у процесі трансформації. Модель безпеки переходить від віртуальної машини довіри до довіри до компілятора, що використовується кожним розробником (наприклад, LLVM), і ці компілятори є надзвичайно складними, і відомо, що в них є вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на перший погляд безпечний вихідний код на шкідливий байт-код. Крім того, забезпечити, щоб двійкові файли після компіляції в ланцюзі повністю відповідали певному відкритому вихідному коду, тобто проблема «відтворювальної збірки», також надзвичайно важко, оскільки незначні відмінності в середовищі зборки можуть призвести до різних двійкових файлів.
стратегії пом'якшення
Дорога вперед вимагає багатоетапної стратегії захисту.
Поетапний запуск: Поетапний та багатофазний план переходу є основною стратегією пом'якшення ризиків. Спочатку впроваджуючи RISC-V як попередньо скомпільовану альтернативу, а потім здійснюючи розгортання у двовіртуальному середовищі, спільнота може накопичувати операційний досвід та будувати впевненість у низькоризиковому середовищі до того, як відбудуться будь-які незворотні зміни.
Повна перевірка: нечітке тестування та формальна верифікація. Хоча формальна верифікація є остаточною метою, вона повинна супроводжуватися постійним, інтенсивним тестуванням. Як показав Валентин з Diligence Security на телефонній конференції Ethproofs, їхній нечіткий тестер Argus вже виявив 11 ключових вразливостей цілісності та коректності в провідному zkVM. Це доводить, що навіть у найкращих системах є вразливості, які можна виявити лише через суворе протистояння тестуванню.
Стандартизація: для уникнення фрагментації екосистеми спільнота повинна єдино прийняти єдиний, стандартизований профіль RISC-V. Це, ймовірно, буде комбінація ABI, сумісна з RV64 GC та Linux, оскільки ця комбінація може забезпечити найширшу підтримку з основних мов та інструментів, що дозволить максимально використати переваги нової екосистеми.