Виталик Бутерин снова стоит на переднем крае технологий Ethereum, на этот раз он выдвинул смелую идею, способную поколебать весь уровень выполнения Ethereum: заменить существующую виртуальную машину Ethereum (EVM) на RISC-V. За последние десять лет EVM стал синонимом платформы смарт-контрактов, он является основой работы кода Solidity и Vyper, и является базовым "двигателем", на который полагаются Rollup и архитектуры L2. Однако Виталик считает, что этот "двигатель" постепенно начинает проявлять множество проблем, не соответствующих современным требованиям.
原文：https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
Так почему же RISC-V? Почему именно сейчас? Какое грандиозное видение и технические вызовы стоят за этим?
Во-первых, хотя EVM и стабилен, он уже структурно "устарел". EVM использует 256-битную стековую структуру, которая по сути была разработана для безопасности и определенности блокчейна, однако такая архитектура далеко от способа работы современных ЦП, что делает любую систему, основанную на доказательствах ZK (нулевых знаний), при попытке смоделировать EVM, требующей значительных ресурсов — много ресурсов уходит на доказательство того, что "этот код действительно выполняется как EVM", а не на реальную обработку бизнес-логики.
Таким образом, возникли текущие瓶颈, с которыми сталкивается ZK-EVM: он медленный не потому, что технология ZK сама по себе недостаточно продвинута, а потому что требуется моделировать виртуальную машину, которая не является достаточно простой и трудна для доказательства. И в этих ZK-системах код EVM часто "переводится" в другой формат для обработки — RISC-V.
Предложение Виталика выглядит логичным шагом: "Так как все ZK-системы в конечном итоге должны переводить EVM в RISC-V, почему бы нам не позволить смарт-контрактам работать напрямую на RISC-V?" Это похоже на то, как при наборе текста на пиньине необходимо сначала преобразовать его в иероглифы, пока однажды кто-то не скажет: "Можем ли мы распознавать голосовой ввод напрямую?"
RISC-V — это архитектура набора команд, используемая в реальных ЦП, простая, модульная и с открытым исходным кодом, с современным подходом к дизайну и поддержкой зрелой аппаратной и программной экосистемы. Она естественно подходит для генерации ZK-цепей — в мире ZK доказать правильность одной команды RISC-V гораздо проще, чем доказать правильность одной команды EVM. Виталик, ссылаясь на данные нескольких экспериментальных проектов, считает, что если использовать RISC-V в качестве архитектуры выполнения контрактов, скорость ZK-доказательства может увеличиться в 50-100 раз, что означает сокращение времени на генерацию доказательства блока Ethereum с нескольких минут до нескольких секунд, что будет качественным скачком для Ethereum L1 и всех Rollup.
Конечно, знакомые нам языки Solidity и Vyper все еще могут быть сохранены, просто их целевой язык после компиляции больше не будет байт-кодом EVM, а будет инструкциями RISC-V. Другими словами, для большинства разработчиков это будет почти "безболезненной заменой", и они даже не заметят изменений на нижнем уровне. Виталик также предложил три пути совместимости для решения задач переходного периода:
Существование двух виртуальных машин: EVM и RISC-V существуют одновременно, новые контракты могут выбирать использование RISC-V, старые контракты остаются без изменений. Самый безопасный и совместимый вариант.
Интерпретатор на цепи: запускать EVM как "подсистему" на RISC-V, по сути, моделируя EVM на RISC-V в цепи. Этот способ радикален, но унифицирован.
Механизм плагинов для интерпретаторов: позволяет протоколам поддерживать несколько виртуальных машин (таких как будущая Move VM, WASM и т.д.), RISC-V является опцией по умолчанию, но не исключает другие, обладая расширяемостью.
Технических вызовов, очевидно, тоже немало. Например, модель газа для RISC-V требует переработки; например, как обеспечить определенность выполнения смарт-контрактов без поддержки стандартной библиотеки; и еще, что требуется заново разработать множество инструментов безопасности, отладчиков и рамок аудита — реконструкция экосистемы является значительным проектом.
На уровне сообщества это предложение также вызвало огромные обсуждения. Радикалы считают, что это именно то, как Ethereum должен ответить на конкуренцию новых высокопроизводительных цепей, таких как Solana, Sui и Aptos, и что это необходимый шаг к "поколению Ethereum"; тогда как консерваторы беспокоятся о высокой сложности и стоимости реализации, а также о том, что затраты на миграцию экосистемы трудно оценить, что может вызвать проблемы с совместимостью и разрывом в цепочке инструментов.
Соучредитель Sui Сэм Блэкшир даже публично заявил, что если бы он заново проектировал блокчейн, он бы сразу использовал язык Move, потому что Move более силен в управлении ресурсами и безопасности. Однако он также признал, что для нынешнего Ethereum RISC-V является реалистичной и разумной альтернативой.
Стоит отметить, что Ethereum не собирается использовать RISC-V для "замены решений по масштабированию". Layer 2, EIP-4844, решения по фрагментации данных, решения по смягчению MEV и т.д. будут продолжать развиваться, RISC-V в основном будет улучшением на уровне "замены двигателя", а не прямым методом масштабирования. Но этот новый двигатель, возможно, позволит Ethereum в будущем масштабироваться быстрее, стабильнее и с меньшими усилиями.
Предложение Виталика не является "Ethereum 2.5", которое будет запущено завтра, это скорее долгосрочная стратегическая дорожная карта: в следующие несколько лет, когда инструменты будут готовы, а консенсус сообщества установлен, RISC-V, возможно, постепенно станет настоящим "новым ядром" Ethereum.
В эту эпоху, когда все основатели уже отошли на второй план, и остался только шум рынка, Виталик по-прежнему готов "лично писать предложения", углубляться в технические детали и продвигать архитектурную революцию, которая может открыть сотни раз больше пространства для вычислительной эффективности в блокчейне. Эта преданность и настойчивость являются одной из причин, по которым Ethereum продолжает оставаться на передовой.
Эй, стражи, вы поддерживаете это решение?
\u003ct-42/\u003e \u003cc-44/\u003e