Ефір готується до найважливішої архітектурної трансформації з моменту свого виникнення: замінити EVM на RISC-V.
Причина дуже проста — у майбутньому, де основою є нульові знання (ZK), EVM вже став вузьким місцем продуктивності:
Поточний zkEVM залежить від інтерпретатора, що призводить до сповільнення продуктивності на 50–800 разів;
Препроцесорний модуль ускладнює протокол і підвищує ризики;
Дизайн стеку з 256 бітів має дуже низьку ефективність при генерації доказів.
Рішення RISC-V:
Мінімалістичний дизайн (близько 47 базових інструкцій) + зріла екосистема LLVM (підтримує мови Rust, C++, Go тощо);
Став фактичним стандартом zkVM (90% проектів використовують);
Має офіційні специфікації SAIL (в порівнянні з розмитим жовтим папером) → реалізація сувірної верифікації;
Шлях підтвердження апаратного забезпечення (ASICs/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).
Врешті-решт, ефіріум еволюціонує з "віртуальної машини смарт-контрактів" в надпростий, перевіряємий рівень довіри Інтернету, його кінцева мета – "щоб все було ZK-Snark-ом".
Перехрестя Ethereum
Віталік Бутерін колись сказав: "Кінцева мета включає в себе... зробити все ZK-Snark."
Кінець нульових доказів (ZK) неминучий, і його основний аргумент дуже простий: Ethereum починає з нуля, відновлюючи себе на основі нульових доказів. Це знаменує технічну точку завершення протоколу — через реконструкцію L1 досягти його остаточної форми, підтримуваної високопродуктивним zkVM, наданим основною командою розробників (такою як Succinct).
!
З цією метою візії Ethereum перебуває на найважливішому етапі архітектурної трансформації з моменту свого народження. Це обговорення вже не стосується поетапного оновлення, а є повною реконструкцією його обчислювального ядра — заміною віртуальної машини Ethereum (EVM). Цей крок є основою більш широкої візії "Схудлий Ethereum".
Візія Lean Ethereum має на меті систематичне спрощення всього протоколу, розділяючи його на три основні модулі: Lean Consensus, Lean Data та Lean Execution. А в основному питанні спрощеного виконання найважливішим є: чи став EVM, як двигун революції смарт-контрактів, основним вузьким місцем у майбутньому розвитку Ethereum?
!
Як зазначив Джастін Дрейк з Фонду Ethereum, довгостроковою метою Ethereum завжди було "Snarkify everything" (перетворити все на Snark), що є потужним інструментом для підсилення різних рівнів протоколу. Проте, протягом тривалого часу ця мета більше нагадувала "недосяжний план", оскільки її реалізація потребує концепції реального часу (real-time proving). А тепер, коли реальний час стає реальністю, теоретична неефективність EVM перетворилася на нагальну проблему, яку потрібно вирішити.
Ця стаття глибоко проаналізує технічні та стратегічні аргументи перенесення Ethereum L1 на архітектуру набору команд RISC-V. Цей крок не лише обіцяє звільнити безпрецедентну масштабованість, але й спростити структуру протоколу, а також забезпечити відповідність Ethereum майбутньому перевіреної обчислювальної потужності.
Що ж насправді змінилося?
Перед обговоренням "чому" спочатку потрібно визначити, "що" змінюється.
EVM (Ефірна віртуальна машина) є середовищем виконання смарт-контрактів Ефіру, яке називають «світовим комп'ютером», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн вважається революційним, заклавши основи для виникнення децентралізованих фінансів (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), не можуть безпосередньо отримувати доступ до стану блокчейну. Натомість їм потрібно через спеціальну інструкцію ECALL (виклик середовища) надіслати запит до довіреного ядра, яке працює в режимі нагляду (Supervisor Mode). Ця механіка створює безпечну межу, яка забезпечується апаратним забезпеченням, що робить її більш надійною та перевіряємою в порівнянні з моделлю 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: Будування доказу майбутнього сьогодні
!
Ефіріум готується до ривка. "Розширення 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 схем у Lean для формальної верифікації відповідно до офіційних стандартів RISC-V". Це знаковий прогрес, що переносить довіру з помилкових людських реалізацій на перевірні математичні докази, відкриваючи нові висоти безпеки блокчейну.
Основні ризики трансформації
Хоча архітектура RISC-V має безліч переваг на рівні L1, вона також приносить нові складні виклики.
Проблема вимірювання газу
Створення детермінованої та справедливої моделі Gas для загальної архітектури команд (ISA) є нерозв’язаною проблемою. Простий метод підрахунку команд піддається загрозі атак відмови в обслуговуванні. Наприклад, зловмисник може розробити програму, яка постійно викликає повне кешування, завдаючи великого споживання ресурсів за дуже низьку вартість Gas. Ця проблема ставить серйозні виклики перед стабільністю мережі та економічною моделлю.
Безпека інструментального набору та проблема "відтворювального складання"
Це найбільш важливий, але часто недооцінюваний ризик у процесі трансформації. Модель безпеки переходить від залежності від віртуальних машин на ланцюзі до залежності від компіляторів за межами ланцюга (таких як LLVM), які мають високу складність і відомі вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на перший погляд безневинний вихідний код на шкідливий байт-код. Крім того, забезпечити, щоб бінарні файли після компіляції на ланцюзі повністю відповідали опублікованому вихідному коду, тобто проблема “відтворювального складання”, також надзвичайно важко. Невеликі відмінності в середовищі збірки можуть призвести до отримання різних бінарних файлів, що вплине на прозорість і довіру. Ці проблеми ставлять серйозні випробування для безпеки розробників і користувачів.
Стратегії полегшення
Шлях вперед вимагає багаторівневої стратегії захисту.
Поетапне просування
Прийняття поетапного, багатофазного плану переходу є основною стратегією для управління ризиками. Спочатку вводячи RISC-V як попередньо скомпільовану альтернативу, а потім запустивши його в двовіртуальному середовищі, спільнота може накопичити операційний досвід і створити впевненість у середовищі з низьким ризиком, уникнувши будь-яких незворотних змін. Цей поступовий підхід забезпечує стабільну основу для технологічної трансформації.
Повний аудит: нечітке тестування та формальна верифікація
Хоча формальна верифікація є остаточною метою, вона повинна поєднуватися з безперервним, інтенсивним тестуванням. Як продемонстрував Валентин з Diligence Security на телефонній конференції Ethproofs, їхній інструмент для поблякнення Argus виявив 11 ключових вразливостей щодо цілісності та надійності в провідному zkVM. Це свідчить про те, що навіть найкраще спроектовані системи можуть мати вразливості, які можуть бути виявлені лише за допомогою суворого суперечливого тестування. Поєднання поблякнення та формальної верифікації забезпечує більшу безпеку системи.
Стандартизація
Щоб уникнути фрагментації екосистеми, спільноті потрібно об'єднатися навколо єдиної, стандартизованої конфігурації RISC-V. Це може бути поєднання RV64GC з ABI, сумісним з Linux, оскільки ця комбінація має найширшу підтримку у переважній більшості мов програмування та інструментів, що дозволяє максимізувати переваги нової екосистеми. Стандартизація не лише підвищить ефективність розробників, але й закладе міцний фундамент для довгострокового розвитку екосистеми.
перевірене майбутнє Ethereum
Пропозиція замінити віртуальну машину Ethereum (EVM) на RISC-V є не просто поступовим оновленням, а радикальною реконструкцією виконавчого рівня Ethereum. Це амбітне бачення має на меті вирішення глибоких проблем масштабованості, спрощення складності протоколу та приведення платформи в відповідність з більш широкою екосистемою загального обчислення. Незважаючи на те, що ця трансформація стикається з величезними технічними та соціальними викликами, її довгострокові стратегічні переваги є достатніми, щоб виправдати цю сміливу ініціативу.
Це перетворення зосереджено на ряді основних компромісів:
Баланс між величезним підвищенням продуктивності, що забезпечується нативною архітектурою ZK, та нагальною потребою в зворотній сумісності;
Урахування переваг безпеки, що виникають від спрощених протоколів, та інерції величезного мережевого ефекту EVM.
Вибір між потужними можливостями універсальної екосистеми та ризиками, пов'язаними з залежністю від складних сторонніх інструментів.
Врешті-решт, ця трансформація архітектури стане ключовою для реалізації зобов'язання щодо «Схудлого виконання» (Lean Execution) і важливою складовою бачення «Схудлого Ethereum» (Lean Ethereum). Вона перетворить L1 Ethereum з простого платформи для смарт-контрактів на ефективний та безпечний шар розрахунків і доступності даних, спеціально розроблений для підтримки широкого всесвіту перевіряємих обчислень.
Як сказав Віталік Бутерін, "мета полягає в тому, щоб надати ZK-snark для всього."
Проекти, такі як Ethproofs, надають об'єктивні дані та платформу для співпраці для цієї трансформації, тоді як команда Succinct Labs завдяки практичному застосуванню свого SP1 zkVM надає дієвий план для цього майбутнього. Прийнявши RISC-V, Ethereum не лише вирішує власні проблеми з масштабованістю, але й позиціонує себе як базовий рівень довіри наступного покоління Інтернету, який підтримується третьою великою криптографічною примітивою SNARK після хешування та підписів.
Доказ програмного забезпечення світу, відкриваючи нову еру криптографії.
Дізнатися більше:
Інтерпретація Віталіка: натисніть, щоб переглянути
ETHProofs Четверта дискусія: натисніть, щоб переглянути
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Технічний борг тисне, Ethereum обирає «знищити і почати з нуля» з RISC-V
Автор: jaehaerys.eth
Компіліція: ShenChao TechFlow
Резюме
Ефір готується до найважливішої архітектурної трансформації з моменту свого виникнення: замінити EVM на RISC-V.
Причина дуже проста — у майбутньому, де основою є нульові знання (ZK), EVM вже став вузьким місцем продуктивності:
Рішення RISC-V:
Процес міграції поділяється на три етапи:
Вплив екосистеми:
Врешті-решт, ефіріум еволюціонує з "віртуальної машини смарт-контрактів" в надпростий, перевіряємий рівень довіри Інтернету, його кінцева мета – "щоб все було ZK-Snark-ом".
Перехрестя Ethereum
Віталік Бутерін колись сказав: "Кінцева мета включає в себе... зробити все ZK-Snark."
Кінець нульових доказів (ZK) неминучий, і його основний аргумент дуже простий: Ethereum починає з нуля, відновлюючи себе на основі нульових доказів. Це знаменує технічну точку завершення протоколу — через реконструкцію L1 досягти його остаточної форми, підтримуваної високопродуктивним zkVM, наданим основною командою розробників (такою як Succinct).
!
З цією метою візії Ethereum перебуває на найважливішому етапі архітектурної трансформації з моменту свого народження. Це обговорення вже не стосується поетапного оновлення, а є повною реконструкцією його обчислювального ядра — заміною віртуальної машини Ethereum (EVM). Цей крок є основою більш широкої візії "Схудлий Ethereum".
Візія Lean Ethereum має на меті систематичне спрощення всього протоколу, розділяючи його на три основні модулі: Lean Consensus, Lean Data та Lean Execution. А в основному питанні спрощеного виконання найважливішим є: чи став EVM, як двигун революції смарт-контрактів, основним вузьким місцем у майбутньому розвитку Ethereum?
!
Як зазначив Джастін Дрейк з Фонду Ethereum, довгостроковою метою Ethereum завжди було "Snarkify everything" (перетворити все на Snark), що є потужним інструментом для підсилення різних рівнів протоколу. Проте, протягом тривалого часу ця мета більше нагадувала "недосяжний план", оскільки її реалізація потребує концепції реального часу (real-time proving). А тепер, коли реальний час стає реальністю, теоретична неефективність EVM перетворилася на нагальну проблему, яку потрібно вирішити.
Ця стаття глибоко проаналізує технічні та стратегічні аргументи перенесення Ethereum L1 на архітектуру набору команд RISC-V. Цей крок не лише обіцяє звільнити безпрецедентну масштабованість, але й спростити структуру протоколу, а також забезпечити відповідність Ethereum майбутньому перевіреної обчислювальної потужності.
Що ж насправді змінилося?
Перед обговоренням "чому" спочатку потрібно визначити, "що" змінюється.
EVM (Ефірна віртуальна машина) є середовищем виконання смарт-контрактів Ефіру, яке називають «світовим комп'ютером», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років його дизайн вважається революційним, заклавши основи для виникнення децентралізованих фінансів (DeFi) та екосистеми NFT. Проте ця спеціалізована архітектура, розроблена майже десять років тому, тепер накопичила значну технічну заборгованість.
У порівнянні, RISC-V не є продуктом, а відкритим стандартом — безкоштовним, універсальним алфавітом дизайну процесорів. Як підкреслив Джеремі Бруестл на конференції Ethproofs, його ключові принципи роблять його чудовим вибором для цієї ролі:
!
проблема витрат інтерпретатора
Причини переходу від 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), не можуть безпосередньо отримувати доступ до стану блокчейну. Натомість їм потрібно через спеціальну інструкцію ECALL (виклик середовища) надіслати запит до довіреного ядра, яке працює в режимі нагляду (Supervisor Mode). Ця механіка створює безпечну межу, яка забезпечується апаратним забезпеченням, що робить її більш надійною та перевіряємою в порівнянні з моделлю 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: Будування доказу майбутнього сьогодні
!
Ефіріум готується до ривка. "Розширення 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 схем у Lean для формальної верифікації відповідно до офіційних стандартів RISC-V". Це знаковий прогрес, що переносить довіру з помилкових людських реалізацій на перевірні математичні докази, відкриваючи нові висоти безпеки блокчейну.
Основні ризики трансформації
Хоча архітектура RISC-V має безліч переваг на рівні L1, вона також приносить нові складні виклики.
Проблема вимірювання газу
Створення детермінованої та справедливої моделі Gas для загальної архітектури команд (ISA) є нерозв’язаною проблемою. Простий метод підрахунку команд піддається загрозі атак відмови в обслуговуванні. Наприклад, зловмисник може розробити програму, яка постійно викликає повне кешування, завдаючи великого споживання ресурсів за дуже низьку вартість Gas. Ця проблема ставить серйозні виклики перед стабільністю мережі та економічною моделлю.
Безпека інструментального набору та проблема "відтворювального складання"
Це найбільш важливий, але часто недооцінюваний ризик у процесі трансформації. Модель безпеки переходить від залежності від віртуальних машин на ланцюзі до залежності від компіляторів за межами ланцюга (таких як LLVM), які мають високу складність і відомі вразливості. Зловмисники можуть скористатися вразливостями компілятора, перетворюючи на перший погляд безневинний вихідний код на шкідливий байт-код. Крім того, забезпечити, щоб бінарні файли після компіляції на ланцюзі повністю відповідали опублікованому вихідному коду, тобто проблема “відтворювального складання”, також надзвичайно важко. Невеликі відмінності в середовищі збірки можуть призвести до отримання різних бінарних файлів, що вплине на прозорість і довіру. Ці проблеми ставлять серйозні випробування для безпеки розробників і користувачів.
Стратегії полегшення
Шлях вперед вимагає багаторівневої стратегії захисту.
Поетапне просування
Прийняття поетапного, багатофазного плану переходу є основною стратегією для управління ризиками. Спочатку вводячи RISC-V як попередньо скомпільовану альтернативу, а потім запустивши його в двовіртуальному середовищі, спільнота може накопичити операційний досвід і створити впевненість у середовищі з низьким ризиком, уникнувши будь-яких незворотних змін. Цей поступовий підхід забезпечує стабільну основу для технологічної трансформації.
Повний аудит: нечітке тестування та формальна верифікація
Хоча формальна верифікація є остаточною метою, вона повинна поєднуватися з безперервним, інтенсивним тестуванням. Як продемонстрував Валентин з Diligence Security на телефонній конференції Ethproofs, їхній інструмент для поблякнення Argus виявив 11 ключових вразливостей щодо цілісності та надійності в провідному zkVM. Це свідчить про те, що навіть найкраще спроектовані системи можуть мати вразливості, які можуть бути виявлені лише за допомогою суворого суперечливого тестування. Поєднання поблякнення та формальної верифікації забезпечує більшу безпеку системи.
Стандартизація
Щоб уникнути фрагментації екосистеми, спільноті потрібно об'єднатися навколо єдиної, стандартизованої конфігурації RISC-V. Це може бути поєднання RV64GC з ABI, сумісним з Linux, оскільки ця комбінація має найширшу підтримку у переважній більшості мов програмування та інструментів, що дозволяє максимізувати переваги нової екосистеми. Стандартизація не лише підвищить ефективність розробників, але й закладе міцний фундамент для довгострокового розвитку екосистеми.
перевірене майбутнє Ethereum
Пропозиція замінити віртуальну машину Ethereum (EVM) на RISC-V є не просто поступовим оновленням, а радикальною реконструкцією виконавчого рівня Ethereum. Це амбітне бачення має на меті вирішення глибоких проблем масштабованості, спрощення складності протоколу та приведення платформи в відповідність з більш широкою екосистемою загального обчислення. Незважаючи на те, що ця трансформація стикається з величезними технічними та соціальними викликами, її довгострокові стратегічні переваги є достатніми, щоб виправдати цю сміливу ініціативу.
Це перетворення зосереджено на ряді основних компромісів:
Врешті-решт, ця трансформація архітектури стане ключовою для реалізації зобов'язання щодо «Схудлого виконання» (Lean Execution) і важливою складовою бачення «Схудлого Ethereum» (Lean Ethereum). Вона перетворить L1 Ethereum з простого платформи для смарт-контрактів на ефективний та безпечний шар розрахунків і доступності даних, спеціально розроблений для підтримки широкого всесвіту перевіряємих обчислень.
Як сказав Віталік Бутерін, "мета полягає в тому, щоб надати ZK-snark для всього."
Проекти, такі як Ethproofs, надають об'єктивні дані та платформу для співпраці для цієї трансформації, тоді як команда Succinct Labs завдяки практичному застосуванню свого SP1 zkVM надає дієвий план для цього майбутнього. Прийнявши RISC-V, Ethereum не лише вирішує власні проблеми з масштабованістю, але й позиціонує себе як базовий рівень довіри наступного покоління Інтернету, який підтримується третьою великою криптографічною примітивою SNARK після хешування та підписів.
Доказ програмного забезпечення світу, відкриваючи нову еру криптографії.
Дізнатися більше:
Інтерпретація Віталіка: натисніть, щоб переглянути
ETHProofs Четверта дискусія: натисніть, щоб переглянути