Цей постулає радикальну ідею для майбутнього рівня виконання Ethereum, яка є такою ж амбіційною, як зусилля ланцюга променів для рівня консенсусу. Він спрямований на значне покращення ефективності рівня виконання Ethereum, вирішуючи один з основних масштабувальних проблем, і також може значно покращити простоту рівня виконання - фактично, це, можливо, єдиний спосіб цього зробити.
Ідея: замінити EVM на RISC-V як мову віртуальної машини, на якій написані розумні контракти.
Важливі пояснення:
- Концепції рахунків, виклики між контрактами, сховище тощо залишаться точно такими ж. Ці абстракції працюють добре, і розробники звикли до них. Опкоди, такі як SLOAD, SSTORE, BALANCE, CALL і т. д., стануть системними викликами RISC-V.
- У такому світі смарт-контракти можуть бути написані на Rust, але я очікую, що більшість розробників продовжуватимуть писати смарт-контракти на Solidity (або Vyper), які будуть адаптуватися для додавання RISC-V як бекенду. Це тому, що смарт-контракти, написані на Rust, -фактичнодоситьПотворні, і Solidity та Vyper - багатобільшечитабельний. Потенційно, devex змінилося б дуже мало, і розробники могли б мало помітити зміни зовсім.
- Старі контракти EVM будуть продовжувати працювати і будуть повністю двосторонньо сумісні з новими контрактами RISC-V. Є кілька способів зробити це, про що я розповім пізніше у цьому пості.
Один прецедент для цього - Nervos CKB VM, яка в основному RISC-V.
Чому це робити?
На короткий термін основні підтягуючі фактори масштабованості Ethereum L1 вирішуються майбутніми EIP, такими як блокові списки рівня доступу, відкладене виконанняі розподілене зберігання історії плюсEIP-4444. У середньостроковій перспективі ми вирішуємо додаткові питання збездержавність та ZK-EVMs. На довгостроковий період основними обмежуючими факторами масштабування Ethereum L1 стають:
- Стабільність протоколів вибірковості доступності даних та зберігання історії
- Бажання зберегти конкурентний ринок виробництва блоків
- ZK-EVM доказові здатності
Я буду аргументувати, що заміна ZK-EVM на RISC-V вирішує ключове обмеження в (2) та (3).
Це таблиця кількості циклів, яку використовує Succinct ZK-EVM для доведення різних частин шару виконання EVM:
Є чотири частини, які займають значну кількість часу: deserialize_inputs, initialize_witness_db, state_root_computation та block_execution.
ініціалізувати_witness_db та state_root_computation стосуються дерева стану, а deserialize_inputs відноситься до процесу перетворення даних блоку та свідків у внутрішнє представлення; отже, реалістично понад 50% цього пропорційне розмірам свідка.
Ці частини можна значно оптимізувати, замінивши поточне дерево Меркла Патріція з 16-ичною кеккаком на бінарне дерево, яке використовує хеш-функцію, яка підходить для доказування. Якщо ми використовуємо Poseidon, ми можемодовести 2 мільйони хешів на секундуна ноутбуці (порівняно з ~15 000 хеш/сек для keccak). Є також багато інших варіантів, крім Poseidon. В цілому, є можливості масово зменшити ці компоненти. Як бонус, ми можемо позбутися accrue_logs_bloom, ну, позбутися цвіту.
Це залишає блок виконання, який становить приблизно половину циклів перевірки, витрачених сьогодні. Якщо ми хочемо збільшити ефективність загального перевірника в 100 разів, немає обходу факту, що нам потрібно щонайменше 50 разів підвищити ефективність перевірника EVM. Одне з можливих рішень - спробувати створити реалізації EVM, які є набагато ефективнішими з точки зору циклів перевірки. Інше, що ми можемо зробити, - помітити, що сьогодні перевірники ZK-EVM вже працюють, доводячи над реалізаціями EVM, скомпільованими до RISC-V, і надають розробникам смарт-контрактів прямий доступ до цього RISC-V VM.
Деякі цифри свідчать, що в обмежених випадках це може призвести до отримання ефективності більше ніж у 100 разів:
На практиці я очікую, що залиший час доведення стане домінуючим у тому, що сьогодні є попередні компілювання. Якщо ми зробимо RISC-V основним VM, то газовий графік відобразить часи доведення, і тому буде економічний тиск зупинити використання більш дорогих попередніх компілювань; але навіть тоді виграші не будуть настільки вражаючими, але у нас є вагомі підстави вважати, що вони будуть дуже значними.
(До речі, приблизно 50/50 розподіл між "EVM" та "іншими речами" також з'являється в звичайному виконанні EVM, і ми інтуїтивно очікуємо, що вигоди від видалення EVM як «посередника» повинні бути подібно великими
Деталі реалізації
Існує кілька способів реалізації цього виду пропозиції. Найменш руйнівним є підтримка двох ВМ, а також дозвіл на написання контрактів у будь-якому з них. Обидва типи контрактів матимуть доступ до таких самих видів можливостей: постійного сховища (SLOAD і SSTORE), можливості утримувати баланси ETH, можливості здійснювати виклики та отримувати їх, тощо. Контракти EVM та RISC-V зможуть вільно викликати один одного; з точки зору RISC-V, виклик контракту EVM здасться йому системним викликом з деякими спеціальними параметрами; контракт EVM, що отримує повідомлення, інтерпретує його як ВИКЛИК.
Більш радикальний підхід з точки зору протоколу полягає в перетворенні існуючих контрактів EVM у контракти, які викликають контракт інтерпретатора EVM, написаний на RISC-V, який виконує їх існуючий код EVM. Це означає, що якщо у контракта EVM є код C, а інтерпретатор EVM знаходиться за адресою X, то контракт замінюється верхньою логікою, яка, коли викликається ззовні з викликом параметрів D, викликає X з (C, D), а потім очікує значення повернення та пересилає його. Якщо сам інтерпретатор EVM викликає контракт, просячи виконати CALL або SLOAD/SSTORE, тоді контракт це робить.
Проміжний шлях - це зробити другий варіант, але створити явну функцію протоколу для цього - в основному, узаконити концепцію "інтерпретатора віртуальної машини" та вимагати, щоб її логіка була написана на RISC-V. EVM буде першим, але можуть бути й інші (наприклад, Move може бути кандидатом).
Однією з ключових переваг другої та третьої пропозиції є значне спрощення специфікації рівня виконання - дійсно, цей тип ідеї може бути єдиним практичним способом зробити це, враховуючи велику складність навіть інкрементальних спрощень, таких як видалення SELFDESTRUCT. Tinygrad має твердий правило ніколи не перевищуючи 10000 рядків коду; оптимальний базовий рівень блокчейну повинен добре вписуватися в ці межі й навіть ставати ще меншим. Зусилля з розвитку ланцюга променів мають велике обіцяння щодо значного спрощення рівня згоди Ethereum. Але для виконавчого рівня, щоб побачити схожі вигоди, цей радикальний змінений може бути єдиним життєздатним шляхом.
Disclaimer:
- Ця стаття була перепечатана з [ Ethereum Магікі]. Усі авторські права належать оригінальному авторові [Віталік Бутерін]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Гейт Навчаннякоманда, і вони оперативно з цим впораються.
- Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
- Команда Gate Learn перекладає статті на інші мови. Копіювання, поширення або плагіатування перекладених статей заборонено, якщо не зазначено інше.
