Экосистема Ethereum стоит на переломном этапе. То, что начиналось как революционная платформа для умных контрактов, накопило слои технической сложности, которые теперь угрожают его масштабируемости. В центре этой проблемы находится Ethereum Virtual Machine — базовый слой выполнения, который обеспечил успех платформы, но все больше выступает как ограничивающий фактор в эпоху нулевых знаний и высокопроизводительной проверки.
Кризис производительности: когда EVM столкнулся с нулевыми знаниями
Корень проблемы масштабируемости Ethereum не является загадкой. По мере перехода сети к системам проверки на основе нулевых знаний, в взаимодействии EVM с ZK-доказательствами возникла фундаментальная неэффективность. Текущие реализации zkEVM не доказывают напрямую сам виртуальный машинный слой. Вместо этого они доказывают интерпретатор EVM, который затем компилируется в байткод RISC-V. Эта архитектурная косвенность создает огромный штраф по производительности — оценки указывают на задержки в 50–800 раз медленнее, чем нативное выполнение программ.
Проблема усугубляется при учете экономической модели сети. Даже при использовании оптимизированных хеш-алгоритмов, таких как Poseidon, генерация доказательств для выполнения блока все равно занимает 80–90% общего времени доказательства. Виталик Бутерин прямо заявил: если базовая архитектура все равно компилируется в RISC-V, зачем вообще сохранять интерпретируемый слой EVM? Ответ прост — устранить его.
Помимо накладных расходов интерпретатора, техническая основа EVM показывает более глубокие ограничения. 256-битная стековая архитектура была оптимизирована для криптографических операций в ранней эпохе вычислений. Современные умные контракты обычно работают с 32- или 64-битными целыми числами, однако EVM принуждает все значения проходить через свою 256-битную архитектуру. В системах нулевых знаний эта неэффективность становится особенно дорогой — меньшие числа требуют больше ресурсов при генерации доказательств, а не меньше, при этом вычислительная сложность увеличивается в 2–4 раза.
Проблема долга: предкомпилированные модули как технический бычий кнут
Чтобы компенсировать ограничения производительности EVM в некоторых криптографических операциях, Ethereum ввел предкомпилированные контракты — встроенные функции, закодированные прямо в протокол. Хотя это было прагматично в краткосрочной перспективе, такой подход создал то, что Виталик Бутерин назвал «катастрофическим» техническим долгом.
Объем этой проблемы ошеломляющий. Обертка для одного предкомпилированного контракта (например, modexp) превышает весь код базового интерпретатора RISC-V. Добавление новых предкомпилированных функций требует спорных решений по хардфоркам, что значительно ограничивает инновации в протоколе, когда приложения нуждаются в новых криптографических примитивах. Поверхность безопасности расширилась опасно, а сложность протокола постоянно растет. Как резюмировал Бутерин: «Начиная с сегодняшнего дня, мы должны прекратить добавлять новые предкомпилированные контракты.»
Решение RISC-V: почему открытый стандарт превосходит индивидуальную архитектуру
RISC-V — это не продукт, а открытая архитектура набора команд — свободный чертеж для построения процессоров. Его дизайн отражает уроки, извлеченные за десятилетия развития компьютерной архитектуры, делая его исключительно подходящим для следующей фазы Ethereum.
Минимализм архитектуры
Базовый набор инструкций RISC-V содержит примерно 47 команд. Эта крайняя простота — сознательный выбор, а не ограничение. Меньший доверенный код становится значительно проще для аудита и формальной верификации — критически важные требования для протоколов, обеспечивающих миллиарды в пользовательской ценности. Сложные операции добавляются через дополнительные расширения, сохраняющие простоту ядра без излишнего раздувания протокола.
Экосистема через LLVM
Приняв RISC-V, Ethereum получает доступ к десятилетиям развития инфраструктуры компиляторов через LLVM — «низкоуровневую виртуальную машину». Это решение обеспечивает нативную поддержку Rust, Go, C++, Python и десятков других языков. Разработчики по всему миру уже владеют этими инструментами. Вместо того чтобы создавать новую программную экосистему с нуля, Ethereum может унаследовать зрелую, проверенную инфраструктуру, которая уже поддерживает миллионы разработчиков.
Практическое преимущество трудно переоценить. Создание цепочек компиляторов — чрезвычайно сложная задача; использование существующих увеличивает эффективность разработки в разы. Благодаря принятию RISC-V Ethereum фактически получает бесплатный доступ к мировому уровню инфраструктуры компиляторов, что было бы чрезвычайно дорого самостоятельно.
Рынок zkVM уже выбрал
Сигнал из экосистемы нулевых знаний однозначен. Среди десяти бекендов zkVM, способных доказывать блоки Ethereum, девять уже приняли RISC-V в качестве целевой архитектуры. Это не теоретическая спекуляция, а практическая валидация. Проекты, строящие будущее ZK, независимо пришли к выводу, что RISC-V — лучший выбор для проверяемых вычислений. Принятие Ethereum совпадает с рыночной динамикой, а не создает ее.
Формальная верификация через спецификацию SAIL
Спецификация EVM в основном существует в виде текста в Желтой книге — по сути, неоднозначна и трудно формализуема математически. В отличие от этого, RISC-V включает машиночитаемую спецификацию SAIL, которая служит «золотым стандартом» для формальной верификации.
Это различие имеет огромное значение. Формальная верификация позволяет создавать математические доказательства правильности системы — переносит доверие с ошибочных человеческих реализаций на проверяемые криптографические гарантии. Исследователи Фонда Ethereum уже работают над извлечением zkVM RISC-V цепей для формальной проверки в соответствии с официальной спецификацией в системе Lean. Это — переломный момент: переход от безопасности, основанной на реализации, к безопасности, основанной на спецификации.
Трехфазная миграция: развитие, а не революция
Осознавая риски архитектурных изменений, руководство Ethereum предложило осознанный многоэтапный подход, ориентированный на обратную совместимость и стабильность работы.
Фаза первая: ограниченное внедрение zkVM
Изначально функциональность RISC-V будет вводиться через предкомпилированные альтернативы — фактически заменяя устаревшие предкомпилированные контракты EVM на эквивалентные функции, реализованные как белый список RISC-V программ. Это позволит тестировать в реальных условиях сети с низким риском. Новый виртуальный машинный слой докажет свою эффективность через практическую проверку перед более широким внедрением.
Фаза вторая: сосуществование двух виртуальных машин
Когда появится уверенность, смарт-контракты смогут явно указывать, использовать ли EVM или RISC-V байткод через теги контрактов. Важное нововведение — бесшовная совместимость: контракты EVM и RISC-V смогут вызывать друг друга через стандартизированные системные вызовы (ECALL). Это создаст единое средоточие выполнения, где обе архитектуры будут взаимодействовать внутри одного протокола.
Фаза третья: EVM как формальная спецификация
Конечная цель — рассматривать EVM как формально проверяемый умный контракт, выполняемый на нативном RISC-V L1. Наследующие приложения получат постоянную поддержку через реализацию, а разработчики протокола — единый движок выполнения. Сложность исчезнет, нагрузка на поддержку значительно снизится.
Радикальная перестройка экосистемы: победители и проигравшие новой архитектуры
Переход архитектуры кардинально изменит экономику Layer 2 и стимулы разработчиков в экосистеме Ethereum.
Оптимистичные Rollups столкнутся с экзистенциальными вызовами
Проекты вроде Arbitrum и Optimism строили свои модели безопасности вокруг механизмов доказательства мошенничества, которые работают путем повторного выполнения спорных транзакций через L1 EVM. Когда EVM исчезнет, их основа безопасности рухнет. Эти проекты столкнутся с жестким выбором: либо провести масштабные инженерные работы по переработке систем доказательства мошенничества под RISC-V, либо полностью отказаться от гарантий Ethereum. Вероятно, это ускорит слияние с моделями на базе нулевых знаний.
Обратное верно для ZK Rollups. Большинство проектов уже внутренне стандартизированы на RISC-V. Когда L1 «говорит на одном языке», интеграция становится значительно проще. Визия Джастина Дрейка о «родных Rollups» описывает L2 как специализированные экземпляры среды выполнения L1 — достигая бесшовных расчетов без слоев трансляции.
Практические преимущества очевидны:
Объединение компиляторов: инструменты, разработанные для L1 RISC-V, сразу же подходят для L2
Выравнивание модели газа: L1 и L2 используют одинаковые инструкции, что делает ценообразование более рациональным
Повторное использование кода: инструменты отладки, формальной верификации и оптимизации станут универсальными
Трансформация опыта разработчиков и пользователей
Для разработчиков этот переход означает освобождение от ограничений EVM без отказа от экосистемы. Внезапно популярные языки программирования станут жизнеспособными для разработки на блокчейне. Можно писать контракты на Rust, сохраняя знакомство с стандартными фреймворками. Как предложил Бутерин, «Solidity и Vyper останутся популярными еще долгое время благодаря своему элегантному дизайну для логики умных контрактов», но они станут опциями реализации, а не обязательным выбором.
Это похоже на то, как Node.js позволил разработчикам писать JavaScript для клиента и сервера. Теперь один и тот же разработчик сможет использовать одинаковые языки для оффчейн и ончейн вычислений, что значительно упростит рабочие процессы.
Для пользователей последствия еще более кардинальны. Ожидается, что стоимость доказательств снизится примерно в 100 раз — что превратит текущие транзакционные издержки с нескольких долларов в несколько центов или меньше. Такая экономическая эффективность откроет путь к реализации концепции «Gigagas L1», предполагающей около 10 000 транзакций в секунду. Сложные, ценные на цепочке приложения станут экономически оправданными.
Succinct Labs и SP1: доказательство работоспособности перехода
Переход Ethereum от теоретической идеи к практической реализации получил импульс благодаря командам вроде Succinct Labs, чья реализация zkVM SP1 демонстрирует, что проверка на базе RISC-V не только возможна, но и эффективна.
SP1 использует архитектуру «предкомпилированных функций», которая напрямую решает криптографические узкие места, мешающие масштабированию EVM. Вместо медленных встроенных функций, SP1 передает тяжелые операции, такие как хеширование Keccak, специализированным ZK-цепям, вызываемым через стандартные ECALL-инструкции. Такой гибридный подход сочетает производительность специализированного оборудования с гибкостью программного обеспечения.
Практический эффект проявился сразу. Продукт OP Succinct от Succinct Labs добавил возможности нулевых знаний в стеки Optimistic Rollup. Итог: финализация выводов сократилась с семи дней до примерно одного часа. Этот прорыв решает важнейшие проблемы в экосистеме Optimistic и показывает, как архитектура RISC-V позволяет качественно улучшить пользовательский опыт.
Помимо отдельных проектов, сеть Prover от Succinct представляет собой жизнеспособную экономическую модель для децентрализованного генерации доказательств — создавая практические шаблоны для будущего проверяемых вычислений.
Реальные риски трансформации
Несмотря на архитектурные преимущества RISC-V, переход влечет за собой новые вызовы, требующие строгих мер по их минимизации.
Сложности метering газа
Создание детерминированных, справедливых моделей газа для общего набора инструкций остается в значительной степени нерешенной задачей. Простое подсчет инструкций уязвимо к атакам типа отказа в обслуживании. Злоумышленники могут создавать программы, вызывающие повторные промахи кэша, потребляющие значительные ресурсы при минимальных затратах газа. Эта угроза ставит под угрозу стабильность сети и экономические модели.
Безопасность компиляторов и инструментов
Малозаметная, но критическая опасность — зависимость безопасности от внешних компиляторов, таких как LLVM. Эти инструменты чрезвычайно сложны и содержат известные уязвимости. Продвинутые злоумышленники могут эксплуатировать баги компиляторов, превращая безобидный исходный код в вредоносный байткод. Проблема «воспроизводимых сборок» усугубляет ситуацию — небольшие изменения окружения могут приводить к разным бинарным файлам, что угрожает прозрачности и гарантиям доверия.
Фрагментация экосистемы
Без стандартизации разные конфигурации RISC-V могут распространиться по проектам, разрушая преимущества единого подхода. Необходима координация вокруг единого стандарта — вероятно, RV64GC с Linux-совместимым ABI.
Меры по снижению рисков: формальная верификация, интенсивное тестирование и стандартизация
Для минимизации этих рисков требуется многоуровневая стратегия защиты.
Сам по себе поэтапный запуск служит механизмом снижения рисков — начальное внедрение в сценариях с низким риском, таких как предкомпилированные функции, создает операционную уверенность перед более широким переходом. Одновременно сообщество должно активно заниматься формальной верификацией и постоянным тестированием на наличие уязвимостей.
Джон Валентайн из Diligence Security показал, что даже ведущие zkVM содержат критические уязвимости, обнаруживаемые только при тщательном fuzz-тестировании. Комплексные стратегии безопасности сочетают формальную верификацию — «теоретическую основу» — с интенсивным тестированием — «практической проверкой».
Стандартизация вокруг единственной конфигурации RISC-V — например, RV64GC с Linux ABI — обеспечивает согласованность экосистемы, поддержку множества языков программирования и предотвращает фрагментацию, которая могла бы подорвать преимущества перехода.
Формируемое проверяемое будущее
Предложенная миграция Ethereum с EVM на RISC-V — это не просто постепенная оптимизация, а фундаментальная перестройка слоя выполнения протокола. Она решает глубокие узкие места масштабируемости, устраняет технический долг предкомпилированных контрактов и выводит Ethereum на уровень экосистемы проверяемых вычислений и формальных спецификаций цепочек.
Путь вперед требует балансировки между конкурирующими требованиями: значительными приростами производительности за счет архитектуры, основанной на нулевых знаниях, и обратной совместимостью; преимуществами безопасности от упрощения протокола и существующей инфраструктурой EVM; а также возможностями универсальной вычислительной экосистемы и рисками, связанными со сложными сторонними инструментами.
В конечном итоге, эта архитектурная эволюция воплощает приверженность Ethereum концепции «Lean Execution» и более широкой идеи «Lean Ethereum». Вместо того чтобы оставаться платформой для умных контрактов, Ethereum станет эффективным, безопасным слоем расчетов и доступности данных, предназначенным для поддержки огромной вселенной проверяемых вычислений.
Виталик Бутерин видит конечную цель — «предоставлять ZK-снапшоты для всего» — и она приближается к реализации, поскольку проекты вроде Succinct Labs демонстрируют, что RISC-V — это не спекулятивная архитектура, а практическая инженерия в ближайшем будущем. Приняв RISC-V, Ethereum позиционирует себя как базовый слой доверия для следующего поколения интернет-инфраструктуры — основанный на криптографических доказательствах, а не доверенных посредниках.
Эра доказуемого программного обеспечения наступила.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Ключевые выборы в архитектуре Ethereum: почему RISC-V представляет будущее проверяемых вычислений
Экосистема Ethereum стоит на переломном этапе. То, что начиналось как революционная платформа для умных контрактов, накопило слои технической сложности, которые теперь угрожают его масштабируемости. В центре этой проблемы находится Ethereum Virtual Machine — базовый слой выполнения, который обеспечил успех платформы, но все больше выступает как ограничивающий фактор в эпоху нулевых знаний и высокопроизводительной проверки.
Кризис производительности: когда EVM столкнулся с нулевыми знаниями
Корень проблемы масштабируемости Ethereum не является загадкой. По мере перехода сети к системам проверки на основе нулевых знаний, в взаимодействии EVM с ZK-доказательствами возникла фундаментальная неэффективность. Текущие реализации zkEVM не доказывают напрямую сам виртуальный машинный слой. Вместо этого они доказывают интерпретатор EVM, который затем компилируется в байткод RISC-V. Эта архитектурная косвенность создает огромный штраф по производительности — оценки указывают на задержки в 50–800 раз медленнее, чем нативное выполнение программ.
Проблема усугубляется при учете экономической модели сети. Даже при использовании оптимизированных хеш-алгоритмов, таких как Poseidon, генерация доказательств для выполнения блока все равно занимает 80–90% общего времени доказательства. Виталик Бутерин прямо заявил: если базовая архитектура все равно компилируется в RISC-V, зачем вообще сохранять интерпретируемый слой EVM? Ответ прост — устранить его.
Помимо накладных расходов интерпретатора, техническая основа EVM показывает более глубокие ограничения. 256-битная стековая архитектура была оптимизирована для криптографических операций в ранней эпохе вычислений. Современные умные контракты обычно работают с 32- или 64-битными целыми числами, однако EVM принуждает все значения проходить через свою 256-битную архитектуру. В системах нулевых знаний эта неэффективность становится особенно дорогой — меньшие числа требуют больше ресурсов при генерации доказательств, а не меньше, при этом вычислительная сложность увеличивается в 2–4 раза.
Проблема долга: предкомпилированные модули как технический бычий кнут
Чтобы компенсировать ограничения производительности EVM в некоторых криптографических операциях, Ethereum ввел предкомпилированные контракты — встроенные функции, закодированные прямо в протокол. Хотя это было прагматично в краткосрочной перспективе, такой подход создал то, что Виталик Бутерин назвал «катастрофическим» техническим долгом.
Объем этой проблемы ошеломляющий. Обертка для одного предкомпилированного контракта (например, modexp) превышает весь код базового интерпретатора RISC-V. Добавление новых предкомпилированных функций требует спорных решений по хардфоркам, что значительно ограничивает инновации в протоколе, когда приложения нуждаются в новых криптографических примитивах. Поверхность безопасности расширилась опасно, а сложность протокола постоянно растет. Как резюмировал Бутерин: «Начиная с сегодняшнего дня, мы должны прекратить добавлять новые предкомпилированные контракты.»
Решение RISC-V: почему открытый стандарт превосходит индивидуальную архитектуру
RISC-V — это не продукт, а открытая архитектура набора команд — свободный чертеж для построения процессоров. Его дизайн отражает уроки, извлеченные за десятилетия развития компьютерной архитектуры, делая его исключительно подходящим для следующей фазы Ethereum.
Минимализм архитектуры
Базовый набор инструкций RISC-V содержит примерно 47 команд. Эта крайняя простота — сознательный выбор, а не ограничение. Меньший доверенный код становится значительно проще для аудита и формальной верификации — критически важные требования для протоколов, обеспечивающих миллиарды в пользовательской ценности. Сложные операции добавляются через дополнительные расширения, сохраняющие простоту ядра без излишнего раздувания протокола.
Экосистема через LLVM
Приняв RISC-V, Ethereum получает доступ к десятилетиям развития инфраструктуры компиляторов через LLVM — «низкоуровневую виртуальную машину». Это решение обеспечивает нативную поддержку Rust, Go, C++, Python и десятков других языков. Разработчики по всему миру уже владеют этими инструментами. Вместо того чтобы создавать новую программную экосистему с нуля, Ethereum может унаследовать зрелую, проверенную инфраструктуру, которая уже поддерживает миллионы разработчиков.
Практическое преимущество трудно переоценить. Создание цепочек компиляторов — чрезвычайно сложная задача; использование существующих увеличивает эффективность разработки в разы. Благодаря принятию RISC-V Ethereum фактически получает бесплатный доступ к мировому уровню инфраструктуры компиляторов, что было бы чрезвычайно дорого самостоятельно.
Рынок zkVM уже выбрал
Сигнал из экосистемы нулевых знаний однозначен. Среди десяти бекендов zkVM, способных доказывать блоки Ethereum, девять уже приняли RISC-V в качестве целевой архитектуры. Это не теоретическая спекуляция, а практическая валидация. Проекты, строящие будущее ZK, независимо пришли к выводу, что RISC-V — лучший выбор для проверяемых вычислений. Принятие Ethereum совпадает с рыночной динамикой, а не создает ее.
Формальная верификация через спецификацию SAIL
Спецификация EVM в основном существует в виде текста в Желтой книге — по сути, неоднозначна и трудно формализуема математически. В отличие от этого, RISC-V включает машиночитаемую спецификацию SAIL, которая служит «золотым стандартом» для формальной верификации.
Это различие имеет огромное значение. Формальная верификация позволяет создавать математические доказательства правильности системы — переносит доверие с ошибочных человеческих реализаций на проверяемые криптографические гарантии. Исследователи Фонда Ethereum уже работают над извлечением zkVM RISC-V цепей для формальной проверки в соответствии с официальной спецификацией в системе Lean. Это — переломный момент: переход от безопасности, основанной на реализации, к безопасности, основанной на спецификации.
Трехфазная миграция: развитие, а не революция
Осознавая риски архитектурных изменений, руководство Ethereum предложило осознанный многоэтапный подход, ориентированный на обратную совместимость и стабильность работы.
Фаза первая: ограниченное внедрение zkVM
Изначально функциональность RISC-V будет вводиться через предкомпилированные альтернативы — фактически заменяя устаревшие предкомпилированные контракты EVM на эквивалентные функции, реализованные как белый список RISC-V программ. Это позволит тестировать в реальных условиях сети с низким риском. Новый виртуальный машинный слой докажет свою эффективность через практическую проверку перед более широким внедрением.
Фаза вторая: сосуществование двух виртуальных машин
Когда появится уверенность, смарт-контракты смогут явно указывать, использовать ли EVM или RISC-V байткод через теги контрактов. Важное нововведение — бесшовная совместимость: контракты EVM и RISC-V смогут вызывать друг друга через стандартизированные системные вызовы (ECALL). Это создаст единое средоточие выполнения, где обе архитектуры будут взаимодействовать внутри одного протокола.
Фаза третья: EVM как формальная спецификация
Конечная цель — рассматривать EVM как формально проверяемый умный контракт, выполняемый на нативном RISC-V L1. Наследующие приложения получат постоянную поддержку через реализацию, а разработчики протокола — единый движок выполнения. Сложность исчезнет, нагрузка на поддержку значительно снизится.
Радикальная перестройка экосистемы: победители и проигравшие новой архитектуры
Переход архитектуры кардинально изменит экономику Layer 2 и стимулы разработчиков в экосистеме Ethereum.
Оптимистичные Rollups столкнутся с экзистенциальными вызовами
Проекты вроде Arbitrum и Optimism строили свои модели безопасности вокруг механизмов доказательства мошенничества, которые работают путем повторного выполнения спорных транзакций через L1 EVM. Когда EVM исчезнет, их основа безопасности рухнет. Эти проекты столкнутся с жестким выбором: либо провести масштабные инженерные работы по переработке систем доказательства мошенничества под RISC-V, либо полностью отказаться от гарантий Ethereum. Вероятно, это ускорит слияние с моделями на базе нулевых знаний.
Zero-Knowledge Rollups получат стратегическое преимущество
Обратное верно для ZK Rollups. Большинство проектов уже внутренне стандартизированы на RISC-V. Когда L1 «говорит на одном языке», интеграция становится значительно проще. Визия Джастина Дрейка о «родных Rollups» описывает L2 как специализированные экземпляры среды выполнения L1 — достигая бесшовных расчетов без слоев трансляции.
Практические преимущества очевидны:
Трансформация опыта разработчиков и пользователей
Для разработчиков этот переход означает освобождение от ограничений EVM без отказа от экосистемы. Внезапно популярные языки программирования станут жизнеспособными для разработки на блокчейне. Можно писать контракты на Rust, сохраняя знакомство с стандартными фреймворками. Как предложил Бутерин, «Solidity и Vyper останутся популярными еще долгое время благодаря своему элегантному дизайну для логики умных контрактов», но они станут опциями реализации, а не обязательным выбором.
Это похоже на то, как Node.js позволил разработчикам писать JavaScript для клиента и сервера. Теперь один и тот же разработчик сможет использовать одинаковые языки для оффчейн и ончейн вычислений, что значительно упростит рабочие процессы.
Для пользователей последствия еще более кардинальны. Ожидается, что стоимость доказательств снизится примерно в 100 раз — что превратит текущие транзакционные издержки с нескольких долларов в несколько центов или меньше. Такая экономическая эффективность откроет путь к реализации концепции «Gigagas L1», предполагающей около 10 000 транзакций в секунду. Сложные, ценные на цепочке приложения станут экономически оправданными.
Succinct Labs и SP1: доказательство работоспособности перехода
Переход Ethereum от теоретической идеи к практической реализации получил импульс благодаря командам вроде Succinct Labs, чья реализация zkVM SP1 демонстрирует, что проверка на базе RISC-V не только возможна, но и эффективна.
SP1 использует архитектуру «предкомпилированных функций», которая напрямую решает криптографические узкие места, мешающие масштабированию EVM. Вместо медленных встроенных функций, SP1 передает тяжелые операции, такие как хеширование Keccak, специализированным ZK-цепям, вызываемым через стандартные ECALL-инструкции. Такой гибридный подход сочетает производительность специализированного оборудования с гибкостью программного обеспечения.
Практический эффект проявился сразу. Продукт OP Succinct от Succinct Labs добавил возможности нулевых знаний в стеки Optimistic Rollup. Итог: финализация выводов сократилась с семи дней до примерно одного часа. Этот прорыв решает важнейшие проблемы в экосистеме Optimistic и показывает, как архитектура RISC-V позволяет качественно улучшить пользовательский опыт.
Помимо отдельных проектов, сеть Prover от Succinct представляет собой жизнеспособную экономическую модель для децентрализованного генерации доказательств — создавая практические шаблоны для будущего проверяемых вычислений.
Реальные риски трансформации
Несмотря на архитектурные преимущества RISC-V, переход влечет за собой новые вызовы, требующие строгих мер по их минимизации.
Сложности метering газа
Создание детерминированных, справедливых моделей газа для общего набора инструкций остается в значительной степени нерешенной задачей. Простое подсчет инструкций уязвимо к атакам типа отказа в обслуживании. Злоумышленники могут создавать программы, вызывающие повторные промахи кэша, потребляющие значительные ресурсы при минимальных затратах газа. Эта угроза ставит под угрозу стабильность сети и экономические модели.
Безопасность компиляторов и инструментов
Малозаметная, но критическая опасность — зависимость безопасности от внешних компиляторов, таких как LLVM. Эти инструменты чрезвычайно сложны и содержат известные уязвимости. Продвинутые злоумышленники могут эксплуатировать баги компиляторов, превращая безобидный исходный код в вредоносный байткод. Проблема «воспроизводимых сборок» усугубляет ситуацию — небольшие изменения окружения могут приводить к разным бинарным файлам, что угрожает прозрачности и гарантиям доверия.
Фрагментация экосистемы
Без стандартизации разные конфигурации RISC-V могут распространиться по проектам, разрушая преимущества единого подхода. Необходима координация вокруг единого стандарта — вероятно, RV64GC с Linux-совместимым ABI.
Меры по снижению рисков: формальная верификация, интенсивное тестирование и стандартизация
Для минимизации этих рисков требуется многоуровневая стратегия защиты.
Сам по себе поэтапный запуск служит механизмом снижения рисков — начальное внедрение в сценариях с низким риском, таких как предкомпилированные функции, создает операционную уверенность перед более широким переходом. Одновременно сообщество должно активно заниматься формальной верификацией и постоянным тестированием на наличие уязвимостей.
Джон Валентайн из Diligence Security показал, что даже ведущие zkVM содержат критические уязвимости, обнаруживаемые только при тщательном fuzz-тестировании. Комплексные стратегии безопасности сочетают формальную верификацию — «теоретическую основу» — с интенсивным тестированием — «практической проверкой».
Стандартизация вокруг единственной конфигурации RISC-V — например, RV64GC с Linux ABI — обеспечивает согласованность экосистемы, поддержку множества языков программирования и предотвращает фрагментацию, которая могла бы подорвать преимущества перехода.
Формируемое проверяемое будущее
Предложенная миграция Ethereum с EVM на RISC-V — это не просто постепенная оптимизация, а фундаментальная перестройка слоя выполнения протокола. Она решает глубокие узкие места масштабируемости, устраняет технический долг предкомпилированных контрактов и выводит Ethereum на уровень экосистемы проверяемых вычислений и формальных спецификаций цепочек.
Путь вперед требует балансировки между конкурирующими требованиями: значительными приростами производительности за счет архитектуры, основанной на нулевых знаниях, и обратной совместимостью; преимуществами безопасности от упрощения протокола и существующей инфраструктурой EVM; а также возможностями универсальной вычислительной экосистемы и рисками, связанными со сложными сторонними инструментами.
В конечном итоге, эта архитектурная эволюция воплощает приверженность Ethereum концепции «Lean Execution» и более широкой идеи «Lean Ethereum». Вместо того чтобы оставаться платформой для умных контрактов, Ethereum станет эффективным, безопасным слоем расчетов и доступности данных, предназначенным для поддержки огромной вселенной проверяемых вычислений.
Виталик Бутерин видит конечную цель — «предоставлять ZK-снапшоты для всего» — и она приближается к реализации, поскольку проекты вроде Succinct Labs демонстрируют, что RISC-V — это не спекулятивная архитектура, а практическая инженерия в ближайшем будущем. Приняв RISC-V, Ethereum позиционирует себя как базовый слой доверия для следующего поколения интернет-инфраструктуры — основанный на криптографических доказательствах, а не доверенных посредниках.
Эра доказуемого программного обеспечения наступила.