Эфир переживает самые важные архитектурные изменения с момента своего создания: замена Эфирной виртуальной машины (EVM) на RISC-V. Основной причиной этого изменения является то, что в эпоху доказательства с нулевым знанием (ZK) EVM стала самым большим узким местом:
Текущий zkEVM зависит от выполнения интерпретатора, что приводит к снижению скорости на 50–800 раз;
Предварительно скомпилированные контракты (Precompiles) делают протокол слишком сложным и увеличивают риски;
Эффективность дизайна стека на 256 бит в доказательстве крайне низка.
Уже стал де-факто стандартом zkVM (90% проектов используют);
Формализованная спецификация SAIL (по сравнению с неопределенной желтой книгой) может поддерживать строгую верификацию;
Доказательство аппаратного обеспечения (ASIC/FPGA) находится на стадии тестирования (SP1, Nervos, Cartesi).
Миграция делится на три этапа:
RISC-V как замена для предварительно скомпилированных контрактов (тестирование с низким риском);
Эра двойных виртуальных машин: EVM + RISC-V обладают полной взаимозаменяемостью;
EVM повторно реализован внутри RISC-V (аналогично стратегии Rosetta).
Воздействие на экосистему:
Оптимистичные Rollup'ы не затрагиваются; основная сеть RISC-V не отменит доказательства мошенничества, существующие программы доказательства могут быть скомпилированы для RISC-V (в настоящее время основаны на MIPS); путь миграции: расширить существующую инфраструктуру защиты от ошибок до целевого RISC-V, а не полностью перестраивать;
Разработчики могут напрямую использовать библиотеки Rust/Go/Python на L1;
Пользователи могут получить доказательства стоимости примерно в 100 раз дешевле, тем самым продвигаясь к уровню Gigagas (примерно 10k TPS) L1.
В конечном итоге Ethereum эволюционирует из «виртуальной машины смарт-контрактов» в минимальный, проверяемый уровень доверия в Интернете, с конечной целью: «всё должно быть ZK-Snark».}
Эфириум находится на перепутье
С конечной целью «всё должно быть ZK-Snark» в качестве видения, Ethereum сейчас находится на пороге самого важного архитектурного эволюционного шага с момента его создания. Эта дискуссия больше не ограничивается постепенными обновлениями, а представляет собой фундаментальную реконструкцию его вычислительного ядра — замену виртуальной машины Ethereum (EVM). Эта инициатива является основой более широкой концепции «Упрощённого Ethereum» (Lean Ethereum), направленной на систематическое упрощение всего протокола, разделив его на три ключевых компонента: упрощённый консенсус (Lean Consensus), упрощённые данные (Lean Data) и упрощённое выполнение (Lean Execution). А основной вопрос упрощённого выполнения заключается в следующем: стала ли EVM, как двигатель революции смарт-контрактов, основным узким местом будущего развития Ethereum?
Как сказал Джастин Дрейк из Фонда Эфириума, долгосрочной целью Эфириума всегда было «превращение всего в Snark», что является мощным инструментом, способным улучшить различные уровни протокола. Однако долгое время эта цель больше походила на «воздушный замок», поскольку для её достижения требовалось доказательство концепции в реальном времени. Сегодня, когда доказательства в реальном времени постепенно становятся реальностью, теоретическая неэффективность EVM превратилась в актуальную проблему, требующую решения.
Анализ будет исследовать технические и стратегические аргументы миграции Ethereum L1 на архитектуру команд RISC-V (ISA), что, как ожидается, обеспечит беспрецедентную масштабируемость, упростит структуру протокола и согласует Ethereum с будущим верифицируемых вычислений.
Что именно изменилось?
Прежде чем углубляться в обсуждение «почему», необходимо сначала понять, «что» именно меняется.
EVM — это среда выполнения смарт-контрактов Ethereum, являющаяся «мировым компьютером», который обрабатывает транзакции и обновляет состояние блокчейна. На протяжении многих лет его дизайн был революционным, создав безразрешительную платформу и дав начало целой экосистеме DeFi и NFT. Однако эта кастомная архитектура, разработанная почти десять лет назад, сегодня накопила значительный технический долг.
В отличие от этого, RISC-V не является продуктом, а представляет собой открытый стандарт — бесплатный, универсальный «алфавит» проектирования процессоров. Как подчеркнул Джереми Брустл на телефонной конференции Ethproofs, его ключевые принципы делают его единственным выбором для этой роли:
Минимализм: базовый набор команд исключительно прост, он содержит всего около 40-47 команд. Джереми описывает его как «почти идеальный случай использования для нашего необходимого сверхупрощенного универсального компьютера».
Модульность: добавление более сложных функций через опциональные расширения. Это крайне важно, так как позволяет иметь простой основной функционал и по мере необходимости расширять его, не навязывая ненужную сложность базовому протоколу;
Открытая экосистема: она обладает обширной и зрелой поддержкой инструментов, включая компилятор LLVM, который позволяет разработчикам использовать такие популярные языки, как Rust, C++ и Go. Как сказал Джастин Дрейк: «Существует множество инструментов, связанных с компиляторами, и создание компилятора чрезвычайно сложно... Поэтому наличие этих инструментов компилятора имеет большую ценность.» RISC-V позволяет Ethereum бесплатно наследовать эти готовые инструменты.
Проблема накладных расходов интерпретатора
Необходимость замены EVM не является результатом единственного недостатка, а возникает из ряда фундаментальных ограничений, которые в контексте нативного будущего доказательства с нулевым разглашением (ZK) стали невозможными для игнорирования. Эти проблемы охватывают серьезные узкие места в системе доказательства ZK, а также риски, связанные с нарастающей сложностью внутри протокола.
Проблема накладных расходов интерпретатора
Основным движущим фактором этой трансформации является врожденная неэффективность EVM в системах с нулевым разглашением. Поскольку Ethereum постепенно переходит к модели проверки состояния L1 через ZK-доказательства, производительность доказателей станет окончательным узким местом.
Проблема заключается в текущем принципе работы zkEVM. Они не предоставляют нулевое знание о EVM напрямую, а вместо этого доказывают работу интерпретатора EVM, который сам по себе компилируется в RISC-V. Виталик Бутерин остро указал на эту основную проблему:
«Если реализация zkVM заключается в том, чтобы компилировать выполнение EVM в код, который в конечном итоге становится кодом RISC-V, почему бы не открыть разработчикам смарт-контрактов доступ к низкоуровневому RISC-V? Это полностью устранило бы затраты на внешнюю виртуальную машину.»
Этот дополнительный уровень объяснения приводит к огромной потере производительности. По оценкам, этот уровень может привести к снижению производительности на 50 до 800 раз по сравнению с доказательством нативной программы. Даже после оптимизации других узких мест (например, за счет перехода на алгоритм хеширования Poseidon), эта часть «выполнения блока» будет по-прежнему занимать 80–90% времени доказательства, что делает EVM конечным и самым упорным препятствием для масштабирования L1. Если убрать этот уровень, Виталик предсказывает, что эффективность выполнения может увеличиться в 100 раз.
Долговая ловушка предкомпилированного контракта
Чтобы решить проблему недостаточной производительности EVM в определенных криптографических операциях, Ethereum внедрил предкомпилированные контракты — специализированные функции, закодированные непосредственно в протоколе. Хотя это было прагматичным решением в то время, сегодня это вызвало «катастрофическую» ситуацию, о которой говорил Виталик Бутерин:
«Предварительная компиляция для нас является катастрофической... они значительно увеличили надежную кодовую базу Ethereum... и на грани провала консенсуса они несколько раз ставили нас на грань краха.»
Его сложность поражает. Виталик, сравнивая обертку кода для одного предварительно скомпилированного контракта (modexp) и полный интерпретатор RISC-V, указал: логика предварительной компиляции на самом деле более сложна. Новая предварительная компиляция должна пройти медленный и полный политических игр процесс жесткого форка, что серьезно препятствует инновациям в приложениях, зависящих от новых криптографических примитивов.
Таким образом, Виталик пришел к твердому выводу: «Я на самом деле считаю, что мы должны немедленно прекратить добавлять любые предварительно скомпилированные контракты.»
Технический долг архитектуры Эфириума
Ядро дизайна EVM отражает устаревшие требования эпохи, но оно больше не подходит для современных вычислений. EVM выбрала 256-битную архитектуру для обработки криптографических значений, что делает эту архитектуру очень неэффективной для 32-битных или 64-битных целых чисел, обычно используемых в смарт-контрактах. Эта низкая эффективность особенно дорого обходится в системах с нулевым разглашением.
Как объяснил Виталик: «Когда используются меньшие числа, каждое число на самом деле не экономит никаких ресурсов, а сложность увеличивается в 2-4 раза.»
Кроме того, стековая архитектура EVM менее эффективна, чем регистровая архитектура RISC-V и современных ЦП. Ей требуется больше инструкций для выполнения той же операции, что также усложняет оптимизацию компилятора.
Эти комплексные факторы, включая узкие места производительности ZK-доказательств, сложность предкомпиляций и устаревшие архитектурные решения, вместе создают убедительную и неотложную причину для того, чтобы Ethereum преодолел EVM.
RISC-V чертеж: создание более прочной основы
Преимущества RISC-V не только связаны с недостатками EVM, но и с его философией дизайна и врожденными внутренними преимуществами. Его архитектура предлагает надежную, простую и проверяемую основу, что делает ее очень подходящей для таких высокорисковых сред, как Ethereum.
Почему открытые стандарты лучше, чем индивидуальный дизайн
В отличие от настраиваемых архитектур команд (ISA), которые требуют создания всей программной экосистемы с нуля, RISC-V является зрелым открытым стандартом, который предлагает три ключевых преимущества:
Зрелая экосистема
Используя RISC-V, Ethereum в полной мере воспользовался коллективным прогрессом в области компьютерных наук за десятилетия. Как объяснил Джастин Дрейк, это предоставляет Ethereum возможность напрямую использовать инструменты мирового класса: «Существует компонент инфраструктуры, называемый LLVM, который представляет собой набор инструментов компилятора, позволяющий разработчикам компилировать высокоуровневые языки программирования на различные бэкенды. RISC-V является одним из поддерживаемых бэкендов. Так что если вы поддерживаете RISC-V, вы автоматически поддерживаете все высокоуровневые языки, поддерживаемые LLVM.»
Это значительно снизило барьер для входа для миллионов разработчиков, знакомых с такими языками, как Rust, C и Go.
Философия дизайна минимализма
Минимализм RISC-V — это намеренная особенность, а не ограничение. Его базовый набор инструкций содержит всего около 47 инструкций, что делает ядро виртуальной машины исключительно простым. Эта простота является огромным преимуществом с точки зрения безопасности, поскольку меньшая доверенная кодовая база легче поддается аудиту и формальной верификации.
Фактический стандарт в области ZK
Более того, экосистема zkVM уже сделала самостоятельный выбор. Как подчеркивает Джастин Дрейк, из данных Ethproofs можно увидеть четкую тенденцию: «RISC-V является ведущей ISA для бэкенда zkVM.»
Из 10 zkVM, способных подтверждать блоки Ethereum, 9 выбрали RISC-V в качестве целевой архитектуры. Эта рыночная конвергенция посылает мощный сигнал: использование RISC-V в Ethereum не является спекулятивной попыткой, а следует проверенному рынком стандарту.
Создано для доверия, а не только для выполнения
Помимо экосистемы, внутренняя архитектура RISC-V также особенно подходит для построения безопасных и проверяемых систем.
Во-первых, у RISC-V есть официальная, читаемая машиной спецификация, называемая SAIL. Это значительно улучшает спецификацию виртуальной машины Ethereum (EVM), которая в основном существует в виде документации (желтой книги) и может быть неоднозначной. Спецификация SAIL обеспечивает «золотой стандарт», который может предоставить математические доказательства, критически важные для правильности протокола, что жизненно важно для защиты ценного протокола. Как отметил Алекс Хикс из Фонда Ethereum (EF) на телефонной конференции Ethproofs, это позволяет схемам zkVM непосредственно «проверять в соответствии с официальной спецификацией RISC-V».
Во-вторых, RISC-V включает привилегированную архитектуру, которая часто игнорируется, но имеет решающее значение для безопасности. Она определяет различные уровни операций, включая пользовательский режим (для ненадежных приложений, таких как смарт-контракты) и режим контроля (для надежного «исполнительного ядра»).
В модели RISC-V смарт-контракты, работающие в пользовательском режиме, не могут напрямую получать доступ к состоянию блокчейна. Вместо этого они должны отправлять запросы к доверенному ядру, работающему в режиме управления, через специальную инструкцию ECALL (вызов окружения). Эта механика создает безопасную границу, принудительно реализуемую аппаратным обеспечением, которая более надежна и проще верифицируется, чем чисто программная модель песочницы EVM.
Видение Виталика
Этот переход задуман как последовательный и многоступенчатый процесс, чтобы обеспечить стабильность системы и обратную совместимость. Метод, описанный Виталиком Бутериным, направлен на достижение постепенного развития, а не революционных изменений.
Шаг первый: предпросмотр замены
На начальном этапе следует принять наиболее консервативный подход, введя ограниченные функции новой виртуальной машины (VM). Как предложил Виталик, «мы можем начать с ограниченных сценариев использования новой виртуальной машины, например, заменив предварительно скомпилированные функции». Это будет включать приостановку новых функций EVM, заменив их реализацией необходимых функций с помощью программ RISC-V, одобренных через белый список. Такой подход позволяет новой виртуальной машине тестироваться в реальных условиях в основной сети при низком уровне риска, при этом клиент Ethereum будет выступать в качестве посредника между двумя средами выполнения.
Шаг второй: Сосуществование двух виртуальных машин
Следующий этап — «прямой доступ новых виртуальных машин для пользователей». При развертывании смарт-контрактов можно будет добавить флаг, указывающий, является ли его байт-код EVM или RISC-V. Ключевая особенность — обеспечение бесшовной совместимости: «два типа контрактов смогут вызывать друг друга». Это будет реализовано через системные вызовы (ECALL), а клиент Ethereum будет служить посредником для среды выполнения.
Шаг третий: EVM как симуляционный контракт (стратегия «Rosetta»)
Конечной целью является достижение окончательной упрощённости протокола. На этом этапе «мы реализуем EVM как одну из реализаций новой виртуальной машины». Стандартный EVM станет формально проверяемым смарт-контрактом, работающим на нативном RISC-V L1. Это не только обеспечит постоянную поддержку устаревших приложений, но и позволит разработчикам клиентов поддерживать только один упрощённый движок исполнения.
Цепная реакция всей экосистемы
План перехода от EVM к RISC-V далеко не ограничивается основным протоколом; он окажет глубокое влияние на всю экосистему Ethereum, с потенциалом изменить опыт разработчиков, коренным образом изменить конкурентную среду решений уровня 2 и открыть новые модели экономического доказательства.
Перестройка структуры Rollup: разделение путей Optimistic и ZK
Переход на уровень L1 с исполняемым слоем RISC-V окажет совершенно различное влияние на два основных типа Rollups.
Безопасная модель Optimistic Rollups (таких как Arbitrum и Optimism) зависит от повторного выполнения спорных транзакций на Layer-1 для решения проблем с мошенничеством. Даже если Ethereum Layer-1 перейдет на RISC-V, эти системы не претерпят фундаментальных изменений. Как объяснил один из соучредителей Optimism: «Если мы перейдем на RISC-V, цепи Optimistic также не будут прерваны. Вам просто нужно скомпилировать виртуальную машину RISC-V в программу доказательства. И не нужно использовать Asterisc. Существующие системы доказательства на основе MIPS также не будут прерваны — вам просто нужно скомпилировать виртуальную машину RISC-V в MIPS.»
Это означает, что модель защиты от мошенничества по-прежнему цела. Корректировка является технической: необходимо скомпилировать новую виртуальную машину RISC-V в существующую инфраструктуру, а не redesign системы с нуля. Остается вызовом инженерные детали, такие как измерение газа, эффективность и стоимость.
В сравнении, ZK Rollups получат огромное стратегическое преимущество. Подавляющее большинство ZK Rollups уже использует RISC-V в качестве своей внутренней ISA. Использование одного и того же родного языка L1 может обеспечить более тесную и эффективную интеграцию. Джастин Дрейк описал будущее «родных Rollups», в котором L2 по сути является специализированным экземпляром среды выполнения самого L1, обеспечивая бесшовный расчет с помощью встроенной L1 VM. Эта интеграция приведет к следующим изменениям:
Упрощенный технологический стек: устранение сложного мостового соединения между внутренним исполнением RISC-V на L2 и EVM;
Реализация инструментов и повторного использования кода: компиляторы, отладчики и инструменты формальной верификации, разработанные для среды L1 RISC-V, могут быть использованы L2 напрямую, чтобы снизить затраты на разработку.
Координация экономических стимулов: Комиссии за газ уровня L1 будут более точно отражать фактические затраты на выполнение ZK-доказательства RISC-V, что позволит создать более разумную экономическую модель.
Новая эпоха для разработчиков и пользователей
Для разработчиков экосистемы Ethereum это изменение будет постепенным, а не разрушительным.
Для разработчиков ключевое преимущество заключается в том, что они могут войти в более широкий и зрелый мир разработки программного обеспечения. Как отметил Виталик Бутерин, разработчики «сможет писать контракты на Rust, и эти два языка начнут сосуществовать». В то же время он прогнозирует, что «Solidity и Vyper будут популярны еще долгое время», поскольку у них есть элегантно спроектированная логика смарт-контрактов. Возможность использовать основные языки и их богатые библиотеки через инструментальную цепочку LLVM станет революционной. Виталик описывает это как «опыт, похожий на Node.JS», в котором разработчики в основном могут использовать один и тот же язык для написания кода на цепочке и вне цепи.
Для пользователей конечная выгода заключается в более экономичной и мощной сети. Ожидается, что стоимость подтверждения снизится примерно в 100 раз — с нескольких долларов за транзакцию до нескольких центов — что напрямую приведет к более низким расходам на расчеты на уровне Layer-1 и Layer-2. Эта экономическая целесообразность откроет видение «Gigagas L1», цель которого — достичь производительности около 10000 TPS на уровне L1, тем самым поддерживая более сложные и высокоценные приложения на блокчейне в будущем.
Succinct Labs и SP1: доказательство того, что будущее уже здесь
Теоретические преимущества RISC-V были реализованы такими командами, как Succinct Labs, чьи результаты стали мощным кейс-исследованием для всего предложения.
SP1, разработанный Succinct Labs, является высокопроизводимым, открытым zkVM, построенным на основе RISC-V, который проверяет жизнеспособность нового архитектурного подхода. Он использует концепцию "предварительно скомпилированного централизованного" дизайна, что идеально решает проблему криптографической узкой места EVM. В отличие от традиционных подходов, полагающихся на медленные, жестко закодированные предварительно скомпилированные методы, SP1 разгружает такие ресурсоемкие операции, как хеширование Keccak, на специально разработанные и вручную оптимизированные ZK-цепи, вызываемые через стандартные инструкции ECALL. Это обеспечивает как производительность индивидуального оборудования, так и гибкость программного обеспечения.
Практическое влияние команды стало очевидным, их продукт OP Succinct использует SP1 для реализации «ZK-изации» Optimistic Rollup. Как объяснила соучредитель Succinct Ума Рой:
«Ваш OP Stack Rollup больше не нужно ждать 7 дней для окончательного подтверждения и вывода... теперь это занимает всего 1 час. Это значительно ускоряет окончательное подтверждение, просто потрясающе.»
Это решает ключевую проблему всей экосистемы OP Stack. Кроме того, инфраструктура Succinct, «Succinct Prover Network», была разработана как децентрализованный рынок генерации доказательств, демонстрируя жизнеспособную экономическую модель для будущего проверяемых вычислений. Их работа - это не только проверка концепции, но и жизнеспособный план будущего, описанный в данной статье.
Как Ethereum снижает риски
Ключевое преимущество RISC-V заключается в том, что он делает конечной целью формальной верификации — математическое доказательство корректности системы — достижимой целью. Спецификация EVM написана на естественном языке в желтой книге (Yellow Paper) и имеет крайне высокую степень сложности для формализации. В то время как RISC-V имеет официальную, машинно-читаемую спецификацию SAIL, которая предоставляет четкое "золотое эталонное" поведение.
Это открывает ясный путь к более высокой безопасности. Как отметил Алекс Хикс из фонда Ethereum, в настоящее время ведется работа по «извлечению zkVM RISC-V схемы и официальной RISC-V спецификации в Lean для формальной проверки». Это знаковый прогресс, который переносит доверие от подверженной ошибкам человеческой реализации к可验证ным математическим доказательствам, обеспечивая прорыв в области безопасности.
Основные риски трансформации
Несмотря на множество преимуществ архитектуры RISC-V L1, она также столкнется с новыми сложными вызовами.
Проблема учета Gas: создание детерминированной и справедливой модели Gas для универсального ISA является одной из самых сложных задач. Простые методы подсчета инструкций подвержены угрозе атак отказа в обслуживании. Например, злоумышленник может разработать программу, которая многократно вызывает кэшированную программу, тем самым достигая высокой загрузки ресурсов при очень низких затратах на Gas.
Безопасность цепочки инструментов и проблемы «воспроизводимой сборки»: это, возможно, самый важный и недооцененный риск в процессе трансформации. Модель безопасности переходит от виртуальных машин доверенной цепи к доверению каждому разработчику, использующему компиляторы вне цепи (например, LLVM), которые являются крайне сложными и известны тем, что содержат уязвимости. Злоумышленники могут воспользоваться уязвимостями компилятора, чтобы преобразовать на вид безобидный исходный код в злонамеренный байт-код. Кроме того, обеспечить полное соответствие байт-кода после компиляции в цепи и определенному публичному исходному коду, т.е. проблему «воспроизводимой сборки», также крайне сложно, поскольку незначительные различия в среде сборки могут привести к созданию различных бинарных файлов.
Стратегия смягчения
Дорога вперед требует многоуровневой стратегии защиты.
Поэтапный запуск: постепенный и многоступенчатый план перехода является основной стратегией снижения рисков. Введя RISC-V сначала в качестве предварительно скомпилированного альтернативного решения, а затем развернув его в среде с двумя виртуальными машинами, сообщество сможет накопить операционный опыт и уверенность в условиях низкого риска, прежде чем произойдут какие-либо необратимые изменения.
Полный аудит: фузз-тестирование и формальная верификация. Хотя формальная верификация является конечной целью, она должна сопровождаться постоянным и интенсивным тестированием. Как показал Валентин из Diligence Security на конференции Ethproofs, их фузз-тестировщик Argus уже выявил 11 ключевых уязвимостей целостности и корректности в ведущем zkVM. Это доказывает, что даже в самых тщательно спроектированных системах есть уязвимости, которые можно выявить только с помощью строгого противостоящего тестирования.
Стандартизация: Чтобы избежать фрагментации экосистемы, сообществу необходимо единогласно принять единую, стандартизированную конфигурацию RISC-V. Это, вероятно, будет комбинация ABI RV64 GC и совместимого с Linux, так как эта комбинация может обеспечить наибольшую поддержку со стороны современных языков и инструментов, что позволит максимально использовать преимущества новой экосистемы.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Технический долг накапливается, как Ethereum может восстановить архитектуру технологий с помощью RISC-V и найти путь к решению проблемы?
Автор: jaehaerys.eth
Перевод: Глендон, Techub News
Кратко говоря
Эфир переживает самые важные архитектурные изменения с момента своего создания: замена Эфирной виртуальной машины (EVM) на RISC-V. Основной причиной этого изменения является то, что в эпоху доказательства с нулевым знанием (ZK) EVM стала самым большим узким местом:
Текущий zkEVM зависит от выполнения интерпретатора, что приводит к снижению скорости на 50–800 раз;
Предварительно скомпилированные контракты (Precompiles) делают протокол слишком сложным и увеличивают риски;
Эффективность дизайна стека на 256 бит в доказательстве крайне низка.
RISC-V может решить эти проблемы:
Минимализм (примерно 47 основных команд) + зрелая экосистема LLVM (поддержка Rust, C++, Go);
Уже стал де-факто стандартом zkVM (90% проектов используют);
Формализованная спецификация SAIL (по сравнению с неопределенной желтой книгой) может поддерживать строгую верификацию;
Доказательство аппаратного обеспечения (ASIC/FPGA) находится на стадии тестирования (SP1, Nervos, Cartesi).
Миграция делится на три этапа:
RISC-V как замена для предварительно скомпилированных контрактов (тестирование с низким риском);
Эра двойных виртуальных машин: EVM + RISC-V обладают полной взаимозаменяемостью;
EVM повторно реализован внутри RISC-V (аналогично стратегии Rosetta).
Воздействие на экосистему:
Оптимистичные Rollup'ы не затрагиваются; основная сеть RISC-V не отменит доказательства мошенничества, существующие программы доказательства могут быть скомпилированы для RISC-V (в настоящее время основаны на MIPS); путь миграции: расширить существующую инфраструктуру защиты от ошибок до целевого RISC-V, а не полностью перестраивать;
ZK Rollup значительно выиграет (Polygon, zkSync, Scroll → дешевле, быстрее, проще);
Разработчики могут напрямую использовать библиотеки Rust/Go/Python на L1;
Пользователи могут получить доказательства стоимости примерно в 100 раз дешевле, тем самым продвигаясь к уровню Gigagas (примерно 10k TPS) L1.
В конечном итоге Ethereum эволюционирует из «виртуальной машины смарт-контрактов» в минимальный, проверяемый уровень доверия в Интернете, с конечной целью: «всё должно быть ZK-Snark».}
Эфириум находится на перепутье
С конечной целью «всё должно быть ZK-Snark» в качестве видения, Ethereum сейчас находится на пороге самого важного архитектурного эволюционного шага с момента его создания. Эта дискуссия больше не ограничивается постепенными обновлениями, а представляет собой фундаментальную реконструкцию его вычислительного ядра — замену виртуальной машины Ethereum (EVM). Эта инициатива является основой более широкой концепции «Упрощённого Ethereum» (Lean Ethereum), направленной на систематическое упрощение всего протокола, разделив его на три ключевых компонента: упрощённый консенсус (Lean Consensus), упрощённые данные (Lean Data) и упрощённое выполнение (Lean Execution). А основной вопрос упрощённого выполнения заключается в следующем: стала ли EVM, как двигатель революции смарт-контрактов, основным узким местом будущего развития Ethereum?
Как сказал Джастин Дрейк из Фонда Эфириума, долгосрочной целью Эфириума всегда было «превращение всего в Snark», что является мощным инструментом, способным улучшить различные уровни протокола. Однако долгое время эта цель больше походила на «воздушный замок», поскольку для её достижения требовалось доказательство концепции в реальном времени. Сегодня, когда доказательства в реальном времени постепенно становятся реальностью, теоретическая неэффективность EVM превратилась в актуальную проблему, требующую решения.
Анализ будет исследовать технические и стратегические аргументы миграции Ethereum L1 на архитектуру команд RISC-V (ISA), что, как ожидается, обеспечит беспрецедентную масштабируемость, упростит структуру протокола и согласует Ethereum с будущим верифицируемых вычислений.
Что именно изменилось?
Прежде чем углубляться в обсуждение «почему», необходимо сначала понять, «что» именно меняется.
EVM — это среда выполнения смарт-контрактов Ethereum, являющаяся «мировым компьютером», который обрабатывает транзакции и обновляет состояние блокчейна. На протяжении многих лет его дизайн был революционным, создав безразрешительную платформу и дав начало целой экосистеме DeFi и NFT. Однако эта кастомная архитектура, разработанная почти десять лет назад, сегодня накопила значительный технический долг.
В отличие от этого, RISC-V не является продуктом, а представляет собой открытый стандарт — бесплатный, универсальный «алфавит» проектирования процессоров. Как подчеркнул Джереми Брустл на телефонной конференции Ethproofs, его ключевые принципы делают его единственным выбором для этой роли:
Минимализм: базовый набор команд исключительно прост, он содержит всего около 40-47 команд. Джереми описывает его как «почти идеальный случай использования для нашего необходимого сверхупрощенного универсального компьютера».
Модульность: добавление более сложных функций через опциональные расширения. Это крайне важно, так как позволяет иметь простой основной функционал и по мере необходимости расширять его, не навязывая ненужную сложность базовому протоколу;
Открытая экосистема: она обладает обширной и зрелой поддержкой инструментов, включая компилятор LLVM, который позволяет разработчикам использовать такие популярные языки, как Rust, C++ и Go. Как сказал Джастин Дрейк: «Существует множество инструментов, связанных с компиляторами, и создание компилятора чрезвычайно сложно... Поэтому наличие этих инструментов компилятора имеет большую ценность.» RISC-V позволяет Ethereum бесплатно наследовать эти готовые инструменты.
Проблема накладных расходов интерпретатора
Необходимость замены EVM не является результатом единственного недостатка, а возникает из ряда фундаментальных ограничений, которые в контексте нативного будущего доказательства с нулевым разглашением (ZK) стали невозможными для игнорирования. Эти проблемы охватывают серьезные узкие места в системе доказательства ZK, а также риски, связанные с нарастающей сложностью внутри протокола.
Проблема накладных расходов интерпретатора
Основным движущим фактором этой трансформации является врожденная неэффективность EVM в системах с нулевым разглашением. Поскольку Ethereum постепенно переходит к модели проверки состояния L1 через ZK-доказательства, производительность доказателей станет окончательным узким местом.
Проблема заключается в текущем принципе работы zkEVM. Они не предоставляют нулевое знание о EVM напрямую, а вместо этого доказывают работу интерпретатора EVM, который сам по себе компилируется в RISC-V. Виталик Бутерин остро указал на эту основную проблему:
«Если реализация zkVM заключается в том, чтобы компилировать выполнение EVM в код, который в конечном итоге становится кодом RISC-V, почему бы не открыть разработчикам смарт-контрактов доступ к низкоуровневому RISC-V? Это полностью устранило бы затраты на внешнюю виртуальную машину.»
Этот дополнительный уровень объяснения приводит к огромной потере производительности. По оценкам, этот уровень может привести к снижению производительности на 50 до 800 раз по сравнению с доказательством нативной программы. Даже после оптимизации других узких мест (например, за счет перехода на алгоритм хеширования Poseidon), эта часть «выполнения блока» будет по-прежнему занимать 80–90% времени доказательства, что делает EVM конечным и самым упорным препятствием для масштабирования L1. Если убрать этот уровень, Виталик предсказывает, что эффективность выполнения может увеличиться в 100 раз.
Долговая ловушка предкомпилированного контракта
Чтобы решить проблему недостаточной производительности EVM в определенных криптографических операциях, Ethereum внедрил предкомпилированные контракты — специализированные функции, закодированные непосредственно в протоколе. Хотя это было прагматичным решением в то время, сегодня это вызвало «катастрофическую» ситуацию, о которой говорил Виталик Бутерин:
«Предварительная компиляция для нас является катастрофической... они значительно увеличили надежную кодовую базу Ethereum... и на грани провала консенсуса они несколько раз ставили нас на грань краха.»
Его сложность поражает. Виталик, сравнивая обертку кода для одного предварительно скомпилированного контракта (modexp) и полный интерпретатор RISC-V, указал: логика предварительной компиляции на самом деле более сложна. Новая предварительная компиляция должна пройти медленный и полный политических игр процесс жесткого форка, что серьезно препятствует инновациям в приложениях, зависящих от новых криптографических примитивов.
Таким образом, Виталик пришел к твердому выводу: «Я на самом деле считаю, что мы должны немедленно прекратить добавлять любые предварительно скомпилированные контракты.»
Технический долг архитектуры Эфириума
Ядро дизайна EVM отражает устаревшие требования эпохи, но оно больше не подходит для современных вычислений. EVM выбрала 256-битную архитектуру для обработки криптографических значений, что делает эту архитектуру очень неэффективной для 32-битных или 64-битных целых чисел, обычно используемых в смарт-контрактах. Эта низкая эффективность особенно дорого обходится в системах с нулевым разглашением.
Как объяснил Виталик: «Когда используются меньшие числа, каждое число на самом деле не экономит никаких ресурсов, а сложность увеличивается в 2-4 раза.»
Кроме того, стековая архитектура EVM менее эффективна, чем регистровая архитектура RISC-V и современных ЦП. Ей требуется больше инструкций для выполнения той же операции, что также усложняет оптимизацию компилятора.
Эти комплексные факторы, включая узкие места производительности ZK-доказательств, сложность предкомпиляций и устаревшие архитектурные решения, вместе создают убедительную и неотложную причину для того, чтобы Ethereum преодолел EVM.
RISC-V чертеж: создание более прочной основы
Преимущества RISC-V не только связаны с недостатками EVM, но и с его философией дизайна и врожденными внутренними преимуществами. Его архитектура предлагает надежную, простую и проверяемую основу, что делает ее очень подходящей для таких высокорисковых сред, как Ethereum.
Почему открытые стандарты лучше, чем индивидуальный дизайн
В отличие от настраиваемых архитектур команд (ISA), которые требуют создания всей программной экосистемы с нуля, RISC-V является зрелым открытым стандартом, который предлагает три ключевых преимущества:
Зрелая экосистема
Используя RISC-V, Ethereum в полной мере воспользовался коллективным прогрессом в области компьютерных наук за десятилетия. Как объяснил Джастин Дрейк, это предоставляет Ethereum возможность напрямую использовать инструменты мирового класса: «Существует компонент инфраструктуры, называемый LLVM, который представляет собой набор инструментов компилятора, позволяющий разработчикам компилировать высокоуровневые языки программирования на различные бэкенды. RISC-V является одним из поддерживаемых бэкендов. Так что если вы поддерживаете RISC-V, вы автоматически поддерживаете все высокоуровневые языки, поддерживаемые LLVM.»
Это значительно снизило барьер для входа для миллионов разработчиков, знакомых с такими языками, как Rust, C и Go.
Философия дизайна минимализма
Минимализм RISC-V — это намеренная особенность, а не ограничение. Его базовый набор инструкций содержит всего около 47 инструкций, что делает ядро виртуальной машины исключительно простым. Эта простота является огромным преимуществом с точки зрения безопасности, поскольку меньшая доверенная кодовая база легче поддается аудиту и формальной верификации.
Фактический стандарт в области ZK
Более того, экосистема zkVM уже сделала самостоятельный выбор. Как подчеркивает Джастин Дрейк, из данных Ethproofs можно увидеть четкую тенденцию: «RISC-V является ведущей ISA для бэкенда zkVM.»
Из 10 zkVM, способных подтверждать блоки Ethereum, 9 выбрали RISC-V в качестве целевой архитектуры. Эта рыночная конвергенция посылает мощный сигнал: использование RISC-V в Ethereum не является спекулятивной попыткой, а следует проверенному рынком стандарту.
Создано для доверия, а не только для выполнения
Помимо экосистемы, внутренняя архитектура RISC-V также особенно подходит для построения безопасных и проверяемых систем.
Во-первых, у RISC-V есть официальная, читаемая машиной спецификация, называемая SAIL. Это значительно улучшает спецификацию виртуальной машины Ethereum (EVM), которая в основном существует в виде документации (желтой книги) и может быть неоднозначной. Спецификация SAIL обеспечивает «золотой стандарт», который может предоставить математические доказательства, критически важные для правильности протокола, что жизненно важно для защиты ценного протокола. Как отметил Алекс Хикс из Фонда Ethereum (EF) на телефонной конференции Ethproofs, это позволяет схемам zkVM непосредственно «проверять в соответствии с официальной спецификацией RISC-V».
Во-вторых, RISC-V включает привилегированную архитектуру, которая часто игнорируется, но имеет решающее значение для безопасности. Она определяет различные уровни операций, включая пользовательский режим (для ненадежных приложений, таких как смарт-контракты) и режим контроля (для надежного «исполнительного ядра»).
В модели RISC-V смарт-контракты, работающие в пользовательском режиме, не могут напрямую получать доступ к состоянию блокчейна. Вместо этого они должны отправлять запросы к доверенному ядру, работающему в режиме управления, через специальную инструкцию ECALL (вызов окружения). Эта механика создает безопасную границу, принудительно реализуемую аппаратным обеспечением, которая более надежна и проще верифицируется, чем чисто программная модель песочницы EVM.
Видение Виталика
Этот переход задуман как последовательный и многоступенчатый процесс, чтобы обеспечить стабильность системы и обратную совместимость. Метод, описанный Виталиком Бутериным, направлен на достижение постепенного развития, а не революционных изменений.
Шаг первый: предпросмотр замены
На начальном этапе следует принять наиболее консервативный подход, введя ограниченные функции новой виртуальной машины (VM). Как предложил Виталик, «мы можем начать с ограниченных сценариев использования новой виртуальной машины, например, заменив предварительно скомпилированные функции». Это будет включать приостановку новых функций EVM, заменив их реализацией необходимых функций с помощью программ RISC-V, одобренных через белый список. Такой подход позволяет новой виртуальной машине тестироваться в реальных условиях в основной сети при низком уровне риска, при этом клиент Ethereum будет выступать в качестве посредника между двумя средами выполнения.
Шаг второй: Сосуществование двух виртуальных машин
Следующий этап — «прямой доступ новых виртуальных машин для пользователей». При развертывании смарт-контрактов можно будет добавить флаг, указывающий, является ли его байт-код EVM или RISC-V. Ключевая особенность — обеспечение бесшовной совместимости: «два типа контрактов смогут вызывать друг друга». Это будет реализовано через системные вызовы (ECALL), а клиент Ethereum будет служить посредником для среды выполнения.
Шаг третий: EVM как симуляционный контракт (стратегия «Rosetta»)
Конечной целью является достижение окончательной упрощённости протокола. На этом этапе «мы реализуем EVM как одну из реализаций новой виртуальной машины». Стандартный EVM станет формально проверяемым смарт-контрактом, работающим на нативном RISC-V L1. Это не только обеспечит постоянную поддержку устаревших приложений, но и позволит разработчикам клиентов поддерживать только один упрощённый движок исполнения.
Цепная реакция всей экосистемы
План перехода от EVM к RISC-V далеко не ограничивается основным протоколом; он окажет глубокое влияние на всю экосистему Ethereum, с потенциалом изменить опыт разработчиков, коренным образом изменить конкурентную среду решений уровня 2 и открыть новые модели экономического доказательства.
Перестройка структуры Rollup: разделение путей Optimistic и ZK
Переход на уровень L1 с исполняемым слоем RISC-V окажет совершенно различное влияние на два основных типа Rollups.
Безопасная модель Optimistic Rollups (таких как Arbitrum и Optimism) зависит от повторного выполнения спорных транзакций на Layer-1 для решения проблем с мошенничеством. Даже если Ethereum Layer-1 перейдет на RISC-V, эти системы не претерпят фундаментальных изменений. Как объяснил один из соучредителей Optimism: «Если мы перейдем на RISC-V, цепи Optimistic также не будут прерваны. Вам просто нужно скомпилировать виртуальную машину RISC-V в программу доказательства. И не нужно использовать Asterisc. Существующие системы доказательства на основе MIPS также не будут прерваны — вам просто нужно скомпилировать виртуальную машину RISC-V в MIPS.»
Это означает, что модель защиты от мошенничества по-прежнему цела. Корректировка является технической: необходимо скомпилировать новую виртуальную машину RISC-V в существующую инфраструктуру, а не redesign системы с нуля. Остается вызовом инженерные детали, такие как измерение газа, эффективность и стоимость.
В сравнении, ZK Rollups получат огромное стратегическое преимущество. Подавляющее большинство ZK Rollups уже использует RISC-V в качестве своей внутренней ISA. Использование одного и того же родного языка L1 может обеспечить более тесную и эффективную интеграцию. Джастин Дрейк описал будущее «родных Rollups», в котором L2 по сути является специализированным экземпляром среды выполнения самого L1, обеспечивая бесшовный расчет с помощью встроенной L1 VM. Эта интеграция приведет к следующим изменениям:
Упрощенный технологический стек: устранение сложного мостового соединения между внутренним исполнением RISC-V на L2 и EVM;
Реализация инструментов и повторного использования кода: компиляторы, отладчики и инструменты формальной верификации, разработанные для среды L1 RISC-V, могут быть использованы L2 напрямую, чтобы снизить затраты на разработку.
Координация экономических стимулов: Комиссии за газ уровня L1 будут более точно отражать фактические затраты на выполнение ZK-доказательства RISC-V, что позволит создать более разумную экономическую модель.
Новая эпоха для разработчиков и пользователей
Для разработчиков экосистемы Ethereum это изменение будет постепенным, а не разрушительным.
Для разработчиков ключевое преимущество заключается в том, что они могут войти в более широкий и зрелый мир разработки программного обеспечения. Как отметил Виталик Бутерин, разработчики «сможет писать контракты на Rust, и эти два языка начнут сосуществовать». В то же время он прогнозирует, что «Solidity и Vyper будут популярны еще долгое время», поскольку у них есть элегантно спроектированная логика смарт-контрактов. Возможность использовать основные языки и их богатые библиотеки через инструментальную цепочку LLVM станет революционной. Виталик описывает это как «опыт, похожий на Node.JS», в котором разработчики в основном могут использовать один и тот же язык для написания кода на цепочке и вне цепи.
Для пользователей конечная выгода заключается в более экономичной и мощной сети. Ожидается, что стоимость подтверждения снизится примерно в 100 раз — с нескольких долларов за транзакцию до нескольких центов — что напрямую приведет к более низким расходам на расчеты на уровне Layer-1 и Layer-2. Эта экономическая целесообразность откроет видение «Gigagas L1», цель которого — достичь производительности около 10000 TPS на уровне L1, тем самым поддерживая более сложные и высокоценные приложения на блокчейне в будущем.
Succinct Labs и SP1: доказательство того, что будущее уже здесь
Теоретические преимущества RISC-V были реализованы такими командами, как Succinct Labs, чьи результаты стали мощным кейс-исследованием для всего предложения.
SP1, разработанный Succinct Labs, является высокопроизводимым, открытым zkVM, построенным на основе RISC-V, который проверяет жизнеспособность нового архитектурного подхода. Он использует концепцию "предварительно скомпилированного централизованного" дизайна, что идеально решает проблему криптографической узкой места EVM. В отличие от традиционных подходов, полагающихся на медленные, жестко закодированные предварительно скомпилированные методы, SP1 разгружает такие ресурсоемкие операции, как хеширование Keccak, на специально разработанные и вручную оптимизированные ZK-цепи, вызываемые через стандартные инструкции ECALL. Это обеспечивает как производительность индивидуального оборудования, так и гибкость программного обеспечения.
Практическое влияние команды стало очевидным, их продукт OP Succinct использует SP1 для реализации «ZK-изации» Optimistic Rollup. Как объяснила соучредитель Succinct Ума Рой:
«Ваш OP Stack Rollup больше не нужно ждать 7 дней для окончательного подтверждения и вывода... теперь это занимает всего 1 час. Это значительно ускоряет окончательное подтверждение, просто потрясающе.»
Это решает ключевую проблему всей экосистемы OP Stack. Кроме того, инфраструктура Succinct, «Succinct Prover Network», была разработана как децентрализованный рынок генерации доказательств, демонстрируя жизнеспособную экономическую модель для будущего проверяемых вычислений. Их работа - это не только проверка концепции, но и жизнеспособный план будущего, описанный в данной статье.
Как Ethereum снижает риски
Ключевое преимущество RISC-V заключается в том, что он делает конечной целью формальной верификации — математическое доказательство корректности системы — достижимой целью. Спецификация EVM написана на естественном языке в желтой книге (Yellow Paper) и имеет крайне высокую степень сложности для формализации. В то время как RISC-V имеет официальную, машинно-читаемую спецификацию SAIL, которая предоставляет четкое "золотое эталонное" поведение.
Это открывает ясный путь к более высокой безопасности. Как отметил Алекс Хикс из фонда Ethereum, в настоящее время ведется работа по «извлечению zkVM RISC-V схемы и официальной RISC-V спецификации в Lean для формальной проверки». Это знаковый прогресс, который переносит доверие от подверженной ошибкам человеческой реализации к可验证ным математическим доказательствам, обеспечивая прорыв в области безопасности.
Основные риски трансформации
Несмотря на множество преимуществ архитектуры RISC-V L1, она также столкнется с новыми сложными вызовами.
Проблема учета Gas: создание детерминированной и справедливой модели Gas для универсального ISA является одной из самых сложных задач. Простые методы подсчета инструкций подвержены угрозе атак отказа в обслуживании. Например, злоумышленник может разработать программу, которая многократно вызывает кэшированную программу, тем самым достигая высокой загрузки ресурсов при очень низких затратах на Gas.
Безопасность цепочки инструментов и проблемы «воспроизводимой сборки»: это, возможно, самый важный и недооцененный риск в процессе трансформации. Модель безопасности переходит от виртуальных машин доверенной цепи к доверению каждому разработчику, использующему компиляторы вне цепи (например, LLVM), которые являются крайне сложными и известны тем, что содержат уязвимости. Злоумышленники могут воспользоваться уязвимостями компилятора, чтобы преобразовать на вид безобидный исходный код в злонамеренный байт-код. Кроме того, обеспечить полное соответствие байт-кода после компиляции в цепи и определенному публичному исходному коду, т.е. проблему «воспроизводимой сборки», также крайне сложно, поскольку незначительные различия в среде сборки могут привести к созданию различных бинарных файлов.
Стратегия смягчения
Дорога вперед требует многоуровневой стратегии защиты.
Поэтапный запуск: постепенный и многоступенчатый план перехода является основной стратегией снижения рисков. Введя RISC-V сначала в качестве предварительно скомпилированного альтернативного решения, а затем развернув его в среде с двумя виртуальными машинами, сообщество сможет накопить операционный опыт и уверенность в условиях низкого риска, прежде чем произойдут какие-либо необратимые изменения.
Полный аудит: фузз-тестирование и формальная верификация. Хотя формальная верификация является конечной целью, она должна сопровождаться постоянным и интенсивным тестированием. Как показал Валентин из Diligence Security на конференции Ethproofs, их фузз-тестировщик Argus уже выявил 11 ключевых уязвимостей целостности и корректности в ведущем zkVM. Это доказывает, что даже в самых тщательно спроектированных системах есть уязвимости, которые можно выявить только с помощью строгого противостоящего тестирования.
Стандартизация: Чтобы избежать фрагментации экосистемы, сообществу необходимо единогласно принять единую, стандартизированную конфигурацию RISC-V. Это, вероятно, будет комбинация ABI RV64 GC и совместимого с Linux, так как эта комбинация может обеспечить наибольшую поддержку со стороны современных языков и инструментов, что позволит максимально использовать преимущества новой экосистемы.