Ця стаття від: Ethereum розробник levochka.eth
Компіляція｜Odaily 星球日报（@OdailyChina）；Перекладач｜Azuma（@azuma_eth）
Редакторська примітка:
Вчора співзасновник Ethereum Віталік опублікував радикальну статтю про оновлення виконувального рівня Ethereum (див. «Радикальна нова стаття Віталіка: розширення виконувального рівня “не зламати - не побудувати”, EVM майбутнє має бути ітероване»), в якій йдеться про бажання замінити EVM на RISC-V як мову віртуальної машини для смарт-контрактів.
Як тільки ця стаття вийшла, вона відразу ж викликала обурення в спільноті розробників Ethereum, і багато технічних гігантів висловили різні погляди на план. Незабаром після публікації статті levochka.eth, розробник Ethereum першого рівня, написав довгий пост під оригінальною статтею, спростовуючи аргумент Віталіка про те, що Віталік зробив помилкові припущення про систему доказів та її продуктивність, і що RISC-V може бути не найкращим вибором, оскільки він не може збалансувати «масштабованість» та «ремонтопридатність». **
Наступне - це оригінальний текст levochka.eth, перекладений Odaily 星球日报.
Будь ласка, не робіть цього.
Цей план є нерозумним, оскільки ви зробили помилкові припущення щодо системи доказів та її продуктивності.
Перевірка гіпотези
На мою думку, основні аргументи цього рішення - це “масштабованість” (scalability) та “обслуговуваність” (maintainability).
По-перше, я хочу обговорити підтримуваність.
Фактично, всі RISC-V ZK-VM вимагають «прекомпіляцій» для обробки операцій, що вимагають інтенсивних обчислень. Попередньо складений список SP 1 можна знайти в документації Sucinct, і ви побачите, що він охоплює майже всі важливі «обчислювальні» коди операцій в EVM.
Тому всі зміни до базових криптографічних примітивів повинні супроводжуватися написанням і аудитом нових “провідних схем” для цих попередньо скомпільованих функцій, що є серйозним обмеженням.
Дійсно, якщо продуктивність буде достатньо хорошою, підтримка частини “не EVM” в клієнті виконання може бути відносно легкою. Я не впевнений, чи буде продуктивність достатньо хорошою, але моя впевненість у цій частині досить низька, з таких причин:
- “Обчислення дерева стану” (state tree computation) дійсно може бути значно прискорене за допомогою дружніх попередніх компіляцій (таких як Poseidon).
- Але чи можна елегантно та підтримувано обробляти “десеріалізацію” (deserialization) поки що неясно.
- Крім того, існують деякі складні деталі (такі як вимірювання Gas та різні перевірки), які можуть належати до “часу оцінки блоку”, але насправді їх слід класифікувати як “несправжні EVM” частини, і ці частини, як правило, більше піддаються тиску обслуговування.
По-друге, щодо частини масштабованості.
Я хочу підкреслити один момент, RISC-V не може обробляти навантаження EVM без використання попередньо скомпільованого коду, абсолютно не може.
Таким чином, хоча технічно правильне, твердження про те, що «остаточний час доведення буде домінувати поточною операцією попередньої компіляції» в оригінальному тексті припускає, що в майбутньому не буде ніякої попередньої компіляції, хоча фактично (в цьому майбутньому сценарії) попередня компіляція все ще буде існувати, і є точно такою ж, як і операційні коди з інтенсивними обчисленнями в EVM (такі як сигнатури, хеші і, можливо, великі аналогічні операції).
Щодо прикладу “Фібоначчі” (Fibonacci), важко зробити висновки без глибокого занурення в найглибші деталі, але його переваги частково походять з:
- Різниця між “інтерпретатором” (Interpretation) та “витратами на виконання” (execution overhead);
- Розгортання циклів (зменшення “контрольного потоку” RISC-V, чи зможе Solidity це реалізувати, поки не відомо, але навіть один код операції все ще буде генерувати великий контрольний потік/доступ до пам’яті через витрати на інтерпретацію);
- Використовуйте менші типи даних;
Тут я хочу зазначити, що для досягнення переваг 1 і 2 необхідно усунути «витрати на інтерпретацію» (interpretation overhead). Це відповідає ідеї RISC-V, але це не той RISC-V, про який ми зараз говоримо, а подібний «(? )RISC-V» — він повинен мати певні додаткові можливості, такі як підтримка концепції контрактів.
Питання виникає
Отже, тут є деякі проблеми.
Щоб покращити ремонтопридатність, вам знадобиться RISC-V (з попередньою компіляцією), який може компілювати EVM — це, по суті, статус-кво. **
- Щоб підвищити масштабованість, потрібні зовсім інші речі — нова архітектура, яка може бути схожа на RISC-V, здатна розуміти концепцію “контракту”, сумісна з обмеженнями виконання Ethereum і може безпосередньо виконувати код контракту (без “витрат на інтерпретацію”).
Я зараз припускаю, що ви маєте на увазі другий випадок (оскільки решта статті, здається, натякає на це). Я повинен нагадати вам, що весь код за межами цього середовища все ще буде написаний на поточній мові RISC-V zkVM, що має значний вплив на обслуговування.
Інші можливості
Ми можемо скомпілювати байт-код з високорівневих EVM операційних кодів. Компилятор відповідає за забезпечення збереження інваріантів програми, наприклад, щоб не відбувалося “переповнення стеку” (stack overflow). Я хотів би побачити, як це демонструється в звичайному EVM. Правильно скомпільований SNARK може бути наданий разом з інструкціями для розгортання контрактів.
Ми також можемо побудувати «формальний доказ», який доводить, що деякі інваріанти зберігаються. Наскільки я можу судити, цей підхід (а не «віртуалізація») використовувався в деяких контекстах браузерів. Генеруючи СНАРК цього формального доказу, можна досягти аналогічних результатів.
Звісно, найпростіший вибір - це просто взятися за це…
Побудова мінімального “ланцюгового” MMU
Ви, можливо, приховано висловили це в статті, але дозвольте мені нагадати: якщо ви хочете усунути віртуалізаційні витрати, ви повинні безпосередньо виконувати скомпільований код — це означає, що вам потрібно якимось чином запобігти запису контракту (тепер це виконувана програма) в пам’ять ядра (не EVM реалізація).
Отже, нам потрібен якийсь «модуль керування пам’яттю» (MMU). Традиційний механізм сторінок комп’ютера може бути непотрібним, оскільки «фізичний» простір пам’яті практично безмежний. Цей MMU повинен бути якомога більш компактним (оскільки він знаходиться на тому ж абстрактному рівні, що й архітектура), але деякі функції (такі як «атомарність транзакцій, atomicity of transactions») можуть бути перенесені на цей рівень.
У цей час, доказовий EVM стане ядром програми, що працює в цій архітектурі.
RISC-V можливо не є найкращим вибором
Цікаво, що в усіх цих умовах найкраща “архітектура набору команд” (ISA), яка підходить для цього завдання, може бути не RISC-V, а щось схоже на EOF-EVM, причина в тому, що:
- «Малі» коди операцій насправді призводять до великої кількості звернень до пам’яті, з якими важко ефективно впоратися за допомогою існуючих методів атестації.
- Щоб зменшити витрати на гілку, ми нещодавно в статті Morgana продемонстрували, як на рівні попередньої компіляції довести продуктивність коду з “статичними стрибками” (static jumps, схожими на EOF).
Моя пропозиція полягає в тому, щоб побудувати нову архітектуру, дружню до доказів, оснащену мінімальною MMU, яка дозволить запускати контракти як окремі виконувані файли. Я не вважаю, що це має бути RISC-V, а повинна бути нова ISA, оптимізована спеціально для обмежень протоколу SNARK**, навіть часткове успадкування підмножини опкоду EVM може бути кращим — ** як ми знаємо, незалежно від того, чи хочемо ми цього, попередньо скомпільовані функції завжди будуть існувати, тому RISC-V тут не принесе жодних спрощень.
