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

Екосистема Ethereum стоїть на переломному етапі. Що починалося як революційна платформа для смарт-контрактів, з часом накопичило рівні технічної складності, які тепер загрожують його масштабованості. У центрі цієї проблеми знаходиться Віртуальна Машина Ethereum (EVM)— базовий рівень виконання, що забезпечив успіх платформи, але все більше виступає як обмежуючий фактор у епосі нуль-знань та високопродуктивної верифікації.

Криза продуктивності: коли EVM зустрів нуль-знаньні доведення

Корінь проблеми масштабування Ethereum не є загадкою. З переходом мережі до систем верифікації на основі доведень нуль-знань, з’явилася фундаментальна неефективність у тому, як EVM взаємодіє з ZK-доведеннями. Поточні реалізації zkEVM не доводять безпосередньо саму віртуальну машину. Замість цього вони доводять інтерпретатор EVM, який потім компілюється у байткод RISC-V. Ця архітектурна опосередкованість створює величезний штраф у продуктивності— за оцінками, накладні витрати становлять від 50 до 800 разів повільніше за нативне виконання програми.

Проблема ускладнюється при врахуванні економіки мережі. Навіть із оптимізованими хеш-алгоритмами, такими як Poseidon, генерація доведень для виконання блоку все ще споживає 80-90% загального часу доведення. Віталік Бутерін прямо висловив цю проблему: якщо базова архітектура все одно компілюється у RISC-V, навіщо взагалі зберігати інтерпретативний рівень EVM? Відповідь проста—усунути його.

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

Проблема боргу: попередньо скомпільовані модулі як технічний швидкий пісок

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

Обсяг цієї проблеми вражає. Обгортковий код для одного попередньо скомпільованого контракту (такого як modexp) перевищує весь кодовий базис повного інтерпретатора RISC-V. Додавання нових попередньо скомпільованих функцій вимагає суперечливого управління через хард-форки, що суттєво обмежує інновації у протоколі, коли додатки потребують нових криптографічних примітивів. Поверхня безпеки стрімко зростає, а складність протоколу постійно зростає. Як підсумував Бутерін: «Ми повинні припинити додавати нові попередньо скомпільовані контракти з сьогоднішнього дня.»

Рішення RISC-V: чому відкритий стандарт перевищує користувацьку архітектуру

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

Мінімалізм архітектури

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

Використання екосистеми через LLVM

Застосовуючи RISC-V, Ethereum отримує доступ до десятиліть розвитку інфраструктури компіляторів через LLVM (Low-Level Virtual Machine). Це одне рішення забезпечує нативну підтримку Rust, Go, C++, Python та десятків інших мов. Розробники по всьому світу вже мають навички роботи з цими інструментами. Замість створення нової програмної екосистеми з нуля, Ethereum може успадкувати зрілу, перевірену інфраструктуру, яка вже підтримує мільйони розробників.

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

Ринок zkVM вже визначився

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

Формальна верифікація через специфікацію SAIL

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

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

Трифазна міграція: еволюція, а не революція

Розуміючи ризики архітектурних змін, керівництво Ethereum запропонувало обережний, багатоступінчастий підхід, що зберігає зворотну сумісність і стабільність роботи.

Фаза перша: обмежене впровадження zkVM

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

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

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

Фаза третя: EVM як формальна специфікація

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

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

Перехід архітектури кардинально змінить економіку Layer 2 і стимулюватиме розробників у всій екосистемі Ethereum.

Оптимістичні Rollups стикаються з екзистенційними викликами

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

Стратегічна перевага для ZK Rollups

Зворотне стосується ZK Rollups. Більшість проектів вже стандартизували RISC-V внутрішньо. Коли L1 «говорить тією ж мовою», інтеграція стає набагато ефективнішою. Візія Джастіна Дрейка «рідних Rollups» описує L2 як спеціалізовані інстанси середовища виконання L1—досягаючи безшовного розрахунку без перекладацьких шарів.

Практичні переваги:

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

Трансформація досвіду розробників і користувачів

Для розробників цей перехід означає звільнення від обмежень EVM без необхідності відмовлятися від екосистеми. Основні мови програмування раптом стають життєздатними інструментами для розробки на блокчейні. Розробники зможуть писати контракти на Rust, зберігаючи знайомство з стандартними фреймворками. Як запропонував Бутерін, «Solidity і Vyper залишаться популярними ще довго через їх елегантний дизайн для логіки смарт-контрактів», але вони стануть опціями реалізації, а не обов’язковими.

Це схоже на те, як Node.js дозволив розробникам писати JavaScript для клієнтського і серверного коду. Той самий розробник тепер може використовувати однакові мови для офф-чейн і он-чейн обчислень, що значно спрощує робочі процеси.

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

Succinct Labs і SP1: доказ, що перехід працює

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

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

Практичний вплив був миттєвим. Продукт OP Succinct від Succinct додав можливості доведень нуль-знань до стеків Optimistic Rollup. Результат: завершення виведення з семи днів зменшено до приблизно однієї години. Цей прорив вирішує ключові проблеми в екосистемі Optimistic і демонструє, як архітектура RISC-V дозволяє якісно покращити досвід користувачів.

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

Реальні ризики трансформації

Незважаючи на переваги архітектури RISC-V, перехід створює нові виклики, що потребують суворих заходів.

Складність метрики газу

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

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

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

Фрагментація екосистеми

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

Пом’якшення ризиків через шари: формальна верифікація, інтенсивне тестування і стандартизація

Для зменшення цих ризиків потрібні багаторівневі стратегії захисту.

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

Valentine з Diligence Security показав, що навіть провідні zkVM містять критичні вразливості, які можна виявити лише за допомогою ретельного fuzz-тестування. Комплексна стратегія безпеки поєднує формальну верифікацію (теоретичну основу) з інтенсивним тестуванням (практичну перевірку).

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

Формується верифіковане майбутнє

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

Шлях вперед вимагає балансування між високою продуктивністю архітектури на основі доведень нуль-знань і збереження зворотної сумісності; між безпекою через спрощення протоколу і мережею, що вже побудована навколо EVM; та можливостями універсальної обчислювальної екосистеми і ризиками від складних сторонніх інструментів.

Загалом, ця еволюція архітектури втілює прихильність Ethereum до «Легкого Виконання» і ширшої концепції «Lean Ethereum». Замість залишатися платформою для смарт-контрактів, Ethereum стане ефективним, безпечним рівнем розрахунків і доступу до даних, створеним для підтримки величезної всесвіту верифікованих обчислень.

Endgame Віталіка Бутеріна—«забезпечити ZK-snarks для всього»—наближається до реалізації, оскільки проекти, такі як Succinct Labs, демонструють, що RISC-V — це не спекулятивна архітектура, а практичний інженерний підхід у короткостроковій перспективі. Прийнявши RISC-V, Ethereum позиціонує себе як базовий рівень довіри для наступної генерації інтернет-інфраструктури—керованої криптографічними доведеннями, а не довіреними посередниками.

Ера довіреного програмного забезпечення вже настала.