20 квітня Віталік Бутерін на платформі Ethereum Magicians запропонував важливу пропозицію щодо довгострокового рівня виконання L1 Ethereum. Він запропонував використовувати архітектуру RISC-V замість існуючої EVM (віртуальної машини Ethereum) як мову віртуальної машини для написання смарт-контрактів, що має на меті фундаментально підвищити ефективність роботи рівня виконання Ethereum, подолати одну з основних вузьких місць масштабування та суттєво спростити його простоту.
Foresight News здійснив повний переклад цієї пропозиції, щоб допомогти читачам зрозуміти цю технологічну концепцію. Нижче наведено переклад оригінального тексту пропозиції:
Ця стаття пропонує радикальну ідею щодо майбутнього виконавчого шару Ethereum, яка не є менш амбітною, ніж план Beam Chain для шарів консенсусу. Ця пропозиція має на меті значно підвищити ефективність виконавчого шару Ethereum, вирішити одну з основних проблем масштабування та суттєво спростити виконавчий шар — насправді, це може бути єдиний шлях до досягнення цієї мети.
Основна ідея: замінити EVM на RISC-V як мову віртуальної машини для написання смарт-контрактів.
Важливе повідомлення:
Система облікових записів, міжконтрактні виклики, зберігання та інші концепції будуть повністю збережені. Ці абстрактні дизайни добре працюють, і розробники звикли їх використовувати. Операційні коди такі як SLOAD, SSTORE, BALANCE, CALL будуть перетворені на системні виклики RISC-V.
У цьому режимі смарт-контракти можна писати на Rust, але я очікую, що більшість розробників все ще буде продовжувати використовувати Solidity (або Vyper) для написання контрактів, ці мови будуть адаптовані до RISC-V як нового бекенду. Оскільки смарт-контракти, написані на Rust, насправді мають гіршу читабельність, тоді як Solidity і Vyper є більш зрозумілими. Досвід розробки може бути майже неушкодженим, розробники навіть можуть не помітити змін.
Старі версії EVM-контрактів продовжать працювати і будуть повністю двосторонньо сумісні з новими RISC-V контрактами. Є кілька способів реалізації, які будуть детально розглянуті в цій статті.
Nervos CKB VM вже став прикладом, його суть полягає в реалізації RISC-V.
Чому так?
У короткостроковій перспективі, запроваджені EIP (такі як списки доступу на рівні блоків, затримане виконання, розподілене зберігання історії та EIP-4444) можуть вирішити основні вузькі місця масштабування Ethereum L1. У середньостроковій перспективі більше проблем буде вирішено за допомогою безстатевості та ZK-EVM. У довгостроковій перспективі, основними обмежуючими факторами масштабування Ethereum L1 стануть:
Стабільність протоколу вибірки доступності даних та історичного зберігання
потреба підтримувати конкурентоспроможність ринку виробництва блоків
Доказувальна здатність ZK-EVM
Я доведу, що заміна ZK-EVM на RISC-V може вирішити ключові вузькі місця в (2) та (3).
Нижче наведена таблиця, яка показує кількість циклів, необхідних для підтвердження виконання EVM на всіх етапах Succinct ZK-EVM:
Графічне пояснення: Чотири основні витратні етапи - це deserialize_inputs, initialize_witness_db, state_root_computation та block_execution
Серед них initialize_witness_db та state_root_computation пов'язані з деревом стану, а deserialize_inputs стосується процесу перетворення блоків та свідчень у внутрішнє представлення — насправді понад 50% пропорційні розміру свідчень.
Замінивши поточне дерево Меркла Патриції keccak 16-ary на бінарне дерево, що використовує хеш-функції, які легко довести, ці частини можуть бути значно оптимізовані. Якщо використовувати Poseidon, ми можемо доводити 2 мільйони хешів на секунду на ноутбуці (для порівняння, keccak близько 15 000 hash/sec). Окрім Poseidon, є багато інших варіантів. Загалом, ці компоненти мають великий потенціал для оптимізації. Крім того, ми можемо усунути bloom, щоб ліквідувати accrue_logs_bloom.
На блок, що залишився_execution припадає близько половини поточних циклів провера. Щоб досягти 100-кратного збільшення загальної ефективності доказу, потрібна ефективність доказу EVM принаймні в 50 разів. Одне рішення полягає в тому, щоб створити більш ефективну реалізацію доказу для EVM, а інше полягає в тому, щоб помітити, що поточний виконавець ZK-EVM фактично компілює EVM в RISC-V для доказу, надаючи розробникам смарт-контрактів прямий доступ до віртуальної машини RISC-V.
Деякі дані свідчать про те, що в певних випадках підвищення ефективності може перевищувати 100 разів:
У реальних застосуваннях залишковий час prover може бути переважно зайнятий поточними операціями попередньої компіляції (precompiles). Якщо використовувати RISC-V як основну віртуальну машину, графік Gas відображатиме фактичний час доказу, а економічний тиск спонукатиме розробників зменшити використання дорогих попередніх компіляцій. Навіть так, вигоди не будуть такими суттєвими, але в нас є всі підстави вірити, що ці вигоди будуть дуже значними.
(Варто зазначити, що в звичайному виконанні EVM частка витрат часу на «EVM операції» та «інші операції» також близька до 50/50, тому ми інтуїтивно вважаємо, що видалення EVM як «проміжного шару» принесе таку ж значну вигоду)
деталі впровадження
Ця пропозиція має кілька способів реалізації. Найменш руйнівним варіантом є одночасна підтримка двох віртуальних машин, що дозволяє контрактам вибирати будь-яку з них для написання. Обидва типи контрактів можуть отримувати доступ до одних і тих же функцій: персистентне зберігання (SLOAD/SSTORE), можливість тримати ETH баланс, ініціювання / отримання викликів тощо. Контракти EVM і RISC-V можуть викликати один одного — з точки зору RISC-V виклик контракту EVM є еквівалентом виконання системного виклику з особливими параметрами; в той час як EVM контракт, що отримує повідомлення, буде інтерпретувати його як CALL.
З точки зору протоколу більш радикальним підходом є перетворення існуючого EVM-контракту в контракт EVM-інтерпретатора, написаного на RISC-V, для виконання його існуючого EVM-коду. Тобто, якщо EVM-контракт має код C, а EVM-інтерпретатор знаходиться за адресою X, то цей контракт буде замінений на верхній рівень логіки, коли ззовні викликається з параметрами D, викликом X і передаванням (C, D), після чого чекає повернення значення і пересилає його далі. Якщо сам EVM-інтерпретатор викликає цей контракт, вимагаючи виконання CALL або SLOAD/SSTORE, то контракт виконує ці операції.
Компромісним рішенням є прийняття другого варіанту, але через угоду чітко підтримується концепція "інтерпретатора віртуальної машини", що вимагає, щоб його логіка була написана на RISC-V. EVM буде першим прикладом, в майбутньому також можуть підтримуватися інші мови (Move може бути кандидатним варіантом).
Основна перевага другого і третього варіантів полягає в тому, що вони значно спрощують специфікацію рівня виконання. З ОГЛЯДУ НА СКЛАДНІСТЬ НАВІТЬ УСУНЕННЯ ПОСТУПОВИХ СПРОЩЕНЬ, ТАКИХ ЯК САМОЗНИЩЕННЯ, ЦЕЙ СПОСІБ МИСЛЕННЯ МОЖЕ БУТИ ЄДИНИМ ЖИТТЄЗДАТНИМ ШЛЯХОМ ДЛЯ СПРОЩЕННЯ. Tinygrad дотримується жорсткого правила «не більше 10 000 рядків коду», і оптимальний базовий блокчейн повинен бути в змозі легко відповідати цьому ліміту і бути ще більш оптимізованим. Ініціатива Beam Chain обіцяє значно спростити рівень консенсусу Ethereum, і така радикальна зміна може бути єдиним способом досягти подібного приросту на рівні виконання.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Повний текст пропозиції Vitalik щодо L1 виконавчого рівня: замінити EVM на RISC-V
Джерело: Віталік Бутерін
Компіляція: KarenZ, Foresight News
20 квітня Віталік Бутерін на платформі Ethereum Magicians запропонував важливу пропозицію щодо довгострокового рівня виконання L1 Ethereum. Він запропонував використовувати архітектуру RISC-V замість існуючої EVM (віртуальної машини Ethereum) як мову віртуальної машини для написання смарт-контрактів, що має на меті фундаментально підвищити ефективність роботи рівня виконання Ethereum, подолати одну з основних вузьких місць масштабування та суттєво спростити його простоту.
Foresight News здійснив повний переклад цієї пропозиції, щоб допомогти читачам зрозуміти цю технологічну концепцію. Нижче наведено переклад оригінального тексту пропозиції:
Ця стаття пропонує радикальну ідею щодо майбутнього виконавчого шару Ethereum, яка не є менш амбітною, ніж план Beam Chain для шарів консенсусу. Ця пропозиція має на меті значно підвищити ефективність виконавчого шару Ethereum, вирішити одну з основних проблем масштабування та суттєво спростити виконавчий шар — насправді, це може бути єдиний шлях до досягнення цієї мети.
Основна ідея: замінити EVM на RISC-V як мову віртуальної машини для написання смарт-контрактів.
Важливе повідомлення:
Система облікових записів, міжконтрактні виклики, зберігання та інші концепції будуть повністю збережені. Ці абстрактні дизайни добре працюють, і розробники звикли їх використовувати. Операційні коди такі як SLOAD, SSTORE, BALANCE, CALL будуть перетворені на системні виклики RISC-V.
У цьому режимі смарт-контракти можна писати на Rust, але я очікую, що більшість розробників все ще буде продовжувати використовувати Solidity (або Vyper) для написання контрактів, ці мови будуть адаптовані до RISC-V як нового бекенду. Оскільки смарт-контракти, написані на Rust, насправді мають гіршу читабельність, тоді як Solidity і Vyper є більш зрозумілими. Досвід розробки може бути майже неушкодженим, розробники навіть можуть не помітити змін.
Старі версії EVM-контрактів продовжать працювати і будуть повністю двосторонньо сумісні з новими RISC-V контрактами. Є кілька способів реалізації, які будуть детально розглянуті в цій статті.
Nervos CKB VM вже став прикладом, його суть полягає в реалізації RISC-V.
Чому так?
У короткостроковій перспективі, запроваджені EIP (такі як списки доступу на рівні блоків, затримане виконання, розподілене зберігання історії та EIP-4444) можуть вирішити основні вузькі місця масштабування Ethereum L1. У середньостроковій перспективі більше проблем буде вирішено за допомогою безстатевості та ZK-EVM. У довгостроковій перспективі, основними обмежуючими факторами масштабування Ethereum L1 стануть:
Стабільність протоколу вибірки доступності даних та історичного зберігання
потреба підтримувати конкурентоспроможність ринку виробництва блоків
Доказувальна здатність ZK-EVM
Я доведу, що заміна ZK-EVM на RISC-V може вирішити ключові вузькі місця в (2) та (3).
Нижче наведена таблиця, яка показує кількість циклів, необхідних для підтвердження виконання EVM на всіх етапах Succinct ZK-EVM:
Графічне пояснення: Чотири основні витратні етапи - це deserialize_inputs, initialize_witness_db, state_root_computation та block_execution
Серед них initialize_witness_db та state_root_computation пов'язані з деревом стану, а deserialize_inputs стосується процесу перетворення блоків та свідчень у внутрішнє представлення — насправді понад 50% пропорційні розміру свідчень.
Замінивши поточне дерево Меркла Патриції keccak 16-ary на бінарне дерево, що використовує хеш-функції, які легко довести, ці частини можуть бути значно оптимізовані. Якщо використовувати Poseidon, ми можемо доводити 2 мільйони хешів на секунду на ноутбуці (для порівняння, keccak близько 15 000 hash/sec). Окрім Poseidon, є багато інших варіантів. Загалом, ці компоненти мають великий потенціал для оптимізації. Крім того, ми можемо усунути bloom, щоб ліквідувати accrue_logs_bloom.
На блок, що залишився_execution припадає близько половини поточних циклів провера. Щоб досягти 100-кратного збільшення загальної ефективності доказу, потрібна ефективність доказу EVM принаймні в 50 разів. Одне рішення полягає в тому, щоб створити більш ефективну реалізацію доказу для EVM, а інше полягає в тому, щоб помітити, що поточний виконавець ZK-EVM фактично компілює EVM в RISC-V для доказу, надаючи розробникам смарт-контрактів прямий доступ до віртуальної машини RISC-V.
Деякі дані свідчать про те, що в певних випадках підвищення ефективності може перевищувати 100 разів:
У реальних застосуваннях залишковий час prover може бути переважно зайнятий поточними операціями попередньої компіляції (precompiles). Якщо використовувати RISC-V як основну віртуальну машину, графік Gas відображатиме фактичний час доказу, а економічний тиск спонукатиме розробників зменшити використання дорогих попередніх компіляцій. Навіть так, вигоди не будуть такими суттєвими, але в нас є всі підстави вірити, що ці вигоди будуть дуже значними.
(Варто зазначити, що в звичайному виконанні EVM частка витрат часу на «EVM операції» та «інші операції» також близька до 50/50, тому ми інтуїтивно вважаємо, що видалення EVM як «проміжного шару» принесе таку ж значну вигоду)
деталі впровадження
Ця пропозиція має кілька способів реалізації. Найменш руйнівним варіантом є одночасна підтримка двох віртуальних машин, що дозволяє контрактам вибирати будь-яку з них для написання. Обидва типи контрактів можуть отримувати доступ до одних і тих же функцій: персистентне зберігання (SLOAD/SSTORE), можливість тримати ETH баланс, ініціювання / отримання викликів тощо. Контракти EVM і RISC-V можуть викликати один одного — з точки зору RISC-V виклик контракту EVM є еквівалентом виконання системного виклику з особливими параметрами; в той час як EVM контракт, що отримує повідомлення, буде інтерпретувати його як CALL.
З точки зору протоколу більш радикальним підходом є перетворення існуючого EVM-контракту в контракт EVM-інтерпретатора, написаного на RISC-V, для виконання його існуючого EVM-коду. Тобто, якщо EVM-контракт має код C, а EVM-інтерпретатор знаходиться за адресою X, то цей контракт буде замінений на верхній рівень логіки, коли ззовні викликається з параметрами D, викликом X і передаванням (C, D), після чого чекає повернення значення і пересилає його далі. Якщо сам EVM-інтерпретатор викликає цей контракт, вимагаючи виконання CALL або SLOAD/SSTORE, то контракт виконує ці операції.
Компромісним рішенням є прийняття другого варіанту, але через угоду чітко підтримується концепція "інтерпретатора віртуальної машини", що вимагає, щоб його логіка була написана на RISC-V. EVM буде першим прикладом, в майбутньому також можуть підтримуватися інші мови (Move може бути кандидатним варіантом).
Основна перевага другого і третього варіантів полягає в тому, що вони значно спрощують специфікацію рівня виконання. З ОГЛЯДУ НА СКЛАДНІСТЬ НАВІТЬ УСУНЕННЯ ПОСТУПОВИХ СПРОЩЕНЬ, ТАКИХ ЯК САМОЗНИЩЕННЯ, ЦЕЙ СПОСІБ МИСЛЕННЯ МОЖЕ БУТИ ЄДИНИМ ЖИТТЄЗДАТНИМ ШЛЯХОМ ДЛЯ СПРОЩЕННЯ. Tinygrad дотримується жорсткого правила «не більше 10 000 рядків коду», і оптимальний базовий блокчейн повинен бути в змозі легко відповідати цьому ліміту і бути ще більш оптимізованим. Ініціатива Beam Chain обіцяє значно спростити рівень консенсусу Ethereum, і така радикальна зміна може бути єдиним способом досягти подібного приросту на рівні виконання.