Коли Ethereum відмовиться від EVM на користь RISC-V: Переробка архітектури, яка може змінити обчислення у блокчейні

Ethereum стоїть на переломному етапі. Хоча Віртуальна Машина Ethereum (EVM) забезпечила понад десятиліття blockchain-інновацій — заклавши основу для DeFi та NFT — стає дедалі ясніше, що ця спеціально створена рівень виконання не був розроблений для обчислювального майбутнього, яке вже настає. Перехід до нуль-знаннєвих (ZK) підтверджень і виникнення загальної структури машини у стандартах системного програмування змушують задуматися: чи зможе застаріла архітектура Ethereum адаптуватися, чи їй потрібне повне переосмислення?

Згідно з технічними дослідниками та керівництвом Фонду Ethereum, відповідь стає все більш однозначною. Протокол прокладає шлях до заміни EVM на RISC-V, відкриту архітектуру інструкцій, яка обіцяє розблокувати масштабованість, зменшити складність і узгодити Ethereum із ширшим екосистемою підтверджуваного обчислення.

Криза продуктивності, про яку ніхто не говорить: чому EVM не може наздогнати ZK

Обмеження не є одразу очевидними, але вони фундаментальні. Коли Ethereum починає доводити свої станові переходи за допомогою нуль-знаннєвих доказів — важливий шлях для масштабування L1 — поточна реалізація zkEVM створює руйнівний штраф за продуктивністю.

Ось технічна реальність: сьогоднішній zkEVM не доводить безпосередньо виконання EVM. Замість цього він доводить інтерпретатор, який був скомпільований у код RISC-V. Цей додатковий рівень абстракції — причина проблеми. Вартість продуктивності? Оцінки коливаються від 50 до 800 разів повільніше за нативне виконання. Навіть після оптимізації інших компонентів — наприклад, перехід на більш ефективні алгоритми хешування — виконання блоків залишається вузьким місцем, що становить 80-90% всього часу генерації доказів.

Як коротко сформулював Віталік Бутерін: якщо zkVM у кінцевому підсумку компілює все у RISC-V, навіщо змушувати розробників смарт-контрактів працювати через проміжний шар EVM, який додає лише накладні витрати?

Це не теорія. Відставання у продуктивності безпосередньо впливає на економіку. Усунення цього інтерпретативного шару може підвищити ефективність виконання приблизно у 100 разів — різниця, яка відділяє життєздатне масштабування від постійних заторів.

Технічний борг, закопаний у протоколі

Вибори дизайну EVM були цілком логічними у 2015 році, але вони закріпилися у обмеження. Розглянемо три конкретні проблеми:

Попередньо скомпільовані контракти як тимчасове рішення, яке не спрацювало. Коли EVM не могла ефективно обробляти певні криптографічні операції, Ethereum додав функції у вигляді хардкодованих контрактів — попередньо скомпільованих. Це здавалося тимчасовим рішенням. Сьогодні це створює те, що Віталік називає «поганою» ситуацією: ці модулі роздули довіру до коду Ethereum до незбалансованих рівнів і спричинили повторювані ризики безпеки, що загрожують збоєм консенсусу.

Додавання нових попередньо скомпільованих контрактів вимагає суперечливих хард-форків і включає обгортковий код складніший за цілі реалізації RISC-V. Віталік підсумовує: протокол має припинити додавати попередньо скомпільовані контракти взагалі.

Архітектура 256-біт для неправильного випадку використання. Стек EVM був розроблений для криптографічних значень, але більшість смарт-контрактів працює з 32- або 64-бітними цілими числами. Це створює жорстке співвідношення ефективності: менші числа не економлять ресурси, тоді як подвоєння або потроєння складності збільшує навантаження. У системах ZK доказів ця неефективність ще більш виражена.

Стек проти регістрів. Архітектура EVM на основі стеку вимагає більше інструкцій, ніж модель регістрів RISC-V, для виконання однакових операцій, що ускладнює оптимізацію компілятора і збільшує навантаження на генерацію доказів.

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

RISC-V: чому відкритий стандарт краще за індивідуальний дизайн

RISC-V — це не власна технологія. Це відкритий стандарт набору інструкцій — фактично, безкоштовний план для проектування процесорів. Його застосування для цієї ролі не випадкове і не експериментальне.

Чому простота — сила. Базовий набір інструкцій RISC-V містить приблизно 47 команд. Це радикальний мінімалізм, навмисний. Менше інструкцій означає менший довірений код — легше аудити, формально перевіряти і забезпечити безпеку. Як підкреслював Джеремі Брустл на галузевих конференціях, цей дизайн «майже ідеальний для тієї супер-мінімальної машини, яку нам потрібно».

Зрілість екосистеми через LLVM. Обравши усталений стандарт, Ethereum отримує доступ до десятиліть інфраструктури компіляторів. За допомогою підтримки LLVM розробники можуть використовувати будь-яку популярну мову програмування — Rust, C++, Go, Python — і компілювати безпосередньо у RISC-V. Це усуває необхідність створювати цілі екосистеми з нуля. Джастін Дрейк підкреслює стратегічну перевагу: «Ми отримуємо підтримку всіх високорівневих мов, підтримуваних LLVM, безкоштовно».

Збігання zkVM вже відбувається. Ринок вже проголосував. З десяти найпрогресивніших реалізацій zkVM, здатних довести Ethereum-блоки, дев’ять обрали RISC-V. Це не спекуляція — це практична валідація. Екосистема нуль-знаннєвих доказів стандартизується на RISC-V як ціль виконання, тому застосування Ethereum — це не азарт, а узгодження з напрямком галузі.

Можливість формальної перевірки. На відміну від специфікації Yellow Paper EVM — написаної природною мовою і схильної до неоднозначностей — RISC-V має офіційну специфікацію SAIL, яка машиночитна. Ця математична строгость дозволяє безпосередньо перевіряти схеми zkVM відповідно до специфікації, створюючи шлях до доведеної коректності, яку EVM ніколи не міг запропонувати.

Вбудовані межі безпеки апаратного забезпечення. RISC-V включає привілейовану архітектуру з режимом користувача і режимом керівника. Смарт-контракти працюють у режимі користувача і не можуть безпосередньо отримати доступ до стану блокчейну; натомість вони надсилають запити ECALL до довіреного ядра. Це створює межу безпеки, яка забезпечується самою архітектурою процесора — набагато надійніше, ніж програмне ізоляційне середовище. Як пояснив Дієго з Cartesi: «Всі ці механізми захисту — частина стандарту RISC-V».

Трифазний перехід: зменшення ризиків через поступовість

Ethereum не планує раптового переходу. Міграція відбуватиметься за обережним планом:

Фаза 1: RISC-V як заміна попередньо скомпільованих контрактів. Спочатку протокол припиняє додавати нові попередньо скомпільовані контракти EVM. Замість цього нову криптографічну функціональність реалізують через білий список RISC-V програм. Це дозволяє тестувати нову архітектуру у головній мережі у контрольованому, низькоризиковому режимі перед широким впровадженням.

Фаза 2: Співіснування двох віртуальних машин. Смарт-контракти отримують можливість оголошувати, чи їх байткод цілиться у EVM чи RISC-V. Важливо, що контракти в обох середовищах можуть викликати один одного через стандартизовані системні виклики ECALL. Це створює гібридний період, коли обидві архітектури працюють разом, підтверджуючи взаємовідповідність перед повним міграцією.

Фаза 3: EVM як симульований контракт. Кінцева мета — розглядати EVM як високорівневу мову — формально перевірений смарт-контракт, що працює нативно на RISC-V L1. Спадкові застосунки залишаються підтримуваними, але основний рівень виконання протоколу стає чистим RISC-V, що значно спрощує розробку і підтримку клієнтів.

Такий поетапний підхід перетворює потенційно катастрофічну міграцію у керовану еволюцію.

Реорганізація екосистеми: переможці та програшні

Цей перехід не однаково вплине на всі Layer 2 — він створює переможців і програшних.

Оптимістичні Rollups стикаються з архітектурними викликами. Проєкти, як Arbitrum і Optimism, базуються на доказах шахрайства: оскаржити транзакцію означає її повторне виконання на L1. Якщо L1 змінить VM з EVM на RISC-V, ця модель безпеки зруйнується. Ці проєкти мають вибір: або витратити великі зусилля на перепроектування доказів шахрайства під нову архітектуру, або повністю відмовитися від безпеки Ethereum. Обидва варіанти — дорогі.

ZK Rollups отримують стратегічну перевагу. Проєкти, як Polygon, zkSync і Scroll, вже стандартизували RISC-V внутрішньо. L1, що «говорить їхньою мовою», усуває потребу у перекладачах. Те, що Фонд Ethereum називає «рідними Rollups», стає можливим: L2 стає спеціалізованим інстансом виконання L1, що ділиться інструментами, компіляторами і формальними методами перевірки. Практично це означає, що команди L2 більше не будують мости між несумісними VM, витрати на розробку зменшуються, а економіка газу стає більш раціональною.

Досвід розробників змінюється кардинально. Замість вивчення Solidity, розробники зможуть писати на Rust, Go або будь-якій мові, підтримуваній LLVM. Контракти зможуть використовувати зрілі бібліотеки з ширшого програмного середовища. Віталік порівнює це з Node.js: код на блокчейні і поза ним — об’єднаний у одній мові, з однаковими інструментами. Це зниження бар’єрів, ймовірно, переформатує, хто може брати участь у розробці блокчейну.

Економіка користувачів значно покращується. Вартість доказів зменшується приблизно у 100 разів. Тарифи за транзакції для L1 і L2 зменшуються відповідно. Це відкриває шлях до «Gigagas L1» — приблизно 10 000 транзакцій за секунду, що дозволяє складним застосункам із високою пропускною здатністю і безпекою.

Succinct Labs і SP1: доведення, що бачення працює вже сьогодні

Перехід не є лише теоретичним. Succinct Labs вже продемонстрували практичні переваги RISC-V через SP1 — відкритий zkVM, що доводить архітектурну тезу.

Ідея SP1: він використовує «орієнтований на попередньо скомпільовані контракти» дизайн, що вирішує криптографічне вузьке місце EVM без створення проблеми складності. Інтенсивні операції, як Keccak-хешування, виконуються у спеціалізованих zk-ланцюгах, викликаються через стандартні ECALL. Це поєднує продуктивність апаратного забезпечення з гнучкістю програмного забезпечення.

Практичний ефект очевидний. Продукт OP Succinct від Succinct дає можливість Optimistic Rollups мати нуль-знаннєві можливості. Результат: замість очікування сім днів для остаточного підтвердження і виведення, транзакції завершується приблизно за годину. Це вирішує критичну проблему швидкості для всього екосистеми OP Stack.

Succinct також керує децентралізованою мережею Prover, створюючи ринок для генерації доказів. Це не концепт — це план економічної моделі, яка керуватиме підтверджуваними обчисленнями у масштабі.

Приховані ризики: що ще може піти не так

Незважаючи на переваги RISC-V, перехід вводить нові ризики:

Складність вимірювання газу. Визначення справедливої, детермінованої вартості газу для загальних інструкцій — нерозв’язана проблема. Просте підрахунок інструкцій вразливий до атак відмови у обслуговуванні. Зловмисник може створити програми, що багаторазово викликають пропуски кешу, споживаючи величезні ресурси при мінімальній вартості газу. Це загрожує стабільності мережі і економічним моделям.

Безпека інструментарію і відтворювані збірки. Це найнебезпечніша і недооцінена проблема. Безпека переходить від залежності від on-chain VM до off-chain компіляторів, таких як LLVM — складного програмного забезпечення, яке може містити вразливості. Зловмисник, що експлуатує баги компілятора, може перетворити безпечний, здавалося б, вихідний код у шкідливий байткод. Не менш важливо — забезпечити, щоб скомпільовані бінарні файли збігалися з публічно доступним вихідним кодом (проблема відтворюваних збірок) у різних середовищах збірки. Малі відмінності у середовищі породжують різні результати, що створює проблеми довіри і прозорості.

Ці ризики можна вирішити, але вони не є тривіальними.

Зменшення ризиків: багаторівнева оборона

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

Агресивне тестування і формальна перевірка. Хоча формальна перевірка — довгострокова мета, її потрібно поєднувати з постійним інтенсивним тестуванням. Такі компанії, як Diligence, вже виявили 11 критичних вразливостей у zkVM через fuzz-тестування. Така закономірність — вразливості ховаються у добре спроектованих системах — вимагає паралельних стратегій тестування і перевірки, а не послідовних.

Стандартизація для запобігання фрагментації. Спільнота має прийняти один стандарт RISC-V, ймовірно RV64GC з Linux-совісним ABI. Це максимізує підтримку інструментарію і запобігає розпорошенню екосистеми, дозволяючи розробникам повністю скористатися перевагами LLVM.

Верифікований інтернет-слій: довгострокова стратегія Ethereum

Перехід від EVM до RISC-V — це не лише про покращення продуктивності. Це про переорієнтацію Ethereum з «віртуальної машини смарт-контрактів» у фундамент підтверджуваної довіри для загальнодоступних обчислень у інтернеті.

Фрейм Віталіка відображає кінцеву мету: «Кінцева ціль включає… зробити все ZK-snarkified.»

Ця трансформація відповідає принципу «Легке виконання» — частині ширшої концепції «Легкий Ethereum». Протокол спрощується з монолітної VM до мінімалістичного рівня розрахунків і доступності даних, оптимізованого для підтверджуваних обчислень. Апаратне прискорення доказів (ASICs і FPGAs від SP1, Nervos, Cartesi) стає можливим, коли набір інструкцій стабілізується навколо RISC-V.

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

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

Ця трансформація починається вже зараз. Проєкти, як Ethproofs, збирають колаборативні дані, необхідні для реалізації цього зсуву. Команди, як Succinct Labs, пропонують практичні плани. За 6-12 місяців очікуйте перших альтернативних попередньо скомпільованих контрактів, що працюють на RISC-V у головній мережі Ethereum — це ознаменує початок кінця для Віртуальної Машини Ethereum, якою ми її знаємо.