Новий пропозиція Віталіка: замінити поточний EVM на RISC-V

Ця стаття пропонує радикальну ідею для майбутнього виконавчого рівня Ethereum, яка є такою ж амбітною, як зусилля Beam Chain щодо рівня консенсусу. Вона має на меті суттєво підвищити ефективність виконавчого рівня Ethereum, вирішити одну з головних вузьких місць масштабування і також значно спростити виконавчий рівень — насправді, можливо, це єдиний спосіб.

Ідея: замінити EVM на RISC-V як мову віртуальної машини для написання смарт-контрактів (примітка перекладача: RISC-V - це відкрита архітектура команд, заснована на принципах обчислень з використанням скороченого набору команд RISC, де V позначає п’яте покоління RISC).

Важливе уточнення:

• Концепції аккаунтів, міжконтрактних викликів, зберігання тощо залишаться абсолютно тими ж. Ці абстракції працюють дуже добре, і розробники звикли до них. Операційні коди SLOAD, SSTORE, BALANCE, CALL стануть системними викликами RISC-V.
• У такому світі смарт-контракти можна писати на Rust, але я очікую, що більшість розробників продовжить писати смарт-контракти на Solidity (або Vyper), що дозволить додати RISC-V як бекенд. Це пов’язано з тим, що смарт-контракти на Rust насправді виглядають досить неохайно, тоді як читабельність Solidity і Vyper значно вища. Можливо, зміни в devex незначні, і розробники, можливо, майже не помітять цієї зміни.
• Старі контракти EVM залишаться діючими та повністю взаємодіятимуть з новими контрактами RISC-V. Є кілька способів це здійснити, про які я розповім пізніше в цій статті.

Одним із прикладів є Nervos CKB VM, яка в основному є RISC-V.

Чому так?

У короткостроковій перспективі основні вузькі місця в масштабованості L1 Ethereum будуть усунені за допомогою майбутніх EIP, таких як списки доступу на рівні блоків, відкладене виконання та розподілене сховище історії, а також EIP-4444. У середньостроковій перспективі ми розглянемо подальші проблеми з безгромадянством та ZK-EVM. У довгостроковій перспективі основними обмежуючими факторами для масштабування рівня 1 Ethereum є:

• Стабільність вибірки доступності даних та протоколу історичного зберігання
• Сподіваюся зберегти конкурентоспроможність ринку виробництва блоків
• ZK-EVM верифікаційні можливості

Я вважаю, що заміна ZK-EVM на RISC-V може вирішити одну з ключових вузьких місць у (2) та (3).

Це таблиця циклів для доведення різних частин виконавчого рівня EVM, що використовує Succinct ZK-EVM:

! nsRqhscTyRR2vPvAOgUE58HVgFHuLUgGxTescWwT.jpeg

Є чотири частини, які займають багато часу: десеріалізувати_inputs, ініціалізувати_witness_db, стан_root_computation і заблокувати_execution.

initialize_witness_db та state_root_computation пов’язані з деревом стану, deserialize_inputs означає процес перетворення блоку та свідчень у внутрішнє представлення; отже, насправді понад 50% пропорційно до масштабу свідчення.

Можна значно оптимізувати ці частини, замінивши поточне дерево Merkle patricia на 16-байтове на дерево з бінарними деревами, що використовують дружні до доказувача хеш-функції. Якщо ми використовуємо Poseidon, ми можемо підтвердити 2 мільйони хешів на секунду на ноутбуку (тоді як keccak — приблизно 15 000 хешів на секунду). Крім Poseidon, є багато інших варіантів. Загалом, у нас є можливість суттєво зменшити ці компоненти. Як бонус, ми можемо позбутися accrue_logs_bloom, позбувшись bloom.

Решта – це блок_execution, на який припадає близько половини циклів доведення, витрачених сьогодні. Якщо ми хочемо збільшити загальний ККД провера в 100 разів, то ми не можемо уникнути того факту, що нам потрібно збільшити ефективність EVM як мінімум в 50 разів. Одна річ, яку ми можемо зробити, це спробувати створити реалізацію EVM, яка буде більш ефективною з точки зору циклів доказу. Ще одна річ, яку ми можемо зробити, це помітити, що проповідник ZK-EVM вже сьогодні працює, доводячи реалізацію EVM, скомпільовану в RISC-V, і надаючи розробникам смарт-контрактів прямий доступ до цієї віртуальної машини RISC-V.

Деякі дані свідчать про те, що в обмежених умовах це може підвищити ефективність більш ніж у 100 разів:

Насправді, я очікую, що залишковий час на доказ буде в основному визначатися попередньою компіляцією сьогодні. Якщо ми візьмемо RISC-V як основну віртуальну машину, то план gas відображатиме час доказу, тому буде економічний тиск, щоб призупинити використання дорожчих попередніх компіляцій; але навіть у такому випадку прибутки не будуть такими вражаючими, проте у нас є всі підстави вірити, що прибутки будуть дуже значними.

(До речі, приблизно 50/50 розподіл між “EVM” та “іншими речами” також спостерігається у звичайному виконанні EVM, ми інтуїтивно очікуємо, що вигоди, які мають бути видалені з EVM як “посередника”, мають бути такими ж великими)

Деталі реалізації

Існує кілька способів реалізації таких пропозицій. Найменш руйнівним методом є підтримка двох віртуальних машин і дозволення написання контрактів на будь-якій з віртуальних машин. Обидва типи контрактів можуть використовувати однакові типи ресурсів: постійне сховище (SLOAD та SSTORE), можливість утримувати баланс ETH, можливість дзвонити та приймати дзвінки тощо. Контракти EVM та RISC-V можуть вільно викликати один одного; з точки зору RISC-V виклик контракту EVM виглядає як системний виклик з деякими спеціальними параметрами; EVM контракт, що отримує це повідомлення, інтерпретує його як CALL.

З точки зору протоколу, більш агресивним підходом є перетворення існуючих смарт-контрактів EVM на контракти, які викликають інтерпретатор EVM, написаний на RISC-V, що виконує їх існуючий код EVM. Іншими словами, якщо смарт-контракт EVM має код C, а інтерпретатор EVM знаходиться за адресою X, то цей контракт буде замінений на верхню логіку, коли ззовні викликається з параметрами D, використовуючи (C, D) для виклику X, а потім чекати на повернуте значення та переслати його. Якщо сам інтерпретатор EVM викликає контракт, вимагаючи виконати CALL або SLOAD/SSTORE, то контракт зробить це.

Середній шлях — це вибір другого варіанту, але з чітким визначенням функції протоколу — по суті, взяти концепцію “інтерпретатора віртуальної машини” за еталон і вимагати, щоб її логіка була написана на RISC-V. EVM буде першим, але можуть бути й інші (наприклад, Move може бути кандидатом).

Основною перевагою другого та третього пропозицій є те, що вони значно спрощують специфікацію шару виконання — насправді, ця ідея може бути єдиним життєздатним методом, оскільки навіть такі поступові спрощення, як видалення SELFDESTRUCT, є дуже складними. Tinygrad має суворе правило, що обсяг коду ніколи не перевищує 10 000 рядків; найкращий базовий рівень блокчейну повинен добре відповідати цим межам, а навіть бути меншим. Зусилля Beam Chain мають великі надії на значне спрощення консенсусу Ethereum. Але для шару виконання, щоб досягти подібних переваг, така радикальна зміна може бути єдиним життєздатним шляхом.