Шар виконання Ethereum на переломному етапі: чому архітектура RISC-V стає неминучою

Ethereum стоїть на критичному перехресті. Фундаментальна архітектура, яка забезпечувала революцію DeFi та підтримувала екосистему NFT, стикається з зростаючими обмеженнями продуктивності, які традиційна оптимізація вже не може вирішити. Відповідь, що виникає від спільноти, — це не патч, а фундаментальна перебудова: перехід від Ethereum Virtual Machine (EVM) до RISC-V як основного середовища виконання.

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

Кризовий стан продуктивності у системах нульової знання

Корінь проблеми — у її простоті: Ethereum безпосередньо не доводить EVM. Замість цього проєкти створюють інтерпретатори, що перетворюють байткод EVM у інструкції, сумісні з доказами — зрештою, все одно компілюючись у RISC-V. Цей архітектурний шар додає руйнівний наклад.

Поточні реалізації zkEVM зазнають зниження продуктивності у 50–800 разів порівняно з нативним виконанням інструкцій. Навіть після агресивної оптимізації криптографічних операцій (заміни на Poseidon-хешування, наприклад), виконання блоку залишається вузьким місцем, споживаючи 80–90% загального часу генерації доказів. Повністю усунувши шар інтерпретатора, дослідники протоколів оцінюють, що ефективність виконання може покращитися у 100 разів — перетворюючи генерацію доказів із економічно недосяжної у практичну.

Ця неефективність глибша, ніж наклад інтерпретатора. Архітектура стеку EVM на 256 біт була розроблена для криптографічних операцій, але марнує ресурси на типову логіку смарт-контрактів із 32 або 64-бітними цілочисельними даними. У системах доказів нульової знання кожна операція вимагає створення криптографічних доказів правильності; ця марнотратність зростає експоненційно. Архітектура на основі регістрів RISC-V, навпаки, відповідає сучасним принципам проектування ЦП і дозволяє оптимізації компілятора, які фундаментально недоступні стековій моделі.

Технічний борг: пастка попередніх компіляцій

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

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

Розробники протоколів дійшли згоди: нових попередніх компіляторів не буде. Майбутній шлях архітектури — перейти до системи, де криптографічні інновації можна впроваджувати через програмований, перевірений код, а не через зміни у протоколі.

Чому RISC-V, а не інша альтернатива

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

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

Спадщина екосистеми: прийняття RISC-V відкриває доступ до LLVM-компілятора — результату десятиліть колективних зусиль інженерів. Розробники, що пишуть на Rust, Go, C++ або Python, можуть компілювати безпосередньо у RISC-V за допомогою зрілих, виробничих інструментів. Це усуває необхідність створювати паралельну програмну екосистему з нуля, що затримало б впровадження на роки.

Фактичний стандарт ZK: ринок уже визначився. Дев’ять провідних zkVM-проектів (включно з реалізаціями Succinct Labs, Nervos, Cartesi та інших) незалежно зійшлися на RISC-V. Це не просто консенсус — це технологічна неминучість. Впровадження RISC-V Ethereum узгоджує протокол із інфраструктурними проєктами, які вже почали його будувати.

Трифазна стратегія переходу

Замість революційної заміни Ethereum виконає ретельно послідовний перехід, спрямований на збереження зворотної сумісності та стабільності роботи:

Фаза 1: Заміна попередніх компіляторів

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

Фаза 2: Співіснування двох віртуальних машин

Розумні контракти явно оголошують, чи їх байткод орієнтований на EVM або RISC-V через тегову систему. Обидві середовища досягають безшовної взаoperодії через системні виклики (ECALL), що дозволяє виклик функцій між рівнями. Цей період дає змогу екосистемі поступово мігрувати без необхідності негайних рішень.

Фаза 3: EVM як реалізований контракт

Останній етап — розглядати застарілий EVM як формальні специфікації, що працюють в межах середовища RISC-V — подібно до того, як Linux може працювати на RISC-V, незважаючи на те, що спочатку орієнтувався на x86. Протокол зберігає постійну підтримку існуючих додатків, тоді як розробники клієнтів підтримують один спрощений механізм виконання. Технічний борг перетворюється на реалізовуваний код, а не на обтяження протоколу.

Реорганізація екосистеми: розходження ролл-апів

Перехід до нативного виконання на RISC-V створює радикально різні сценарії для конкуренції Layer 2:

Оптимістичні ролл-апи під тиском

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

Стратегічна перевага zk-Rollups

ZK-Rollups вже працюють нативно на архітектурі RISC-V. L1, що “говорить тією ж мовою”, дозволяє, як називає Джастін Дрейк, “рідні ролл-апи” — L2, що функціонують як спеціалізовані конфігурації середовища виконання L1. Практичні наслідки:

• Швидкість розробки: L2-команди усувають складний міст між внутрішнім виконанням RISC-V і зовнішніми рівнями розрахунків. Інструменти компіляції, налагоджувачі та утиліти верифікації, створені для L1, стають безпосередньо застосовними до L2 без модифікацій.
• Економічна узгодженість: ціна газу на L1 прямо відображає обчислювальні витрати RISC-V-заснованої zk-перевірки, а не EVM. Це створює точніші стимули та усуває економічні перекоси між шарами.
• Економіка доказів: створення криптографічних доказів для забезпечення L2 стає значно дешевшим. Вартість підтвердження на L1 зменшується з кількох доларів до кількох центів за транзакцію, відкриваючи нові економічні моделі для високочастотних застосунків.

Досвід розробників: від пісочниці до екосистеми

Ця трансформація демократизує розробку у мережі. Зараз Solidity і Vyper — єдині практичні мови для смарт-контрактів — спеціалізовані інструменти, які потрібно вивчати для роботи з блокчейном. За RISC-V розробники пишуть у Rust, Go або Python, використовуючи ті ж бібліотеки, фреймворки та інструменти налагодження, що й для традиційного програмного забезпечення.

Віталік Бутерін описав це як досягнення “досвіду у стилі Node.js” — коли розробники пишуть і внутрішню, і зовнішню логіку у однакових мовах із однаковими інструментами. Психологічний і практичний бар’єр “розробки для блокчейну” як спеціалізованої сфери значною мірою зникає. Нові розробники можуть застосовувати існуючий досвід без повторного навчання.

Для існуючих розробників Solidity перехід триватиме роками. Елегантні абстракції смарт-контрактів залишаться популярними. Але можливість створювати складні стейт-машини та обчислювальну логіку мовами загального призначення змінює межі можливого — особливо для застосунків із високими обчислювальними вимогами або складними структурами даних.

Точка зору Succinct Labs

Теорія перетворюється у реальність через SP1 — високопродуктивний zkVM, розроблений Succinct Labs, що працює нативно на RISC-V. SP1 підтверджує всю технічну тезу через виробничу реалізацію, а не академічну статтю. Він демонструє, що виконання на RISC-V генерує докази за економічно досяжними витратами, зберігаючи сумісність із моделлю безпеки Ethereum.

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

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

Безпека через простоту і формалізацію

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

Дослідники Ethereum Foundation вже отримують zkVM-ланцюги для формальної перевірки відповідності офіційним специфікаціям RISC-V за допомогою Lean theorem provers. Це — поколінний рівень безпеки: довіра переходить від людських помилок до математично доведених доказів.

Привілейована архітектура RISC-V (відрізняє режим користувача від режиму керівника) забезпечує додаткові рівні безпеки. Смарт-контракти у режимі користувача не можуть безпосередньо отримати доступ до стану блокчейну; вони надсилають запити до довірених ядер через стандартизовані ECALL-інструкції. Це закладає межі безпеки на архітектурному рівні, а не покладається на програмні ізоляційні середовища, що мають довгу історію вразливостей.

Реальні ризики і виклики

Перехідний шлях включає нерозв’язані проблеми, що потребують серйозної уваги:

Складність обліку газу

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

Безпека ланцюжка поставки компіляторів

Модель безпеки змінюється з довіри до ончейн-віртуальних машин на довіру до зовнішніх інструментів, таких як LLVM. Комп’ютери-компілятори — надзвичайно складні системи, що містять тисячі рядків коду з оптимізаційними проходами, створюючи поверхні для атак. Вразливість у компіляторі може перетворити безпечний вихідний код у зловмисний байткод, що важко виявити статичним аналізом.

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

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

Мультишаровий захист

Зменшення ризиків вимагає комплексних, багаторівневих підходів, а не односторонніх рішень:

Поступове впровадження

Трифазний перехід — ключова стратегія управління ризиками. На ранніх етапах RISC-V вводиться у таких умовах, що невдачі мають обмежений вплив. Екосистема набирає досвіду і впевненості поступово, уникаючи незворотніх зобов’язань до накопичення достатніх доказів.

Агресивне тестування і верифікація

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

Стандартизація конфігурацій

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

Верифікований інтернет-слій

Перехід від EVM до RISC-V — це не просто технічна зміна, а перехід Ethereum від спеціалізованої системи віртуальної машини для смарт-контрактів до фундаментально нової — мінімальної, перевіреної інфраструктури довіри для інтернету.

Ця трансформація передбачає специфічні технічні компроміси: баланс між 100-кратним зростанням продуктивності за рахунок ZK-нативного виконання і зобов’язаннями щодо зворотної сумісності; спрощення і водночас збереження мережевих ефектів, що захищають існуючий EVM; вибір універсальності екосистеми і управління залежностями від сторонніх інструментів.

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

Як кажуть: доводячи правильність програмного забезпечення, відкриваємо нову еру криптографії. Інфраструктура вже існує. Технічний аргумент переконливий. Залишився лише один фактор — виконання.