Повний текст довгострокової пропозиції Віталіка щодо виконавчого рівня L1: заміна EVM на RISC-V

Джерело: Віталік Бутерін

Компіляція: KarenZ, Foresight News

20 квітня Віталік Бутерін представив важливу пропозицію на платформі Ethereum Magicians щодо довгострокового рівня виконання L1 Ethereum. Він запропонував замінити існуючу EVM (віртуальну машину Ethereum) на архітектуру RISC-V як мову віртуальних машин для написання смарт-контрактів, маючи на меті докорінно підвищити операційну ефективність виконавчого рівня 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 стануть:

1. Стабільність доступності даних, дискретизації та протоколів зберігання історичних даних

2. Підтримувати попит на конкуренцію на ринку блочного виробництва

3. Доказ ZK-EVM

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

Наступна таблиця ілюструє кількість циклів, необхідних для кожного кроку шару виконання Succinct ZK-EVM Proof EVM:

Опис діаграми: Чотири основні трудомісткі сегменти: deserialize_inputs, initialize_witness_db, state_root_computation і block_execution

initialize_witness_db та state_root_computation пов'язані з деревами станів, і deserialize_inputs включають процес перетворення блокових даних та даних свідків у внутрішні репрезентації – понад 50% з яких фактично пропорційно розміру даних свідків.

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

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

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

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

(Варто зазначити, що час, витрачений на «операції EVM» та «інші операції» при звичайному виконанні EVM, також близький до 50/50, тому ми інтуїтивно припускаємо, що видалення 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 може бути кандидатом).

Основна перевага другого і третього варіантів полягає в тому, що вони значно спрощують специфікацію рівня виконання. З ОГЛЯДУ НА СКЛАДНІСТЬ НАВІТЬ УСУНЕННЯ ПОСТУПОВИХ СПРОЩЕНЬ, ТАКИХ ЯК САМОЗНИЩЕННЯ, ЦЕЙ НАПРЯМ МИСЛЕННЯ МОЖЕ БУТИ ЄДИНИМ ЖИТТЄЗДАТНИМ ШЛЯХОМ ДО СПРОЩЕННЯ. Tinygrad дотримується жорсткого правила «не більше 10 000 рядків коду», і оптимальний блокчейн, що лежить в основі, повинен бути в змозі легко вкластися в цей ліміт і ще більше його впорядкувати. Ініціатива Beam Chain обіцяє значно спростити рівень консенсусу Ethereum, і така радикальна зміна може бути єдиним способом досягти аналогічного приросту на рівні виконання.