Розробники спростовують Віталіка: припущення помилкові, і RISC-V – не найкращий вибір

Ця стаття взята з: компіляції розробника Ethereum levochka.eth

Odaily Planet Daily (@OdailyChina); @azuma_eth Примітка редактора

:

Вчора співзасновник Ethereum Віталік випустив радикальну статтю про оновлення виконавчого рівня Ethereum (див. "Радикально нова стаття Віталіка: масштабування рівня виконання "не ламається, не стоїть", EVM має бути повторене в майбутньому), згадавши, що він сподівається замінити його на RISC-V EVM як мова віртуальних машин для смарт-контрактів.

Як тільки ця стаття вийшла, вона відразу ж викликала обурення в співтоваристві розробників Ethereum, і багато технічних гігантів висловили різні погляди на план. Незабаром після публікації статті, розробник Tier-1 Ethereum levochka.eth написав велику статтю під оригінальною статтею, в якій спростував аргумент Віталіка про те, що Віталік зробив неправильні припущення про систему доказів та її продуктивність, і що RISC-V може бути не найкращим вибором, оскільки він не може збалансувати «масштабованість» та «ремонтопридатність».

Нижче наводимо оригінальну статтю на levochka.eth, складену щоденною газетою Odaily.

Будь ласка, не робіть цього.

Цей план не має сенсу, тому що ви робите неправильні припущення щодо доведення системи та її продуктивності.

Гіпотеза валідації

Як я розумію, основними аргументами на користь цієї схеми є «масштабованість» і «ремонтопридатність».

Спочатку хочу поговорити про ремонтопридатність.

Фактично, всі RISC-V zk-VM вимагають "прекомпіляції" для виконання операцій, що вимагають інтенсивних обчислень. Попередньо складений список SP 1 можна знайти в документації Sucinct, і ви побачите, що він охоплює майже всі важливі «обчислювальні» коди операцій в EVM.

В результаті, всі модифікації криптографічних примітивів базового рівня вимагають запису та аудиту нових «схем» для цих попередніх компіляцій, що є серйозним обмеженням.

Дійсно, якщо продуктивність досить хороша, може бути відносно легко виконати справність «не-EVM» частини клієнта. Я не впевнений, що він достатньо хороший, але я менш впевнений у цій частині з наступних причин:

• "обчислення дерева станів" дійсно можна значно прискорити за допомогою дружньої попередньої компіляції, як Poseidon.

• Однак неясно, чи можна впоратися з «десеріалізацією» елегантно і ремонтопридатним способом.
  

• Крім того, є деякі складні деталі (такі як вимірювання газу та різні перевірки), які можуть підпадати під «час оцінки блоку», але насправді їх слід класифікувати як деталі «без EVM», які, як правило, більш вразливі до тиску обслуговування.

По-друге, частина про масштабованість.

Я повинен ще раз наголосити, що RISC-V не може впоратися з навантаженнями EVM без використання попередньої компіляції, абсолютно ні.

Отже, твердження в оригінальному тексті про те, що «час остаточного доведення буде домінувати поточною операцією прекомпіляції», є технічно правильним, але воно надмірно оптимістичне - воно припускає, що в майбутньому не буде ніякої попередньої компіляції, коли фактично (в цьому майбутньому сценарії) прекомпіляція все ще буде існувати, і точно така ж, як інтенсивні обчислення коди операцій в EVM (такі як сигнатури, хеші і, можливо, великі аналоги).

Важко судити про приклад Фібоначчі, не вдаючись у найтонші деталі, але переваги принаймні частково проявляються:

• різниця між інтерпретацією та виконанням накладних витрат;

• Циклічне розкручування (зменшення «потоку керування» RISC-V, невідомо, чи може бути реалізована Solidity, але навіть один код операції все одно може генерувати велику кількість доступів до потоку/пам'яті керування через накладні витрати на інтерпретацію);

• використовувати менші типи даних;

Тут я хотів би зазначити, що для реалізації переваг пункту 1 та пункту 2 необхідно усунути «накладні витрати на тлумачення». Це відповідає філософії RISC-V, але це не RISC-V, який ми зараз обговорюємо, а скоріше схожий "(?)RISC-V" - він вимагає певних додаткових можливостей, таких як підтримка контрактних концепцій.

Ось тут і проблема

, отже, тут є деякі проблеми.

• Щоб покращити ремонтопридатність, вам потрібен RISC-V (з попередньою компіляцією), який компілює EVM – майже все.

• Щоб покращити масштабованість, потрібно щось зовсім інше – нова архітектура, яка може бути схожою на RISC-V, яка розуміє концепцію «контрактів», сумісна з обмеженнями часу виконання Ethereum і може виконувати код контракту безпосередньо (без «накладних витрат на інтерпретацію»).

Тепер я припускаю, що ви маєте на увазі другий випадок (оскільки решта статті, здається, має на увазі це). Мені потрібно звернути вашу увагу на те, що весь код за межами цього оточення все одно буде написаний на поточній мові RISC-V zkVM, що має значний вплив на обслуговування.

В якості альтернативи

ми можемо скомпілювати байт-код з високорівневого коду операції EVM. Компілятор відповідає за те, щоб конструктор залишався інваріантним, наприклад, не відчував "переповнення стека". Я б хотів, щоб це було показано в звичайному EVM. Правильно складені СНАРКИ можуть бути забезпечені інструкціями щодо розгортання за контрактом.

Ми також можемо побудувати «формальний доказ», який доводить, що деякі інваріанти зберігаються. Наскільки я можу судити, цей підхід (а не "віртуалізація") використовувався в деяких контекстах браузерів. Генеруючи СНАРКИ цього формального доказу, можна досягти аналогічних результатів. 

Звичайно, найпростіший варіант - вкусити кулю і зробити ......

Побудова мінімального "ланцюгового" MMU

, що ви можете неявно висловити в статті, але дозвольте попередити, що якщо ви хочете усунути накладні витрати на віртуалізацію, вам доведеться виконувати скомпільований код безпосередньо — це означає, що вам потрібно якимось чином запобігти запису контракту (тепер виконуваного) в пам'ять ядра (а не реалізації EVM).

Тому нам потрібен якийсь «блок управління пам'яттю» (MMU). Механізм пейджингового зв'язку традиційних комп'ютерів може не знадобитися, оскільки «фізичний» простір пам'яті майже нескінченний. Цей MMU повинен бути максимально ощадливим (тому що він знаходиться на тому ж рівні абстракції, що і сама архітектура), але деякі особливості, такі як атомарність транзакцій, можна перенести на цей рівень.

На цьому етапі доведений EVM стає програмою ядра, що працює на цій архітектурі.

RISC-V може бути не найкращим варіантом

Цікаво, що у всіх цих умовах найкращою «архітектурою набору інструкцій» (ISA) для цього завдання може бути не RISC-V, а щось схоже на EOF-EVM з наступних причин:

• «Малі» коди операцій насправді призводять до великого доступу до пам'яті, з чим важко ефективно впоратися існуючим методам атестації.

• Щоб зменшити накладні витрати на розгалуження, ми показали, як довести код "статичних стрибків" (EOF) з продуктивністю на рівні прекомпіляції в нашій нещодавній статті Morgana.

Моя пропозиція полягає в тому, щоб створити нову дружню до proof-friendly архітектуру з мінімальним MMU, яка дозволяє контракту працювати як окремий виконуваний файл. Я не думаю, що це має бути RISC-V, а скоріше новий ISA, оптимізований для обмежень протоколу SNARK, і навіть ISA, який частково успадковує підмножину кодів операцій EVM, може бути кращим - як ми знаємо, попередня компіляція тут, щоб залишитися, хочемо ми цього чи ні, тому RISC-V не приносить тут жодних спрощень.