У майбутньому плані Ethereum нова пропозиція, ініційована співавтором Ethereum Віталіком Бутеріним, викликала жваве обговорення в спільноті: заміна EVM (Ethereum Virtual Machine) на RISC-V як мови віртуальної машини для смартконтрактів. Цю концепцію порівнюють з "великим оновленням рівня beam chain" для виконавчого шару, яке покликане не лише для масштабування, а й для вирішення основних проблем складності та ефективності поточного виконавчого шару.
Що таке RISC-V? Чому його потрібно замінити на EVM?
Основна ідея пропозиції полягає в тому, щоб замінити EVM, що наразі використовується в смартконтрактах Ethereum, на відкриту, модульну архітектуру набору команд — RISC-V. Така зміна не скасує існуючі інструменти розробника Ethereum та звички розробників, оскільки:
Існуюча система облікових записів, міжконтрактні виклики, способи зберігання та інші основні абстрактні шари залишаються незмінними.
Оригінальні мови Solidity та Vyper можуть бути скомпільовані з використанням RISC-V як бекенду, досвід розробника не зазнає значних змін.
Старі контракти EVM все ще можуть двосторонньо взаємодіяти з новими контрактами RISC-V.
Таким чином, розробникам не потрібно вивчати все заново, але продуктивність та простота основи Ethereum можуть суттєво покращитися.
ZK-EVM є найбільшим вузьким місцем продуктивності
З появою кількох пропозицій щодо розширення в майбутньому (таких як EIP-4444, затримка виконання та клієнт без стану), справжніми обмеженнями розширення можливостей Ethereum L1 будуть:
Стабільність зразків доступності даних та історичного зберігання
Ринкова конкуренція в виробництві блоків
Ефективність доказів ZK-EVM
В даний час у процесі підтвердження блоку ZK-EVM виконання логіки EVM Віртуальної машини займає приблизно 50% ресурсів. Це означає, що якщо можна буде запустити смартконтракти безпосередньо в середовищі RISC-V, є можливість досягти підвищення продуктивності ZK підтвердження в 50 разів або навіть в 100 разів.
Цікаво, що процес перевірки для ZK-EVM сьогодні фактично полягає в компіляції EVM у RISC-V і доведенні цього системою ZK. Тому пряме перетворення RISC-V на нативну віртуальну машину виконавчого рівня Ethereum не тільки логічно, але й економить ресурсоспоживання проміжних перетворень.
Чому RISC-V швидкий? Повна оптимізація від хеш-функцій до структурного дизайну
Наразі основними чотирма статтями витрат ресурсів ZK-EVM є:
десеріалізувати_inputs
ініціалізувати_свідка_базу
стан_root_computation
блок_виконання
Перші три можуть бути значно оптимізовані шляхом використання більш дружніх до користувача хеш-функцій (таких як Poseidon) та двійкових дерев станів. Наприклад, Poseidon може обробляти 2 мільйони хешів на секунду на ноутбуці, що значно перевищує 15 тисяч від Keccak. Якщо ці оптимізації будуть реалізовані, це значно зменшить навантаження на перші 50%.
Але залишок 50% все ще походить з
блок_виконання
Цю частину можна вирішити лише за допомогою більш ефективного дизайну Віртуальної машини, наприклад, RISC-V.
Три способи реалізації, від консервативного до радикального, є вибір.
Віталік запропонував три шляхи реалізації технологій:
– Варіант один: паралельне використання двох віртуальних машин (мінімальний ризик): дозволяє контрактам вибирати між використанням EVM або RISC-V, обидва взаємодоповнюють і ділять ресурси, поєднуючи сумісність і інновації.
– Варіант два: RISC-V упаковка EVM інтерпретатора (радикальне оновлення): усі EVM контракти будуть виконуватися через вбудований в RISC-V EVM інтерпретатор, що дозволить перейти до єдиної підкладкової архітектури.
Варіант 3: Підтримка віртуальної машини інтерпретатора на рівні протоколу (помірний шлях): у протоколі розроблений «модуль віртуальної машини», за замовчуванням реалізовано інтерпретатор EVM на RISC-V, і дозволяє в майбутньому розширитися до інших мов, таких як Move.
Спільною перевагою цих шляхів є: можливість спростити специфікацію виконавчого рівня, підвищити підтримуваність та прозорість верифікації.
Співзасновник компанії Mysten Labs, що розробляє Sui: якби можна було почати знову, він обрав би Move, не розглядаючи багато мов.
Щодо цієї пропозиції, співзасновник компанії Mysten Labs, яка розробляє Sui, Сем Блексір також висловив свою думку. Він заявив: «Я вважаю, що для Ethereum вибір бекенду RISC-V є непоганим рішенням (оскільки це потрібно для підтримки існуючих EVM контрактів). Але якщо б я повинен був розробити новий ланцюг з нуля, я б все ще вибрав Move, а не багатомовну підтримку. Багато переваг Sui походять з використання сильно типізованих об'єктів як спільного абстрактного шару на всій стеку.»
Це відображає історичні фактори «стратегії вибору віртуальної машини» для різних ланцюгів. Ethereum, що розвивався найраніше, на етапі початкового дизайну не міг передбачити безліч майбутніх вимог та розробок, і наразі адаптується до змін, підкреслюючи сумісність та перехідний дизайн; новий публічний ланцюг Sui ж акцентує на інтеграції всього стеку від мови до базового рівня, що дозволяє тісно інтегрувати розробку та безпеку.
Типус Фінанс зростання Kyrie також поділився своїм минулим досвідом розмови з Віталіком на заході EthTaipei. Він згадує: «Тоді я запитав Віталіка: 'Чи вважаєш ти, що мова Move та об'єктно-орієнтоване програмування можуть підвищити безпеку блокчейну?'»
Він відповів: «Я не вважаю, що це щось змінює, проект вкрали, і це не залежить від мови.»
Але Kyrie на місці заперечив, що Move дійсно може зменшити ймовірність помилок під час розробки, він легший у використанні, ніж Rust, а об'єктно-орієнтована модель допомагає обмежити ризики. «Коли контракт викрадають, втрати можуть бути обмеженою сумою, а не безмежним ризиком», - додав він.
Хоча тоді Віталік не висловлювався, але з того, що зараз він готовий запропонувати RISC-V як більш потужну, модульну альтернативу, здається, що його ставлення до проектування мови щодо безпеки блокчейн трохи змінилося.
Ця стаття Ефірна заміна серцевої операції? Віталік пропонує, що виконавчий рівень Ethereum може бути повністю замінений EVM на RISC-V, вперше з'явився в новинах ланцюга ABMedia.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Хірургія серця Ethereum? Віталік пропонує, щоб виконавчий шар Ethereum міг повністю замінити EVM на RISC-V.
У майбутньому плані Ethereum нова пропозиція, ініційована співавтором Ethereum Віталіком Бутеріним, викликала жваве обговорення в спільноті: заміна EVM (Ethereum Virtual Machine) на RISC-V як мови віртуальної машини для смартконтрактів. Цю концепцію порівнюють з "великим оновленням рівня beam chain" для виконавчого шару, яке покликане не лише для масштабування, а й для вирішення основних проблем складності та ефективності поточного виконавчого шару.
Що таке RISC-V? Чому його потрібно замінити на EVM?
Основна ідея пропозиції полягає в тому, щоб замінити EVM, що наразі використовується в смартконтрактах Ethereum, на відкриту, модульну архітектуру набору команд — RISC-V. Така зміна не скасує існуючі інструменти розробника Ethereum та звички розробників, оскільки:
Існуюча система облікових записів, міжконтрактні виклики, способи зберігання та інші основні абстрактні шари залишаються незмінними.
Оригінальні мови Solidity та Vyper можуть бути скомпільовані з використанням RISC-V як бекенду, досвід розробника не зазнає значних змін.
Старі контракти EVM все ще можуть двосторонньо взаємодіяти з новими контрактами RISC-V.
Таким чином, розробникам не потрібно вивчати все заново, але продуктивність та простота основи Ethereum можуть суттєво покращитися.
ZK-EVM є найбільшим вузьким місцем продуктивності
З появою кількох пропозицій щодо розширення в майбутньому (таких як EIP-4444, затримка виконання та клієнт без стану), справжніми обмеженнями розширення можливостей Ethereum L1 будуть:
Стабільність зразків доступності даних та історичного зберігання
Ринкова конкуренція в виробництві блоків
Ефективність доказів ZK-EVM
В даний час у процесі підтвердження блоку ZK-EVM виконання логіки EVM Віртуальної машини займає приблизно 50% ресурсів. Це означає, що якщо можна буде запустити смартконтракти безпосередньо в середовищі RISC-V, є можливість досягти підвищення продуктивності ZK підтвердження в 50 разів або навіть в 100 разів.
Цікаво, що процес перевірки для ZK-EVM сьогодні фактично полягає в компіляції EVM у RISC-V і доведенні цього системою ZK. Тому пряме перетворення RISC-V на нативну віртуальну машину виконавчого рівня Ethereum не тільки логічно, але й економить ресурсоспоживання проміжних перетворень.
Чому RISC-V швидкий? Повна оптимізація від хеш-функцій до структурного дизайну
Наразі основними чотирма статтями витрат ресурсів ZK-EVM є:
десеріалізувати_inputs
ініціалізувати_свідка_базу
стан_root_computation
блок_виконання
Перші три можуть бути значно оптимізовані шляхом використання більш дружніх до користувача хеш-функцій (таких як Poseidon) та двійкових дерев станів. Наприклад, Poseidon може обробляти 2 мільйони хешів на секунду на ноутбуці, що значно перевищує 15 тисяч від Keccak. Якщо ці оптимізації будуть реалізовані, це значно зменшить навантаження на перші 50%.
Але залишок 50% все ще походить з
блок_виконання
Цю частину можна вирішити лише за допомогою більш ефективного дизайну Віртуальної машини, наприклад, RISC-V.
Три способи реалізації, від консервативного до радикального, є вибір.
Віталік запропонував три шляхи реалізації технологій:
– Варіант один: паралельне використання двох віртуальних машин (мінімальний ризик): дозволяє контрактам вибирати між використанням EVM або RISC-V, обидва взаємодоповнюють і ділять ресурси, поєднуючи сумісність і інновації.
– Варіант два: RISC-V упаковка EVM інтерпретатора (радикальне оновлення): усі EVM контракти будуть виконуватися через вбудований в RISC-V EVM інтерпретатор, що дозволить перейти до єдиної підкладкової архітектури.
Варіант 3: Підтримка віртуальної машини інтерпретатора на рівні протоколу (помірний шлях): у протоколі розроблений «модуль віртуальної машини», за замовчуванням реалізовано інтерпретатор EVM на RISC-V, і дозволяє в майбутньому розширитися до інших мов, таких як Move.
Спільною перевагою цих шляхів є: можливість спростити специфікацію виконавчого рівня, підвищити підтримуваність та прозорість верифікації.
Співзасновник компанії Mysten Labs, що розробляє Sui: якби можна було почати знову, він обрав би Move, не розглядаючи багато мов.
Щодо цієї пропозиції, співзасновник компанії Mysten Labs, яка розробляє Sui, Сем Блексір також висловив свою думку. Він заявив: «Я вважаю, що для Ethereum вибір бекенду RISC-V є непоганим рішенням (оскільки це потрібно для підтримки існуючих EVM контрактів). Але якщо б я повинен був розробити новий ланцюг з нуля, я б все ще вибрав Move, а не багатомовну підтримку. Багато переваг Sui походять з використання сильно типізованих об'єктів як спільного абстрактного шару на всій стеку.»
Це відображає історичні фактори «стратегії вибору віртуальної машини» для різних ланцюгів. Ethereum, що розвивався найраніше, на етапі початкового дизайну не міг передбачити безліч майбутніх вимог та розробок, і наразі адаптується до змін, підкреслюючи сумісність та перехідний дизайн; новий публічний ланцюг Sui ж акцентує на інтеграції всього стеку від мови до базового рівня, що дозволяє тісно інтегрувати розробку та безпеку.
Типус Фінанс зростання Kyrie також поділився своїм минулим досвідом розмови з Віталіком на заході EthTaipei. Він згадує: «Тоді я запитав Віталіка: 'Чи вважаєш ти, що мова Move та об'єктно-орієнтоване програмування можуть підвищити безпеку блокчейну?'»
Він відповів: «Я не вважаю, що це щось змінює, проект вкрали, і це не залежить від мови.»
Але Kyrie на місці заперечив, що Move дійсно може зменшити ймовірність помилок під час розробки, він легший у використанні, ніж Rust, а об'єктно-орієнтована модель допомагає обмежити ризики. «Коли контракт викрадають, втрати можуть бути обмеженою сумою, а не безмежним ризиком», - додав він.
Хоча тоді Віталік не висловлювався, але з того, що зараз він готовий запропонувати RISC-V як більш потужну, модульну альтернативу, здається, що його ставлення до проектування мови щодо безпеки блокчейн трохи змінилося.
Ця стаття Ефірна заміна серцевої операції? Віталік пропонує, що виконавчий рівень Ethereum може бути повністю замінений EVM на RISC-V, вперше з'явився в новинах ланцюга ABMedia.