Революция на уровне исполнения Ethereum: Перспективы и вызовы архитектуры RISC-V

Соучредитель Ethereum недавно предложил в сообществе дальновидное предложение: заменить существующую виртуальную машину (EVM) на открытое архитектурное решение RISC-V. Эта концепция была сопоставлена с Beam Chain на уровне исполнения, с целью преодолеть узкие места в производительности и упростить логику протокола. Особенно в отношении эффективности нулевых знаний (ZK Proof) ожидается, что можно достичь оптимизации до 100 раз. Это предложение направлено на решение текущих узких мест Ethereum в эффективности ZK доказательств, сложности построения блоков и доступности данных.

Текущие ограничения EVM и преимущества RISC-V

Проблема EVM:

• Устаревшая архитектура: 256-битная стековая структура несовместима с современными ЦП, что влияет на эффективность выполнения ZK-EVM.
• П瓶颈 ZK-доказательства: около половины ресурсов ZK-EVM используется для выполнения самого EVM, что ограничивает эффективность доказательства.
• Плохая поддержка: накапливание функций приводит к путанице в стандартах, например, SELFDESTRUCT трудно отменить.
• Ограниченная разработка: нестандартный набор команд ограничивает поддержку между языками, что делает трудным эффективную компиляцию основных языков.

Преимущества RISC-V:

• Высокая производительность: упрощенный набор команд, совместимый с аппаратным обеспечением, может быть использован для JIT-оптимизации и даже аппаратного ускорения.
• ZK оптимизация: прямая генерация схемы команд RISC-V, упрощение процесса ZK доказательства.
• Зрелая цепочка инструментов: поддержка основных языков, снижение порога разработки, расширение экосистемы.
• Универсальный стандарт: уже используемые блокчейн-проекты, имеющие успешные примеры.

Предложение считает, что использование RISC-V в качестве архитектуры выполнения контрактов напрямую более эффективно и имеет больший потенциал для расширения, чем компиляция EVM в RISC-V в ZK-EVM.

Замена путей и вызовы

Замены три варианта:

1. Двойная виртуальная машина (консервативный подход): EVM и RISC-V работают параллельно, обеспечивая совместимость в переходный период.
2. Онлайновый интерпретатор (радикальный): все контракты EVM интерпретируются и выполняются онлайновыми контрактами RISC-V.
3. Механизм плагинов интерпретатора (компромисс): использовать интерпретатор в качестве элемента протокола, позволяя в будущем вставлять другие ВМ.

Технические вызовы, с которыми сталкивается реализация:

• Риск снижения производительности: RISC-V необходимо эмулировать выполнение на чипах x86, начальная эффективность может быть ниже оптимизированной EVM.
• Реконструкция ценообразования газа: необходимо определить новую модель газа для инструкций RISC-V.
• Безопасный песочница дизайн: ограничение системных вызовов, предотвращение самопроизвольного изменения кода, обеспечение детерминированного выполнения.
• Инструменты разработки: обновление компилятора, отладчика, инструментов безопасности, поддержка байт-кода RISC-V.
• Совместимость миграции: некоторые контракты зависят от особенностей EVM, необходимо осторожно разрабатывать совместимый уровень или механизм отката.

Предложение склоняется к использованию двойной виртуальной машины (VM) в качестве переходного пути, обещая сохранить взаимную операбельность новых и старых контрактов, гарантируя неизменность опыта разработчиков и безболезненное обновление для пользователей.

Влияние на существующие маршруты расширения

RISC-V является оптимизацией инфраструктуры и не заменит существующие пути расширения:

• Уровень 2: RISC-V повышает эффективность обработки L1 и производительность ZK-верификации, что способствует более низким затратам и более быстрому представлению данных для Rollup.
• Шардинг данных и EIP-4844: узкое место в доступности данных все еще необходимо решить с помощью blob и Danksharding.
• FaaS, MEV: не зависят от архитектуры виртуальной машины и не подвержены влиянию продвижения RISC-V.

RISC-V это "смена двигателя", L2/шардинг это "расширение сети", оба аспекта различны и не противоречат друг другу.

Обратная связь сообщества и связанные попытки

Сообщество разногласий:

• Поддерживатели: считают, что это необходимое обновление для решения проблем производительности, которое поможет привлечь традиционных разработчиков.
• Консерваторы: беспокоятся о сложности реализации, исторических обязательствах, стоимости обновления экосистемных инструментов, ставят под сомнение соотношение затрат и результатов.

Похожие проекты:

• Move VM (Aptos/Sui): ресурсно-ориентированная виртуальная машина, высокая безопасность языка, но несовместима с EVM.
• FuelVM: разработан для параллельной обработки, совместим с языком Sway, ограниченная совместимость.
• WASM (Stylus): Внедрение WASM в качестве языка контрактов на L2 уже реализовано на одной из платформ.
• Некоторый блокчейн проект: основная сеть использует RISC-V в качестве виртуальной машины для контрактов, предоставляя практическую справку для Ethereum.

Предложение не исключает других вариантов и считает, что в будущем механизм интерпретатора может быть использован для внедрения таких ВМ, как Move, WASM и т.д., для создания многообразной экосистемы выполнения.

Перспективы будущего влияния

Опыт разработчика:

• Языки такие как Solidity/Vyper по-прежнему могут использоваться, просто изменив бэкенд компилятора.
• Возможно, будет открыта возможность написания контрактов на новых языках, таких как Rust/C, но миграция не будет обязательной.

Затраты на эксплуатацию и производительность:

• Повышение эффективности выполнения приведет к более высоким пределам Gas и более низким затратам.
• Контракты RISC-V могут уменьшить зависимость от предкомпилированных контрактов, а модель Gas будет ближе к затратам на ZK-доказательства.

Экологическая совместимость и развитие:

• В течение срока совместного использования двух виртуальных машин существующие контракты могут продолжать функционировать, а новые контракты постепенно будут использовать RISC-V.
• Инфраструктура должна поддерживать новый формат байт-кода, что может вызвать изменения в совместимости между цепочками.

Безопасность и стабильность:

• Новая архитектура требует широкого тестирования и формальной проверки для повышения надежности протокола.
• Более упрощенный уровень исполнения способствует аудиту и контролю над атакующими поверхностями.

Заключение

Коренные разработчики Ethereum предложили заменить EVM на RISC-V, что отражает глубокую мысль о предельной производительности и простоте протокола в будущем. Это предложение находится на ранней стадии обсуждения, его реализация, как ожидается, займет несколько лет и потребует преодоления множества технических, общественных и экологических вызовов. Это не отмена существующего направления, а укрепление основ и подготовка к будущему.

Как сказал инициатор: "Чтобы достичь качественного улучшения, это радикальное изменение может быть единственным жизнеспособным путем."

Это ставка на будущее, а также глубокое исследование вопроса "стоит ли преобразовывать базовый уровень".