Оригінальний автор: jaehaerys.eth, крипто дослідник
Оригінальний переклад: Shenchao TechFlow
Резюме
Ефір готується до найважливішої архітектурної трансформації з моменту свого народження: заміна EVM на RISC-V.
Причина дуже проста — в майбутньому, де основою є нульове знання (ZK), EVM вже став вузьким місцем продуктивності:
· Поточний zkEVM залежить від інтерпретатора, що призводить до зниження продуктивності на 50–800 разів;
· Попередньо скомпільовані модулі ускладнюють протокол і підвищують ризики;
· Дизайн стеку на 256 біт має дуже низьку ефективність при генерації доказів.
Рішення RISC-V:
· Мінімалістичний дизайн (близько 47 основних команд) + зріла екосистема LLVM (підтримує мови Rust, C++, Go тощо);
· Став фактично стандартом zkVM (90% проектів використовують);
· Має офіційні специфікації SAIL (на відміну від нечіткої жовтої книги) → забезпечує сувору перевірку;
· Шлях апаратного підтвердження (ASIC/FPGAs) вже тестується (SP1, Nervos, Cartesi тощо).
Процес міграції поділяється на три етапи:
· Замінити RISC-V на попередньо скомпільований модуль (тестування з низьким ризиком);
· Епоха двох віртуальних машин: EVM та RISC-V існують разом і повністю взаємодіють;
· Перевпровадження EVM в RISC-V (стратегія Rosetta).
Вплив екосистеми:
· Оптимістичний Rollup (такий як Arbitrum і Optimism) потребує відновлення механізму підтвердження шахрайства;
· Нульові знання Rollup (такі як Polygon, zkSync, Scroll) отримають величезну перевагу → дешевше, швидше, простіше;
· Розробники можуть безпосередньо використовувати бібліотеки мов, таких як Rust, Go та Python на рівні L1;
· Користувачі отримають приблизно в 100 разів нижчі витрати на підтвердження → шлях до Gigagas L1 (приблизно 10 000 TPS).
В кінцевому підсумку, Ethereum еволюціонує з «віртуальної машини смарт-контрактів» в надзвичайно простий, перевіряємий рівень довіри в Інтернеті, його кінцева мета — «зробити так, щоб усе було ZK-Snark-ом».
Перехрестя Ethereum
Віталік Бутерін колись сказав: «Фінальна мета включає в себе…… зробити все ZK-Snark».
Кінець нульових доказів (ZK) вже неминучий, а їхня основна аргументація дуже проста: Ethereum починає з нуля і на основі нульових доказів перетворює себе. Це знаменує технічний кінець протоколу — шляхом реконструкції L1 досягти його остаточної форми, підтримуваної високопродуктивним zkVM, що розробляється основною командою розробників (такою як Succinct).
З цією метою, Ethereum перебуває на найважливішому етапі архітектурної трансформації з моменту свого створення. Це обговорення вже не стосується поступового оновлення, а є повним перепроектуванням його обчислювального ядра — заміною Ethereum Virtual Machine (EVM). Ця ініціатива є основою більш широкої концепції «Скорочений Ethereum» (Lean Ethereum).
Візія Lean Ethereum має на меті систематично спростити весь протокол, розділивши його на три основні модулі: Lean Consensus, Lean Data та Lean Execution. А в центральному питанні спрощеного виконання найважливішим є те, чи став EVM, як двигун революції смарт-контрактів, основним гальмом у майбутньому розвитку Ethereum?
Як сказав Джастін Дрейк з Фонду Ethereum, довгостроковою метою Ethereum завжди було «перетворити все на Snark» (Snarkify everything), що є потужним інструментом для покращення різних рівнів протоколу. Однак протягом тривалого часу ця мета більше нагадувала «недосяжний план», оскільки її реалізація вимагала концепції миттєвого доказування (real-time proving). А тепер, коли миттєве доказування поступово стає реальністю, теоретична неефективність EVM перетворилася на актуальну проблему, яку потрібно вирішити.
Ця стаття детально проаналізує технічні та стратегічні аргументи щодо переходу Ethereum L1 на архітектуру інструкцій RISC-V. Цей крок не лише обіцяє звільнити небачену раніше масштабованість, але й спростити структуру протоколу та привести Ethereum у відповідність з майбутнім перевірюваних обчислень.
Що насправді змінилося?
Перш ніж обговорювати «чому», спочатку потрібно чітко визначити, «що» відбувається.
EVM (Ethereum Virtual Machine) є середовищем виконання смарт-контрактів Ethereum, відомим як «світовий комп'ютер», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн вважається революційним, закладаючи основу для виникнення децентралізованих фінансів (DeFi) та екосистеми NFT. Однак ця спеціалізована архітектура, створена майже десять років тому, зараз накопичила значну технічну заборгованість.
На відміну від цього, RISC-V не є продуктом, а відкритим стандартом — безкоштовним, універсальним алфавітом проектування процесорів. Як підкреслив Джеремі Бруестл на конференції Ethproofs, його ключові принципи роблять його відмінним вибором для цієї ролі:
· Мінімалізм: базовий набір інструкцій RISC-V надзвичайно простий, містить лише близько 40-47 інструкцій. Як сказав Джеремі, це робить його «майже ідеальним для випадків використання нашої надзвичайно спрощеної універсальної машини».
· Модульний дизайн: більш складні функції додаються за допомогою необов'язкових розширень. Ця особливість є життєво важливою, оскільки вона дозволяє зберегти простоту ядра, одночасно розширюючи функціональність відповідно до потреб, не нав'язуючи непотрібну складність базовому протоколу.
· Відкрита екосистема: RISC-V має величезну та зрілу підтримку інструментальних наборів, включаючи компілятор LLVM, що дозволяє розробникам використовувати популярні мови програмування, такі як Rust, C++ та Go. Як зазначив Джастін Дрейк: «Інструменти навколо компілятора дуже різноманітні, а побудова компілятора є надзвичайно складною… тому наявність цих інструментальних наборів компіляторів має величезну цінність.» RISC-V дозволяє Ethereum безкоштовно успадковувати ці готові інструменти.
Проблема витрат на інтерпретатор
Причини заміни EVM не є наслідком одного єдиного дефекту, а є наслідком поєднання кількох основних обмежень, які в контексті майбутнього, зосередженого на нульових знаннях, вже не можна ігнорувати. Ці обмеження включають в себе вузькі місця продуктивності в системах нульових знань, а також ризики, пов'язані зі зростаючою складністю, що накопичується в межах протоколу.
Найбільш терміновим чинником цього перетворення є вроджена неефективність 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-розрядних цілих чисел, які зазвичай використовуються в смарт-контрактах. Ця неефективність є особливо дорогою в системах ZK. Як пояснив Віталік:
«Коли використовуються менші числа, кожне число фактично не економить жодних ресурсів, а складність зростає вдвічі чи вчетверо.»
Крім того, архітектура стеку EVM менш ефективна, ніж архітектура регістрів RISC-V та сучасних ЦП. Вона вимагає більше інструкцій для виконання тих же операцій, що також ускладнює оптимізацію компілятора.
Ці проблеми — включаючи продуктивність ZK-доказів, складність попередньої компіляції та застарілі вибори архітектури — разом складають переконливу та термінову причину: Ethereum повинен вийти за межі EVM, щоб зустріти більш підходящу для майбутнього технологічну архітектуру.
RISC-V план: відновлення майбутнього Ethereum на міцнішій основі
Переваги RISC-V полягають не лише в недоліках EVM, але й у внутрішній потужності його дизайнерської філософії. Його архітектура забезпечує міцну, просту та перевірену основу, що дуже підходить для таких високих ризиків, як Ethereum.
Чому відкриті стандарти переважають над індивідуальними рішеннями?
На відміну від індивідуально налаштованих архітектур команд (ISA), які потрібно створювати з нуля, RISC-V є зрілим відкритим стандартом, що має три ключові переваги:
зріла екосистема
Завдяки впровадженню RISC-V, Ethereum може скористатися десятирічними колективними досягненнями в галузі комп'ютерних наук. Як пояснив Джастін Дрейк, це надає Ethereum можливість безпосередньо використовувати світові інструменти:
«Є компонент інфраструктури під назвою LLVM, це набір інструментів компілятора, який дозволяє вам компілювати високорівневі мови програмування в один з багатьох цільових обʼєктів. Одним із підтримуваних цільових обʼєктів є RISC-V. Отже, якщо ви підтримуєте RISC-V, ви автоматично підтримуєте всі високорівневі мови, підтримувані LLVM.»
Це значно знизило поріг для розробників, що дозволило мільйонам розробників, знайомих з такими мовами, як Rust, C++ і Go, легко приступати до роботи.
Філософія дизайну в дусі мінімалізму Мінімалізм RISC-V є свідомою рисою, а не обмеженням. Його базовий набір інструкцій містить лише близько 47 інструкцій, що дозволяє зберегти ядро віртуальної машини надзвичайно простим. Ця простота має значні переваги з точки зору безпеки, оскільки менша довірена кодова база легша для аудиту та формальної верифікації.
Фактичний стандарт у сфері нульових знань. Що ще більш важливо, екосистема zkVM вже зробила свій вибір. Як зазначив Джастін Дрейк, з даних Ethproofs можна побачити чітку тенденцію:
«RISC-V є провідною архітектурою набору команд (ISA) для бекенду zkVM.»
Серед десяти zkVM, які можуть підтвердити блоки Ethereum, дев'ять обрали RISC-V як цільову архітектуру. Це ринкове зближення випускає потужний сигнал: Ethereum, приймаючи RISC-V, не займається спекулятивними спробами, а дотримується стандарту, який вже був перевірений на практиці та визнаний проектом, що будує своє нульове знання на майбутнє.
Для довіри, а не лише для виконання
Окрім широкої екосистеми, внутрішня архітектура RISC-V також особливо підходить для створення безпечних і перевіряльних систем. По-перше, RISC-V має формалізовану, комп'ютерно-зчитувану специфікацію — SAIL. Це є величезним кроком вперед в порівнянні зі специфікацією EVM (яка в основному представлена в текстовій формі в «жовтій книзі»). «Жовта книга» має певну неясність, тоді як специфікація SAIL надає «золотий стандарт», який здатен підтримувати критично важливі математичні докази коректності, які є життєво важливими для захисту цінних протоколів. Як згадував Алекс Хікс з Фонду Ефіріуму (EF) на конференції Ethproofs, це дозволяє zkVM схемам безпосередньо «перевірятися з офіційною специфікацією RISC-V». По-друге, RISC-V містить привілейовану архітектуру, що є особливістю, яка часто ігнорується, але має вирішальне значення для безпеки. Вона визначає різні рівні виконання, головним чином включаючи режим користувача (для ненадійних додатків, таких як смарт-контракти) та режим нагляду (для надійного «виконавчого ядра»). Дієго з Cartesi детально пояснив це:
«Операційна система повинна захищати себе від впливу іншого коду. Вона повинна ізолювати різні програми одна від одної, і всі ці механізми є частиною стандарту RISC-V.»
У архітектурі RISC-V смарт-контракти, що працюють в режимі користувача (User Mode), не можуть безпосередньо отримувати доступ до стану блокчейну. Натомість вони повинні надсилати запит до довіреного ядра, яке працює в режимі нагляду (Supervisor Mode), через спеціальну інструкцію ECALL (виклик середовища). Ця механіка створює безпечний кордон, який забезпечується апаратним забезпеченням, що є більш надійним і легшим для перевірки, ніж модель EVM, яка повністю покладається на програмні пісочниці.
Візія Віталіка
Ця трансформація задумана як поступовий, багатофазний процес, щоб забезпечити стабільність системи та зворотну сумісність. Як зазначив засновник Ethereum Віталік Бутерін, цей підхід має на меті досягнення «еволюційного» розвитку, а не радикальної «революційної» зміни.
Перший крок: попереднє компілювання заміни
На початковому етапі буде обрано найконсервативніший підхід, впроваджуючи обмежені функції нової віртуальної машини (VM). Як зазначив Віталік Бутерін: «Ми можемо почати з обмежених сценаріїв використання нової VM, наприклад, замінивши функції попередньої компіляції». Конкретно, це призведе до призупинення нових функцій EVM попередньої компіляції та заміни їх реалізацією необхідних функцій через програми RISC-V, затверджені за допомогою білого списку. Цей підхід дозволяє новій VM проводити польові випробування в мережі з низьким рівнем ризику, одночасно виконуючи роль посередника між двома середовищами виконання за допомогою клієнта Ethereum.
Другий крок: спільне використання двох віртуальних машин
Наступний етап полягає в тому, щоб «відкрити нову віртуальну машину (VM) безпосередньо для користувачів». Смарт-контракти можуть вказувати за допомогою мітки, чи є їх байт-код EVM, чи RISC-V. Ключовою особливістю є реалізація безшовної взаємодії: «два типи контрактів можуть викликати один одного». Ця функція буде реалізована через системні виклики (ECALL), що дозволить двом віртуальним машинам співпрацювати в одній екосистемі.
Третій крок: EVM як імітаційний контракт (стратегія «Rosetta»
Остаточною метою є реалізація максимальної спрощеності протоколу. На цьому етапі «ми розглядаємо EVM як одну з реалізацій нового VM». Нормалізований EVM стане формально верифікованим смарт-контрактом, що працює на рідному RISC-V L1. Це не тільки гарантує постійну підтримку старих додатків, але й дозволяє розробникам клієнтів підтримувати лише один спрощений виконавчий механізм, що значно знижує складність і витрати на обслуговування.
Екосистемний рифлений ефект
Перехід від EVM до RISC-V не лише є зміною основного протоколу, але й матиме глибокий вплив на всю екосистему Ethereum. Ця трансформація не лише переформатує досвід розробників, але й радикально змінить конкурентне середовище рішень Layer-2, а також відкриє нові економічні моделі верифікації.
Перенаправлення Rollup: Поєднання Optimistic та ZK
Використання шару виконання RISC-V на рівні L1 матиме кардинально різний вплив на два основні типи Rollup.
Оптимістичні Rollup (такі як Arbitrum, Optimism) стикаються з архітектурними викликами. Їхня модель безпеки залежить від повторного виконання суперечливих транзакцій через L1 EVM для вирішення доказів шахрайства. Якщо EVM L1 буде замінено, ця модель повністю зруйнується. Ці проекти зіштовхнуться з важким вибором: або провести масштабну інженерну реконструкцію, розробивши систему доказів шахрайства для нової L1 VM, або повністю відійти від моделі безпеки Ethereum.
У порівнянні, ZK Rollup отримає величезну стратегічну перевагу. Майже всі ZK Rollup вже використовують RISC-V як свою внутрішню архітектуру набору інструкцій (ISA). L1, який «говорить тією ж мовою», дозволить їй досягти більш тісної та ефективної інтеграції. Джастін Дрейк висунув бачення майбутнього «рідного Rollup»: L2 фактично стає спеціалізованим екземпляром середовища виконання L1, використовуючи вбудовану VM L1 для безшовного розрахунку. Це вирівнювання призведе до наступних змін:
· Спрощення технологічного стеку: команда L2 більше не потребуватиме будувати складні механізми мосту між внутрішнім середовищем виконання RISC-V та EVM.
· Інструменти та повторне використання коду: компілятори, налагоджувачі та інструменти формальної верифікації, розроблені для середовища L1 RISC-V, можуть бути безпосередньо використані L2, що суттєво знижує витрати на розробку.
· Економічні стимули: витрати на газ L1 точніше відображатимуть фактичні витрати на перевірку ZK на основі RISC-V, що дозволить створити більш обґрунтовану економічну модель.
Нова ера для розробників і користувачів
Для розробників Ethereum ця трансформація буде поступовою, а не руйнівною.
Для розробників вони зможуть отримати доступ до більш широкої та зрілої екосистеми розробки програмного забезпечення. Як зазначив Віталік Бутерін, розробники «зможуть писати контракти на Rust, при цьому ці варіанти можуть співіснувати». Тим часом він прогнозує, що «Solidity та Vyper все ще будуть популярні протягом тривалого часу через їх елегантний дизайн логіки смарт-контрактів». Використання основних мов програмування та їх величезних бібліотек ресурсів через інструментальний набір LLVM стане революційним. Віталік порівняв це з «досвідом на зразок NodeJS», де розробники можуть писати код на ланцюзі та поза ним тією ж мовою, реалізуючи інтеграцію розробки.
Для користувачів ця трансформація в кінцевому рахунку принесе нижчі витрати та вищу продуктивність мережевого досвіду. Очікується, що витрати на підтвердження знизяться приблизно в 100 разів, з кількох доларів за транзакцію до кількох центів або навіть менше. Це безпосередньо перетворюється на нижчі збори L1 та збори за розрахунки L2. Ця економічна доцільність відкриє можливість для реалізації візії «Gigagas L1», метою якої є досягнення продуктивності приблизно 10 000 TPS, прокладаючи шлях для більш складних і цінних застосувань на ланцюгу в майбутньому.
Succinct Labs та SP1: Будуючи доказ майбутнього сьогодні
Ethereum готовий до зростання. "Розширення L1, розширення блоків" є стратегічно терміновим завданням у рамках протоколу EF. Очікується, що протягом наступних 6-12 місяців будуть досягнуті значні покращення продуктивності.
Команди, такі як Succinct Labs, вже на практиці продемонстрували теоретичні переваги RISC-V, їхня робота стала вагомим прикладом для підтвердження цієї пропозиції.
SP1, розроблений Succinct Labs, є високопродуктивною, відкритою zkVM на базі RISC-V, яка підтверджує життєздатність нового архітектурного підходу. SP1 використовує філософію «централізованого попереднього компілювання» (precompile-centric), яка ідеально вирішує криптографічні проблеми EVM. На відміну від традиційних методів, які покладаються на повільні, жорстко закодовані попередні компіляції, SP1 вивантажує такі інтенсивні операції, як хешування Keccak, в спеціально спроектовані, ручне оптимізовані ZK-кола, і викликає їх за допомогою стандартних інструкцій ECALL. Цей підхід поєднує в собі продуктивність спеціалізованого апаратного забезпечення та гнучкість програмного забезпечення, забезпечуючи розробникам більш ефективні та масштабовані рішення.
Фактичний вплив Succinct Labs вже проявився. Їхній продукт OP Succinct використовує SP1 для надання оптимістичним роллапам можливості нульового знання (ZK-ify). Як пояснила співзасновниця Succinct Ума Рой:
«Використовуючи Rollup на базі OP Stack, більше не потрібно чекати сім днів для завершення остаточного підтвердження та виведення коштів... тепер підтвердження займає всього одну годину. Це дуже круте підвищення швидкості.»
Цей прорив вирішує ключові проблеми всього екосистеми 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, вона також приносить нові складні виклики.
Проблема вимірювання газу
Створення детермінованої та справедливої моделі Gas для загальної архітектури команд (ISA) є невирішеним завданням. Прості методи підрахунку команд легко піддаються загрозі атак відмови в обслуговуванні. Наприклад, зловмисник може розробити програму, яка постійно викликає промахи в кеші, тим самим завдаючи великі витрати ресурсів за дуже низьку плату за Gas. Ця проблема ставить серйозні виклики для стабільності мережі та економічної моделі.
Безпека інструментального забезпечення та проблема «відтворювального складання»
Це найбільш важливий і часто недооцінений ризик у процесі трансформації. Модель безпеки переходить від залежності від віртуальних машин до залежності від компіляторів (таких як LLVM), при цьому ці компілятори мають високу складність і відомі вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на вигляд безневинний вихідний код на шкідливий байт-код. Крім того, забезпечити повну відповідність між скомпільованими двійковими файлами в ланцюгу та публічно доступним вихідним кодом, тобто проблему "відтворювального складання", також вкрай важко. Невеликі відмінності в середовищі складання можуть призвести до створення різних двійкових файлів, що вплине на прозорість та довіру. Ці проблеми ставлять серйозні виклики безпеці розробників та користувачів.
стратегії пом'якшення
Шлях до прогресу потребує багаторівневої стратегії захисту.
поетапне впровадження
Застосування поетапного, багатоступінчатого плану переходу є основною стратегією для управління ризиками. Спочатку впроваджуючи RISC-V як попередньо скомпільоване альтернативне рішення, а потім запускаючи його в середовищі з двома віртуальними машинами, спільнота може накопичити операційний досвід і встановити впевненість у безризиковому середовищі, уникаючи будь-яких незворотних змін. Цей прогресивний підхід забезпечує стабільну основу для технологічної трансформації.
Повний аудит: нечітке тестування та формальна верифікація
Хоча формальна верифікація є кінцевою метою, її необхідно поєднувати з безперервним, інтенсивним тестуванням. Як показав Валентин з Diligence Security на телефонній конференції Ethproofs, їхній інструмент для фузз-тестування Argus виявив 11 ключових вразливостей у надійності та цілісності провідного zkVM. Це свідчить про те, що навіть у найкраще спроектованих системах можуть існувати вразливості, які можна виявити лише за допомогою строгого контрольно-супротивного тестування. Поєднання фузз-тестування та формальної верифікації забезпечує більшу безпеку системи.
стандартизація
Щоб уникнути фрагментації екосистеми, спільнота повинна об'єднатися навколо єдиної, стандартної конфігурації RISC-V. Це може бути комбінація RV64GC з сумісним з Linux ABI, оскільки ця комбінація має найширшу підтримку в основних мовах програмування та інструментах, що дозволяє максимізувати переваги нової екосистеми. Стандартизація не тільки підвищить ефективність розробників, але й закладе міцний фундамент для довгострокового розвитку екосистеми.
Перевірене майбутнє Ethereum
Пропозиція замінити віртуальну машину Ethereum (EVM) на RISC-V є не просто поступовим оновленням, а радикальною реконструкцією виконавчого рівня Ethereum. Це амбіційне бачення має на меті вирішити глибокі вузькі місця в масштабуванні, спростити складність протоколу та узгодити платформу з більш широкою екосистемою загальних обчислень. Незважаючи на те, що ця трансформація стикається з величезними технічними та соціальними викликами, її довгострокові стратегічні вигоди є достатніми, щоб обґрунтувати цю сміливу ініціативу.
Ця трансформація зосереджена на ряді ключових компромісів:
· Баланс між величезним підвищенням продуктивності, яке забезпечує рідна архітектура ZK, та терміновою необхідністю зворотної сумісності;
· Торгівля між перевагами безпеки, які надає спрощений протокол, та інерцією величезного мережевого ефекту EVM;
· Вибір між потужними можливостями універсальної екосистеми та ризиками, пов'язаними з залежністю від складних сторонніх інструментів.
В кінцевому підсумку, ця трансформація архітектури стане ключовою для реалізації зобов'язання «Скорочене виконання» (Lean Execution) і важливою складовою візії «Скороченого Ethereum» (Lean Ethereum). Вона перетворить L1 Ethereum з простого платформи для смарт-контрактів на ефективний і безпечний шар для розрахунків та доступності даних, розроблений спеціально для підтримки широкого всесвіту верифікованих обчислень.
Як сказав Віталік Бутерін, «мета полягає в тому, щоб забезпечити ZK-snark для всього.»
Проекти, такі як Ethproofs, надають об'єктивні дані та платформу для співпраці для цього перетворення, а команда Succinct Labs через практичне застосування свого SP1 zkVM пропонує дієвий план для цього майбутнього. Прийнявши RISC-V, Ефіріум не лише вирішив власні проблеми з масштабованістю, а й позиціонував себе як основний шар довіри наступного покоління Інтернету — підживлений третьою великою криптографічною примітивою SNARK, що стоїть за хешами та підписами.
Доказ програмного забезпечення світу, відкриваючи нову еру криптографії.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Ethereum або може отримати найбільше оновлення в історії: EVM виводиться з експлуатації, RISC-V бере на себе
Оригінальна назва: Прощавай EVM, привіт RISC-V
Оригінальний автор: jaehaerys.eth, крипто дослідник
Оригінальний переклад: Shenchao TechFlow
Резюме
Ефір готується до найважливішої архітектурної трансформації з моменту свого народження: заміна EVM на RISC-V.
Причина дуже проста — в майбутньому, де основою є нульове знання (ZK), EVM вже став вузьким місцем продуктивності:
· Поточний zkEVM залежить від інтерпретатора, що призводить до зниження продуктивності на 50–800 разів;
· Попередньо скомпільовані модулі ускладнюють протокол і підвищують ризики;
· Дизайн стеку на 256 біт має дуже низьку ефективність при генерації доказів.
Рішення RISC-V:
· Мінімалістичний дизайн (близько 47 основних команд) + зріла екосистема LLVM (підтримує мови Rust, C++, Go тощо);
· Став фактично стандартом zkVM (90% проектів використовують);
· Має офіційні специфікації SAIL (на відміну від нечіткої жовтої книги) → забезпечує сувору перевірку;
· Шлях апаратного підтвердження (ASIC/FPGAs) вже тестується (SP1, Nervos, Cartesi тощо).
Процес міграції поділяється на три етапи:
· Замінити RISC-V на попередньо скомпільований модуль (тестування з низьким ризиком);
· Епоха двох віртуальних машин: EVM та RISC-V існують разом і повністю взаємодіють;
· Перевпровадження EVM в RISC-V (стратегія Rosetta).
Вплив екосистеми:
· Оптимістичний Rollup (такий як Arbitrum і Optimism) потребує відновлення механізму підтвердження шахрайства;
· Нульові знання Rollup (такі як Polygon, zkSync, Scroll) отримають величезну перевагу → дешевше, швидше, простіше;
· Розробники можуть безпосередньо використовувати бібліотеки мов, таких як Rust, Go та Python на рівні L1;
· Користувачі отримають приблизно в 100 разів нижчі витрати на підтвердження → шлях до Gigagas L1 (приблизно 10 000 TPS).
В кінцевому підсумку, Ethereum еволюціонує з «віртуальної машини смарт-контрактів» в надзвичайно простий, перевіряємий рівень довіри в Інтернеті, його кінцева мета — «зробити так, щоб усе було ZK-Snark-ом».
Перехрестя Ethereum
Віталік Бутерін колись сказав: «Фінальна мета включає в себе…… зробити все ZK-Snark».
Кінець нульових доказів (ZK) вже неминучий, а їхня основна аргументація дуже проста: Ethereum починає з нуля і на основі нульових доказів перетворює себе. Це знаменує технічний кінець протоколу — шляхом реконструкції L1 досягти його остаточної форми, підтримуваної високопродуктивним zkVM, що розробляється основною командою розробників (такою як Succinct).
З цією метою, Ethereum перебуває на найважливішому етапі архітектурної трансформації з моменту свого створення. Це обговорення вже не стосується поступового оновлення, а є повним перепроектуванням його обчислювального ядра — заміною Ethereum Virtual Machine (EVM). Ця ініціатива є основою більш широкої концепції «Скорочений Ethereum» (Lean Ethereum).
Візія Lean Ethereum має на меті систематично спростити весь протокол, розділивши його на три основні модулі: Lean Consensus, Lean Data та Lean Execution. А в центральному питанні спрощеного виконання найважливішим є те, чи став EVM, як двигун революції смарт-контрактів, основним гальмом у майбутньому розвитку Ethereum?
Як сказав Джастін Дрейк з Фонду Ethereum, довгостроковою метою Ethereum завжди було «перетворити все на Snark» (Snarkify everything), що є потужним інструментом для покращення різних рівнів протоколу. Однак протягом тривалого часу ця мета більше нагадувала «недосяжний план», оскільки її реалізація вимагала концепції миттєвого доказування (real-time proving). А тепер, коли миттєве доказування поступово стає реальністю, теоретична неефективність EVM перетворилася на актуальну проблему, яку потрібно вирішити.
Ця стаття детально проаналізує технічні та стратегічні аргументи щодо переходу Ethereum L1 на архітектуру інструкцій RISC-V. Цей крок не лише обіцяє звільнити небачену раніше масштабованість, але й спростити структуру протоколу та привести Ethereum у відповідність з майбутнім перевірюваних обчислень.
Що насправді змінилося?
Перш ніж обговорювати «чому», спочатку потрібно чітко визначити, «що» відбувається.
EVM (Ethereum Virtual Machine) є середовищем виконання смарт-контрактів Ethereum, відомим як «світовий комп'ютер», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн вважається революційним, закладаючи основу для виникнення децентралізованих фінансів (DeFi) та екосистеми NFT. Однак ця спеціалізована архітектура, створена майже десять років тому, зараз накопичила значну технічну заборгованість.
На відміну від цього, RISC-V не є продуктом, а відкритим стандартом — безкоштовним, універсальним алфавітом проектування процесорів. Як підкреслив Джеремі Бруестл на конференції Ethproofs, його ключові принципи роблять його відмінним вибором для цієї ролі:
· Мінімалізм: базовий набір інструкцій RISC-V надзвичайно простий, містить лише близько 40-47 інструкцій. Як сказав Джеремі, це робить його «майже ідеальним для випадків використання нашої надзвичайно спрощеної універсальної машини».
· Модульний дизайн: більш складні функції додаються за допомогою необов'язкових розширень. Ця особливість є життєво важливою, оскільки вона дозволяє зберегти простоту ядра, одночасно розширюючи функціональність відповідно до потреб, не нав'язуючи непотрібну складність базовому протоколу.
· Відкрита екосистема: RISC-V має величезну та зрілу підтримку інструментальних наборів, включаючи компілятор LLVM, що дозволяє розробникам використовувати популярні мови програмування, такі як Rust, C++ та Go. Як зазначив Джастін Дрейк: «Інструменти навколо компілятора дуже різноманітні, а побудова компілятора є надзвичайно складною… тому наявність цих інструментальних наборів компіляторів має величезну цінність.» RISC-V дозволяє Ethereum безкоштовно успадковувати ці готові інструменти.
Проблема витрат на інтерпретатор
Причини заміни EVM не є наслідком одного єдиного дефекту, а є наслідком поєднання кількох основних обмежень, які в контексті майбутнього, зосередженого на нульових знаннях, вже не можна ігнорувати. Ці обмеження включають в себе вузькі місця продуктивності в системах нульових знань, а також ризики, пов'язані зі зростаючою складністю, що накопичується в межах протоколу.
Найбільш терміновим чинником цього перетворення є вроджена неефективність 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-розрядних цілих чисел, які зазвичай використовуються в смарт-контрактах. Ця неефективність є особливо дорогою в системах ZK. Як пояснив Віталік:
«Коли використовуються менші числа, кожне число фактично не економить жодних ресурсів, а складність зростає вдвічі чи вчетверо.»
Крім того, архітектура стеку EVM менш ефективна, ніж архітектура регістрів RISC-V та сучасних ЦП. Вона вимагає більше інструкцій для виконання тих же операцій, що також ускладнює оптимізацію компілятора.
Ці проблеми — включаючи продуктивність ZK-доказів, складність попередньої компіляції та застарілі вибори архітектури — разом складають переконливу та термінову причину: Ethereum повинен вийти за межі EVM, щоб зустріти більш підходящу для майбутнього технологічну архітектуру.
RISC-V план: відновлення майбутнього Ethereum на міцнішій основі
Переваги RISC-V полягають не лише в недоліках EVM, але й у внутрішній потужності його дизайнерської філософії. Його архітектура забезпечує міцну, просту та перевірену основу, що дуже підходить для таких високих ризиків, як Ethereum.
Чому відкриті стандарти переважають над індивідуальними рішеннями?
На відміну від індивідуально налаштованих архітектур команд (ISA), які потрібно створювати з нуля, RISC-V є зрілим відкритим стандартом, що має три ключові переваги:
зріла екосистема
Завдяки впровадженню RISC-V, Ethereum може скористатися десятирічними колективними досягненнями в галузі комп'ютерних наук. Як пояснив Джастін Дрейк, це надає Ethereum можливість безпосередньо використовувати світові інструменти:
«Є компонент інфраструктури під назвою LLVM, це набір інструментів компілятора, який дозволяє вам компілювати високорівневі мови програмування в один з багатьох цільових обʼєктів. Одним із підтримуваних цільових обʼєктів є RISC-V. Отже, якщо ви підтримуєте RISC-V, ви автоматично підтримуєте всі високорівневі мови, підтримувані LLVM.»
Це значно знизило поріг для розробників, що дозволило мільйонам розробників, знайомих з такими мовами, як Rust, C++ і Go, легко приступати до роботи.
Філософія дизайну в дусі мінімалізму Мінімалізм RISC-V є свідомою рисою, а не обмеженням. Його базовий набір інструкцій містить лише близько 47 інструкцій, що дозволяє зберегти ядро віртуальної машини надзвичайно простим. Ця простота має значні переваги з точки зору безпеки, оскільки менша довірена кодова база легша для аудиту та формальної верифікації.
Фактичний стандарт у сфері нульових знань. Що ще більш важливо, екосистема zkVM вже зробила свій вибір. Як зазначив Джастін Дрейк, з даних Ethproofs можна побачити чітку тенденцію:
«RISC-V є провідною архітектурою набору команд (ISA) для бекенду zkVM.»
Серед десяти zkVM, які можуть підтвердити блоки Ethereum, дев'ять обрали RISC-V як цільову архітектуру. Це ринкове зближення випускає потужний сигнал: Ethereum, приймаючи RISC-V, не займається спекулятивними спробами, а дотримується стандарту, який вже був перевірений на практиці та визнаний проектом, що будує своє нульове знання на майбутнє.
Для довіри, а не лише для виконання
Окрім широкої екосистеми, внутрішня архітектура RISC-V також особливо підходить для створення безпечних і перевіряльних систем. По-перше, RISC-V має формалізовану, комп'ютерно-зчитувану специфікацію — SAIL. Це є величезним кроком вперед в порівнянні зі специфікацією EVM (яка в основному представлена в текстовій формі в «жовтій книзі»). «Жовта книга» має певну неясність, тоді як специфікація SAIL надає «золотий стандарт», який здатен підтримувати критично важливі математичні докази коректності, які є життєво важливими для захисту цінних протоколів. Як згадував Алекс Хікс з Фонду Ефіріуму (EF) на конференції Ethproofs, це дозволяє zkVM схемам безпосередньо «перевірятися з офіційною специфікацією RISC-V». По-друге, RISC-V містить привілейовану архітектуру, що є особливістю, яка часто ігнорується, але має вирішальне значення для безпеки. Вона визначає різні рівні виконання, головним чином включаючи режим користувача (для ненадійних додатків, таких як смарт-контракти) та режим нагляду (для надійного «виконавчого ядра»). Дієго з Cartesi детально пояснив це:
«Операційна система повинна захищати себе від впливу іншого коду. Вона повинна ізолювати різні програми одна від одної, і всі ці механізми є частиною стандарту RISC-V.»
У архітектурі RISC-V смарт-контракти, що працюють в режимі користувача (User Mode), не можуть безпосередньо отримувати доступ до стану блокчейну. Натомість вони повинні надсилати запит до довіреного ядра, яке працює в режимі нагляду (Supervisor Mode), через спеціальну інструкцію ECALL (виклик середовища). Ця механіка створює безпечний кордон, який забезпечується апаратним забезпеченням, що є більш надійним і легшим для перевірки, ніж модель EVM, яка повністю покладається на програмні пісочниці.
Візія Віталіка
Ця трансформація задумана як поступовий, багатофазний процес, щоб забезпечити стабільність системи та зворотну сумісність. Як зазначив засновник Ethereum Віталік Бутерін, цей підхід має на меті досягнення «еволюційного» розвитку, а не радикальної «революційної» зміни.
Перший крок: попереднє компілювання заміни
На початковому етапі буде обрано найконсервативніший підхід, впроваджуючи обмежені функції нової віртуальної машини (VM). Як зазначив Віталік Бутерін: «Ми можемо почати з обмежених сценаріїв використання нової VM, наприклад, замінивши функції попередньої компіляції». Конкретно, це призведе до призупинення нових функцій EVM попередньої компіляції та заміни їх реалізацією необхідних функцій через програми RISC-V, затверджені за допомогою білого списку. Цей підхід дозволяє новій VM проводити польові випробування в мережі з низьким рівнем ризику, одночасно виконуючи роль посередника між двома середовищами виконання за допомогою клієнта Ethereum.
Другий крок: спільне використання двох віртуальних машин
Наступний етап полягає в тому, щоб «відкрити нову віртуальну машину (VM) безпосередньо для користувачів». Смарт-контракти можуть вказувати за допомогою мітки, чи є їх байт-код EVM, чи RISC-V. Ключовою особливістю є реалізація безшовної взаємодії: «два типи контрактів можуть викликати один одного». Ця функція буде реалізована через системні виклики (ECALL), що дозволить двом віртуальним машинам співпрацювати в одній екосистемі.
Третій крок: EVM як імітаційний контракт (стратегія «Rosetta»
Остаточною метою є реалізація максимальної спрощеності протоколу. На цьому етапі «ми розглядаємо EVM як одну з реалізацій нового VM». Нормалізований EVM стане формально верифікованим смарт-контрактом, що працює на рідному RISC-V L1. Це не тільки гарантує постійну підтримку старих додатків, але й дозволяє розробникам клієнтів підтримувати лише один спрощений виконавчий механізм, що значно знижує складність і витрати на обслуговування.
Екосистемний рифлений ефект
Перехід від EVM до RISC-V не лише є зміною основного протоколу, але й матиме глибокий вплив на всю екосистему Ethereum. Ця трансформація не лише переформатує досвід розробників, але й радикально змінить конкурентне середовище рішень Layer-2, а також відкриє нові економічні моделі верифікації.
Перенаправлення Rollup: Поєднання Optimistic та ZK
Використання шару виконання RISC-V на рівні L1 матиме кардинально різний вплив на два основні типи Rollup.
Оптимістичні Rollup (такі як Arbitrum, Optimism) стикаються з архітектурними викликами. Їхня модель безпеки залежить від повторного виконання суперечливих транзакцій через L1 EVM для вирішення доказів шахрайства. Якщо EVM L1 буде замінено, ця модель повністю зруйнується. Ці проекти зіштовхнуться з важким вибором: або провести масштабну інженерну реконструкцію, розробивши систему доказів шахрайства для нової L1 VM, або повністю відійти від моделі безпеки Ethereum.
У порівнянні, ZK Rollup отримає величезну стратегічну перевагу. Майже всі ZK Rollup вже використовують RISC-V як свою внутрішню архітектуру набору інструкцій (ISA). L1, який «говорить тією ж мовою», дозволить їй досягти більш тісної та ефективної інтеграції. Джастін Дрейк висунув бачення майбутнього «рідного Rollup»: L2 фактично стає спеціалізованим екземпляром середовища виконання L1, використовуючи вбудовану VM L1 для безшовного розрахунку. Це вирівнювання призведе до наступних змін:
· Спрощення технологічного стеку: команда L2 більше не потребуватиме будувати складні механізми мосту між внутрішнім середовищем виконання RISC-V та EVM.
· Інструменти та повторне використання коду: компілятори, налагоджувачі та інструменти формальної верифікації, розроблені для середовища L1 RISC-V, можуть бути безпосередньо використані L2, що суттєво знижує витрати на розробку.
· Економічні стимули: витрати на газ L1 точніше відображатимуть фактичні витрати на перевірку ZK на основі RISC-V, що дозволить створити більш обґрунтовану економічну модель.
Нова ера для розробників і користувачів
Для розробників Ethereum ця трансформація буде поступовою, а не руйнівною.
Для розробників вони зможуть отримати доступ до більш широкої та зрілої екосистеми розробки програмного забезпечення. Як зазначив Віталік Бутерін, розробники «зможуть писати контракти на Rust, при цьому ці варіанти можуть співіснувати». Тим часом він прогнозує, що «Solidity та Vyper все ще будуть популярні протягом тривалого часу через їх елегантний дизайн логіки смарт-контрактів». Використання основних мов програмування та їх величезних бібліотек ресурсів через інструментальний набір LLVM стане революційним. Віталік порівняв це з «досвідом на зразок NodeJS», де розробники можуть писати код на ланцюзі та поза ним тією ж мовою, реалізуючи інтеграцію розробки.
Для користувачів ця трансформація в кінцевому рахунку принесе нижчі витрати та вищу продуктивність мережевого досвіду. Очікується, що витрати на підтвердження знизяться приблизно в 100 разів, з кількох доларів за транзакцію до кількох центів або навіть менше. Це безпосередньо перетворюється на нижчі збори L1 та збори за розрахунки L2. Ця економічна доцільність відкриє можливість для реалізації візії «Gigagas L1», метою якої є досягнення продуктивності приблизно 10 000 TPS, прокладаючи шлях для більш складних і цінних застосувань на ланцюгу в майбутньому.
Succinct Labs та SP1: Будуючи доказ майбутнього сьогодні
Ethereum готовий до зростання. "Розширення L1, розширення блоків" є стратегічно терміновим завданням у рамках протоколу EF. Очікується, що протягом наступних 6-12 місяців будуть досягнуті значні покращення продуктивності.
Команди, такі як Succinct Labs, вже на практиці продемонстрували теоретичні переваги RISC-V, їхня робота стала вагомим прикладом для підтвердження цієї пропозиції.
SP1, розроблений Succinct Labs, є високопродуктивною, відкритою zkVM на базі RISC-V, яка підтверджує життєздатність нового архітектурного підходу. SP1 використовує філософію «централізованого попереднього компілювання» (precompile-centric), яка ідеально вирішує криптографічні проблеми EVM. На відміну від традиційних методів, які покладаються на повільні, жорстко закодовані попередні компіляції, SP1 вивантажує такі інтенсивні операції, як хешування Keccak, в спеціально спроектовані, ручне оптимізовані ZK-кола, і викликає їх за допомогою стандартних інструкцій ECALL. Цей підхід поєднує в собі продуктивність спеціалізованого апаратного забезпечення та гнучкість програмного забезпечення, забезпечуючи розробникам більш ефективні та масштабовані рішення.
Фактичний вплив Succinct Labs вже проявився. Їхній продукт OP Succinct використовує SP1 для надання оптимістичним роллапам можливості нульового знання (ZK-ify). Як пояснила співзасновниця Succinct Ума Рой:
«Використовуючи Rollup на базі OP Stack, більше не потрібно чекати сім днів для завершення остаточного підтвердження та виведення коштів... тепер підтвердження займає всього одну годину. Це дуже круте підвищення швидкості.»
Цей прорив вирішує ключові проблеми всього екосистеми 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, вона також приносить нові складні виклики.
Проблема вимірювання газу
Створення детермінованої та справедливої моделі Gas для загальної архітектури команд (ISA) є невирішеним завданням. Прості методи підрахунку команд легко піддаються загрозі атак відмови в обслуговуванні. Наприклад, зловмисник може розробити програму, яка постійно викликає промахи в кеші, тим самим завдаючи великі витрати ресурсів за дуже низьку плату за Gas. Ця проблема ставить серйозні виклики для стабільності мережі та економічної моделі.
Безпека інструментального забезпечення та проблема «відтворювального складання»
Це найбільш важливий і часто недооцінений ризик у процесі трансформації. Модель безпеки переходить від залежності від віртуальних машин до залежності від компіляторів (таких як LLVM), при цьому ці компілятори мають високу складність і відомі вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на вигляд безневинний вихідний код на шкідливий байт-код. Крім того, забезпечити повну відповідність між скомпільованими двійковими файлами в ланцюгу та публічно доступним вихідним кодом, тобто проблему "відтворювального складання", також вкрай важко. Невеликі відмінності в середовищі складання можуть призвести до створення різних двійкових файлів, що вплине на прозорість та довіру. Ці проблеми ставлять серйозні виклики безпеці розробників та користувачів.
стратегії пом'якшення
Шлях до прогресу потребує багаторівневої стратегії захисту.
поетапне впровадження
Застосування поетапного, багатоступінчатого плану переходу є основною стратегією для управління ризиками. Спочатку впроваджуючи RISC-V як попередньо скомпільоване альтернативне рішення, а потім запускаючи його в середовищі з двома віртуальними машинами, спільнота може накопичити операційний досвід і встановити впевненість у безризиковому середовищі, уникаючи будь-яких незворотних змін. Цей прогресивний підхід забезпечує стабільну основу для технологічної трансформації.
Повний аудит: нечітке тестування та формальна верифікація
Хоча формальна верифікація є кінцевою метою, її необхідно поєднувати з безперервним, інтенсивним тестуванням. Як показав Валентин з Diligence Security на телефонній конференції Ethproofs, їхній інструмент для фузз-тестування Argus виявив 11 ключових вразливостей у надійності та цілісності провідного zkVM. Це свідчить про те, що навіть у найкраще спроектованих системах можуть існувати вразливості, які можна виявити лише за допомогою строгого контрольно-супротивного тестування. Поєднання фузз-тестування та формальної верифікації забезпечує більшу безпеку системи.
стандартизація
Щоб уникнути фрагментації екосистеми, спільнота повинна об'єднатися навколо єдиної, стандартної конфігурації RISC-V. Це може бути комбінація RV64GC з сумісним з Linux ABI, оскільки ця комбінація має найширшу підтримку в основних мовах програмування та інструментах, що дозволяє максимізувати переваги нової екосистеми. Стандартизація не тільки підвищить ефективність розробників, але й закладе міцний фундамент для довгострокового розвитку екосистеми.
Перевірене майбутнє Ethereum
Пропозиція замінити віртуальну машину Ethereum (EVM) на RISC-V є не просто поступовим оновленням, а радикальною реконструкцією виконавчого рівня Ethereum. Це амбіційне бачення має на меті вирішити глибокі вузькі місця в масштабуванні, спростити складність протоколу та узгодити платформу з більш широкою екосистемою загальних обчислень. Незважаючи на те, що ця трансформація стикається з величезними технічними та соціальними викликами, її довгострокові стратегічні вигоди є достатніми, щоб обґрунтувати цю сміливу ініціативу.
Ця трансформація зосереджена на ряді ключових компромісів:
· Баланс між величезним підвищенням продуктивності, яке забезпечує рідна архітектура ZK, та терміновою необхідністю зворотної сумісності;
· Торгівля між перевагами безпеки, які надає спрощений протокол, та інерцією величезного мережевого ефекту EVM;
· Вибір між потужними можливостями універсальної екосистеми та ризиками, пов'язаними з залежністю від складних сторонніх інструментів.
В кінцевому підсумку, ця трансформація архітектури стане ключовою для реалізації зобов'язання «Скорочене виконання» (Lean Execution) і важливою складовою візії «Скороченого Ethereum» (Lean Ethereum). Вона перетворить L1 Ethereum з простого платформи для смарт-контрактів на ефективний і безпечний шар для розрахунків та доступності даних, розроблений спеціально для підтримки широкого всесвіту верифікованих обчислень.
Як сказав Віталік Бутерін, «мета полягає в тому, щоб забезпечити ZK-snark для всього.»
Проекти, такі як Ethproofs, надають об'єктивні дані та платформу для співпраці для цього перетворення, а команда Succinct Labs через практичне застосування свого SP1 zkVM пропонує дієвий план для цього майбутнього. Прийнявши RISC-V, Ефіріум не лише вирішив власні проблеми з масштабованістю, а й позиціонував себе як основний шар довіри наступного покоління Інтернету — підживлений третьою великою криптографічною примітивою SNARK, що стоїть за хешами та підписами.
Доказ програмного забезпечення світу, відкриваючи нову еру криптографії.