Співзасновник Ethereum Віталік Бутерін нещодавно в спільноті Ethereum Magicians запропонував довгострокову пропозицію: замінити поточну віртуальну машину виконання (EVM) на відкриту архітектуру набору команд RISC-V. Він порівняв цю ідею з консенсусним рівнем Beam Chain, вважаючи, що це єдиний потенційний шлях до прориву в продуктивності виконувального рівня та спрощення логіки протоколу. Особливо в аспекті ефективності нульових знань (ZK Proof) Віталік очікує, що шляхом заміни EVM можна досягти оптимізації до 100 разів. Ця пропозиція має на меті вирішення нинішніх вузьких місць Ethereum у таких аспектах, як ефективність ZK доказів, складність побудови блоків, доступність даних.
У цій статті простими словами буде проаналізовано мотивацію, технічні деталі, шляхи реалізації та виклики цієї пропозиції, а також розглянуто її вплив на існуючі маршрути масштабування Ethereum, і буде зроблено огляд реакції спільноти та подібних спроб.
Од. Поточні обмеження EVM та переваги RISC-V
Проблема EVM:
Стара архітектура: EVM використовує 256-бітну стекову структуру, несумісну з сучасними ЦП, що призводить до низької ефективності при виконанні ZK-EVM.
Вузьке місце ZK-доказів: як зазначено в Succinct, приблизно половина ресурсів ZK-EVM використовується для виконання самого EVM, що обмежує ефективність ZK-доказів.
Погане обслуговування: протягом багатьох років накопичення складних функцій, плутанина в стандартах, наприклад, SELFDESTRUCT важко скасувати.
Обмежена розробка: нестандартний набір інструкцій обмежує крос-мовну підтримку, основні мови важко ефективно компілювати в байт-код EVM.
Переваги RISC-V:
Висока продуктивність: RISC-V є зменшеним набором інструкцій для справжніх ЦП, дружнім до апаратного забезпечення, може використовуватися для JIT-оптимізації або навіть апаратного прискорення.
ZK оптимізація: безпосереднє генерування схем для інструкцій RISC-V у ZK доказах є простішим, ніж доказ операцій EVM.
Зріла інструментальна ланцюг: підтримує основні мови, такі як Rust/C/C++, знижує бар'єри для розробки та забезпечує більш широке екосистему.
Загальні стандарти: вже використовуються такими блокчейнами, як Nervos CKB, мають успішні кейси.
Віталік зазначив, що замість того, щоб компілювати EVM у RISC-V у ZK-EVM, краще безпосередньо використовувати RISC-V як архітектуру виконання контрактів, що fundamentally підвищить ефективність виконання та потенціал розширення.
Два, шляхи заміни та виклики: як мігрувати з EVM?
Три варіанти заміни:
Подвійна VM паралельна (найконсервативніша): EVM та RISC-V працюють паралельно, нові контракти можуть використовувати RISC-V, забезпечуючи сумісність під час переходу.
Рішення інтерпретатора на базі блокчейн (радикальне): всі контракти EVM виконуються за допомогою інтерпретації контрактів RISC-V на базі блокчейн.
Механізм плагінів інтерпретатора (компроміс): використовувати інтерпретатор як елемент протоколу, що дозволяє в майбутньому вставляти інші віртуальні машини (наприклад, Move).
Технологічні виклики, що стоять перед реалізацією:
Ризик зниження продуктивності виконання: RISC-V на чіпах x86 потребує моделювання виконання, що може призвести до початкової ефективності нижчої, ніж у оптимізованого EVM.
Ціноутворення газу потребує реконструкції: потрібно визначити нову модель газу для інструкцій RISC-V, щоб забезпечити справедливість і безпеку.
Дизайн безпечного пісочниці: обмеження системних викликів, запобігання самозмінам коду, забезпечення детермінованого виконання.
Адаптація інструментів розробки: необхідно оновити компілятор, налагоджувальник, інструменти безпеки, підтримувати байтовий код RISC-V.
Проблеми сумісності міграції: деякі контракти залежать від особливостей EVM, міграція потребує обережного проектування сумісного шару або механізму відкату.
Віталік схиляється до варіанту першого як перехідного шляху і обіцяє, що нові та старі контракти зберігатимуть взаємодію, забезпечуючи незмінний досвід для розробників та безвідчутне оновлення для користувачів.
Три. Вплив на існуючі шляхи розширення: чи може RISC-V замінити L2, розподіл даних тощо?
Відповідь негативна: RISC-V є оптимізацією інфраструктури, не замінить існуючі маршрути розширення.
Шар 2:
Rollup все ще є основним засобом розширення Ethereum, RISC-V підвищує ефективність обробки L1 та продуктивність перевірки ZK, а не безпосередньо розширює пропускну здатність.
Швидша верифікація L1 може допомогти Rollup знизити витрати та швидше подавати дані, підвищуючи загальну масштабованість.
Розподіл даних та EIP-4844:
Проблеми з доступністю даних все ще потребують вирішення за допомогою EIP-4844 (blob) та Danksharding, RISC-V не впливає на обсяг даних в ланцюгу.
Зміна архітектури не вплине на вимоги до зберігання даних L1.
FaaS、MEV:
Не залежить від архітектури віртуальної машини і не втратить своєї актуальності через просування RISC-V.
Підсумок: RISC-V — це «заміна двигуна», L2/шарування — це «будівництво шляхів», обидва виміри різні, але паралельні.
Чотири, зворотний зв'язок від спільноти та відповідні спроби
Розбіжності в спільноті:
Прихильники: вважають, що це необхідне стратегічне оновлення для реагування на виклики продуктивності, такі як Solana/Sui, що допомагає залучити традиційних розробників.
Консерватори: стурбовані труднощами впровадження, історичним тягарем, великими витратами на оновлення екологічних інструментів, ставлять під сумнів співвідношення витрат і вигод ресурсів.
Посилання на подібні проекти:
Move VM (Aptos/Sui): абсолютно новий ресурсно-орієнтований Блок, з високою безпекою мови, але несумісний з EVM.
FuelVM: нова VM, розроблена для паралельної обробки, в парі з мовою Sway, має обмежену сумісність.
WASM (Stylus): Введення WASM як мови контрактів у L2, вже реалізовано в Arbitrum, має реальну життєздатність.
Nervos CKB: Використання RISC-V в основній мережі як VM для контрактів є прецедентом, що надає практичну довідку для Ethereum.
Віталік заявив, що висунення RISC-V не означає відмову від інших варіантів, він вважає, що в майбутньому механізми інтерпретації також можуть бути використані для вставки таких VM, як Move, WASM тощо, для побудови різноманітної екосистеми виконання.
Пункт п'ять. Перспективи майбутнього впливу: якщо Ефіріум перейде на RISC-V
Досвід розробника:
Мови такі як Solidity/Vyper все ще можуть використовуватися, зміни відбуваються на стороні компілятора, а не самої мови.
Можливо, відкриють нові мови для написання контрактів, такі як Rust/C, але не будуть змушувати до міграції.
Витрати на експлуатацію та продуктивність:
Підвищення ефективності виконання призведе до більшого ліміту Gas та нижчих витрат.
Контракт RISC-V може зменшити залежність від попередньо скомпільованих контрактів, модель Gas більш наближена до вартості ZK-доказів.
Екологічна сумісність та розвиток:
Протягом періоду співіснування двох VM існуючі контракти можуть продовжувати працювати, нові контракти поступово переходять на RISC-V.
Інфраструктура повинна підтримувати новий формат байт-коду, що може викликати зміни у сумісності між блокчейнами (наприклад, питання про залишення або вихід BSC, Polygon).
Безпека та стабільність:
Нова архітектура потребує широких випробувань та формальної верифікації для підвищення надійності протоколу.
Більш простий виконавчий рівень сприяє аудиту та контролю за атакуваною поверхнею.
Висновок
Віталік запропонував замінити EVM Ethereum на RISC-V, що є глибоким роздумом Ethereum про майбутні межі продуктивності та простоту протоколу. Ця пропозиція все ще перебуває на ранній стадії обговорення, і очікується, що її реалізація буде тривати кілька років, оскільки потрібно подолати численні технічні, спільнотні та екологічні виклики. Це не скасування існуючого курсу, а скоріше укріплення основи, підготовка до майбутнього.
Як сказав Віталік: "Щоб досягти підвищення в кілька порядків, це радикальна зміна, можливо, є єдиним життєздатним шляхом."
Ми можемо розглядати це як ставку на майбутнє, а також як глибоке дослідження питання "чи варто перепроєктувати базу".
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Віталік Бутерін радикальна пропозиція: замінити EVM Ethereum на RISC-V, ZK - остаточне рішення для масштабування?
Автор | GaryMa У мові Блокчейн
Вступ
Співзасновник Ethereum Віталік Бутерін нещодавно в спільноті Ethereum Magicians запропонував довгострокову пропозицію: замінити поточну віртуальну машину виконання (EVM) на відкриту архітектуру набору команд RISC-V. Він порівняв цю ідею з консенсусним рівнем Beam Chain, вважаючи, що це єдиний потенційний шлях до прориву в продуктивності виконувального рівня та спрощення логіки протоколу. Особливо в аспекті ефективності нульових знань (ZK Proof) Віталік очікує, що шляхом заміни EVM можна досягти оптимізації до 100 разів. Ця пропозиція має на меті вирішення нинішніх вузьких місць Ethereum у таких аспектах, як ефективність ZK доказів, складність побудови блоків, доступність даних.
У цій статті простими словами буде проаналізовано мотивацію, технічні деталі, шляхи реалізації та виклики цієї пропозиції, а також розглянуто її вплив на існуючі маршрути масштабування Ethereum, і буде зроблено огляд реакції спільноти та подібних спроб.
Од. Поточні обмеження EVM та переваги RISC-V
Проблема EVM:
Стара архітектура: EVM використовує 256-бітну стекову структуру, несумісну з сучасними ЦП, що призводить до низької ефективності при виконанні ZK-EVM.
Вузьке місце ZK-доказів: як зазначено в Succinct, приблизно половина ресурсів ZK-EVM використовується для виконання самого EVM, що обмежує ефективність ZK-доказів.
Погане обслуговування: протягом багатьох років накопичення складних функцій, плутанина в стандартах, наприклад, SELFDESTRUCT важко скасувати.
Обмежена розробка: нестандартний набір інструкцій обмежує крос-мовну підтримку, основні мови важко ефективно компілювати в байт-код EVM.
Переваги RISC-V:
Висока продуктивність: RISC-V є зменшеним набором інструкцій для справжніх ЦП, дружнім до апаратного забезпечення, може використовуватися для JIT-оптимізації або навіть апаратного прискорення.
ZK оптимізація: безпосереднє генерування схем для інструкцій RISC-V у ZK доказах є простішим, ніж доказ операцій EVM.
Зріла інструментальна ланцюг: підтримує основні мови, такі як Rust/C/C++, знижує бар'єри для розробки та забезпечує більш широке екосистему.
Загальні стандарти: вже використовуються такими блокчейнами, як Nervos CKB, мають успішні кейси.
Віталік зазначив, що замість того, щоб компілювати EVM у RISC-V у ZK-EVM, краще безпосередньо використовувати RISC-V як архітектуру виконання контрактів, що fundamentally підвищить ефективність виконання та потенціал розширення.
Два, шляхи заміни та виклики: як мігрувати з EVM?
Три варіанти заміни:
Подвійна VM паралельна (найконсервативніша): EVM та RISC-V працюють паралельно, нові контракти можуть використовувати RISC-V, забезпечуючи сумісність під час переходу.
Рішення інтерпретатора на базі блокчейн (радикальне): всі контракти EVM виконуються за допомогою інтерпретації контрактів RISC-V на базі блокчейн.
Механізм плагінів інтерпретатора (компроміс): використовувати інтерпретатор як елемент протоколу, що дозволяє в майбутньому вставляти інші віртуальні машини (наприклад, Move).
Технологічні виклики, що стоять перед реалізацією:
Ризик зниження продуктивності виконання: RISC-V на чіпах x86 потребує моделювання виконання, що може призвести до початкової ефективності нижчої, ніж у оптимізованого EVM.
Ціноутворення газу потребує реконструкції: потрібно визначити нову модель газу для інструкцій RISC-V, щоб забезпечити справедливість і безпеку.
Дизайн безпечного пісочниці: обмеження системних викликів, запобігання самозмінам коду, забезпечення детермінованого виконання.
Адаптація інструментів розробки: необхідно оновити компілятор, налагоджувальник, інструменти безпеки, підтримувати байтовий код RISC-V.
Проблеми сумісності міграції: деякі контракти залежать від особливостей EVM, міграція потребує обережного проектування сумісного шару або механізму відкату.
Віталік схиляється до варіанту першого як перехідного шляху і обіцяє, що нові та старі контракти зберігатимуть взаємодію, забезпечуючи незмінний досвід для розробників та безвідчутне оновлення для користувачів.
Три. Вплив на існуючі шляхи розширення: чи може RISC-V замінити L2, розподіл даних тощо?
Відповідь негативна: RISC-V є оптимізацією інфраструктури, не замінить існуючі маршрути розширення.
Шар 2:
Rollup все ще є основним засобом розширення Ethereum, RISC-V підвищує ефективність обробки L1 та продуктивність перевірки ZK, а не безпосередньо розширює пропускну здатність.
Швидша верифікація L1 може допомогти Rollup знизити витрати та швидше подавати дані, підвищуючи загальну масштабованість.
Розподіл даних та EIP-4844:
Проблеми з доступністю даних все ще потребують вирішення за допомогою EIP-4844 (blob) та Danksharding, RISC-V не впливає на обсяг даних в ланцюгу.
Зміна архітектури не вплине на вимоги до зберігання даних L1.
FaaS、MEV:
Не залежить від архітектури віртуальної машини і не втратить своєї актуальності через просування RISC-V.
Підсумок: RISC-V — це «заміна двигуна», L2/шарування — це «будівництво шляхів», обидва виміри різні, але паралельні.
Чотири, зворотний зв'язок від спільноти та відповідні спроби
Розбіжності в спільноті:
Прихильники: вважають, що це необхідне стратегічне оновлення для реагування на виклики продуктивності, такі як Solana/Sui, що допомагає залучити традиційних розробників.
Консерватори: стурбовані труднощами впровадження, історичним тягарем, великими витратами на оновлення екологічних інструментів, ставлять під сумнів співвідношення витрат і вигод ресурсів.
Посилання на подібні проекти:
Move VM (Aptos/Sui): абсолютно новий ресурсно-орієнтований Блок, з високою безпекою мови, але несумісний з EVM.
FuelVM: нова VM, розроблена для паралельної обробки, в парі з мовою Sway, має обмежену сумісність.
WASM (Stylus): Введення WASM як мови контрактів у L2, вже реалізовано в Arbitrum, має реальну життєздатність.
Nervos CKB: Використання RISC-V в основній мережі як VM для контрактів є прецедентом, що надає практичну довідку для Ethereum.
Віталік заявив, що висунення RISC-V не означає відмову від інших варіантів, він вважає, що в майбутньому механізми інтерпретації також можуть бути використані для вставки таких VM, як Move, WASM тощо, для побудови різноманітної екосистеми виконання.
Пункт п'ять. Перспективи майбутнього впливу: якщо Ефіріум перейде на RISC-V
Досвід розробника:
Мови такі як Solidity/Vyper все ще можуть використовуватися, зміни відбуваються на стороні компілятора, а не самої мови.
Можливо, відкриють нові мови для написання контрактів, такі як Rust/C, але не будуть змушувати до міграції.
Витрати на експлуатацію та продуктивність:
Підвищення ефективності виконання призведе до більшого ліміту Gas та нижчих витрат.
Контракт RISC-V може зменшити залежність від попередньо скомпільованих контрактів, модель Gas більш наближена до вартості ZK-доказів.
Екологічна сумісність та розвиток:
Протягом періоду співіснування двох VM існуючі контракти можуть продовжувати працювати, нові контракти поступово переходять на RISC-V.
Інфраструктура повинна підтримувати новий формат байт-коду, що може викликати зміни у сумісності між блокчейнами (наприклад, питання про залишення або вихід BSC, Polygon).
Безпека та стабільність:
Нова архітектура потребує широких випробувань та формальної верифікації для підвищення надійності протоколу.
Більш простий виконавчий рівень сприяє аудиту та контролю за атакуваною поверхнею.
Висновок
Віталік запропонував замінити EVM Ethereum на RISC-V, що є глибоким роздумом Ethereum про майбутні межі продуктивності та простоту протоколу. Ця пропозиція все ще перебуває на ранній стадії обговорення, і очікується, що її реалізація буде тривати кілька років, оскільки потрібно подолати численні технічні, спільнотні та екологічні виклики. Це не скасування існуючого курсу, а скоріше укріплення основи, підготовка до майбутнього.
Як сказав Віталік: "Щоб досягти підвищення в кілька порядків, це радикальна зміна, можливо, є єдиним життєздатним шляхом."
Ми можемо розглядати це як ставку на майбутнє, а також як глибоке дослідження питання "чи варто перепроєктувати базу".
Джерело посилання: