Інновації виконавчого шару Ethereum: Перспективи та виклики архітектури RISC-V

Співзасновник Ethereum нещодавно висунув у спільноті перспективну пропозицію: замінити існуючу віртуальну машину виконання (EVM) на відкриту архітектуру набору інструкцій RISC-V. Ця ідея була порівняна з Beam Chain виконувального рівня, що має на меті подолати проблеми з продуктивністю та спростити логіку протоколу. Особливо в плані ефективності нульових знань (ZK Proof), очікується досягнення оптимізації до 100 разів. Ця пропозиція має на меті вирішення поточних проблем Ethereum у зв'язку з ефективністю ZK доказів, складністю побудови блоків та доступністю даних.

Поточні обмеження EVM та переваги RISC-V

Проблема EVM:

• Старі архітектури: 256-розрядна стекова структура не сумісна з сучасними ЦП, що впливає на ефективність виконання ZK-EVM.
• Бутилка ZK-доказів: приблизно половина ресурсів ZK-EVM використовується для виконання самого EVM, що обмежує ефективність доказів.
• Погане обслуговування: накопичення функцій призводить до плутанини в специфікаціях, наприклад, SELFDESTRUCT важко скасувати.
• Обмежена розробка: нестандартний набір інструкцій обмежує підтримку між мовами, що ускладнює ефективну компіляцію основних мов.

Переваги RISC-V:

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

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

Заміна шляхів та виклики

три варіанти заміни:

1. Подвійна віртуальна машина (консервативна): EVM та RISC-V працюють паралельно, забезпечуючи сумісність у перехідний період.
2. Описувач на ланцюгу (радикальний): всі контракти EVM виконуються за допомогою контрактів RISC-V на ланцюгу.
3. Механізм плагінів інтерпретатора (компроміс): використовувати інтерпретатор як елемент протоколу, що дозволяє в майбутньому вставляти інші VM.

Технічні виклики, з якими стикається реалізація:

• Ризик зниження продуктивності виконання: RISC-V на чіпах x86 потребує симуляції виконання, початкова ефективність може бути нижчою за оптимізований EVM.
• Перебудова оцінки Gas: необхідно визначити нову модель Gas для інструкцій RISC-V.
• Дизайн безпечного пісочниці: обмеження системних викликів, запобігання самозмінам коду, забезпечення детермінованого виконання.
• Адаптація розробницьких інструментів: оновлення компілятора, налагоджувача, інструментів безпекового аудиту, підтримка байт-коду RISC-V.
• Сумісність міграції: деякі контракти залежать від функцій EVM, потрібно обережно розробити сумісний рівень або механізм відкату.

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

Вплив на існуючі шляхи розширення

RISC-V є оптимізацією інфраструктури, яка не замінить існуючі маршрути розширення:

• Layer 2: RISC-V підвищує ефективність обробки L1 та продуктивність ZK верифікації, що допомагає Rollup знижувати витрати та швидше подавати дані.
• Розбиття даних та EIP-4844: проблеми доступності даних все ще потрібно вирішувати за допомогою blob та Danksharding.
• FaaS, MEV: не залежать від архітектури віртуальної машини і не підлягають впливу RISC-V.

RISC-V є "заміною двигуна", L2/шардінг є "розширенням мережі", обидва вони мають різні виміри, але паралельні один одному.

Відгуки спільноти та відповідні спроби

Розбіжності в спільноті:

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

Схожі проекти для посилання:

• Move VM (Aptos/Sui): ресурсно-орієнтоване VM, з високою мовною безпекою, але не сумісне з EVM.
• FuelVM: спроектовано для паралельної обробки, сумісний з мовою Sway, має обмежену сумісність.
• WASM (Stylus): впровадження WASM як мови контрактів на L2, вже реалізовано на певній платформі.
• Один блокчейн проект: основна мережа використовує RISC-V як VM для контрактів, щоб надати практичну довідку для Ethereum.

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

Перспективи майбутнього впливу

Досвід розробника:

• Мови, такі як Solidity/Vyper, все ще можна використовувати, лише змінивши бекенд компілятора.
• Можливо, буде відкрито нові мови, такі як Rust/C, для написання контрактів, але мігрувати не обов'язково.

Витрати на експлуатацію та продуктивність:

• Підвищення ефективності виконання призведе до вищого ліміту Gas і нижчих витрат.
• Контракти RISC-V можуть зменшити залежність від попередньо скомпільованих контрактів, модель Gas ближча до вартості ZK-доказів.

Екологічна сумісність і розвиток:

• У періоді спільного існування двох VM існуючі контракти можуть продовжувати працювати, нові контракти поступово впроваджують RISC-V.
• Інфраструктура повинна підтримувати новий формат байт-коду, що може викликати зміни в сумісності між ланцюгами.

Безпека та стабільність:

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

Висновок

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

Як зазначив автор пропозиції: "Щоб досягти підвищення в кілька разів, ця радикальна зміна може бути єдиним можливим шляхом."

Це ставка на майбутнє, а також глибоке дослідження питання "чи варто переробляти основу".