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

Несколько дней назад я опубликовал научно-популярную статью о RISC-V, чтобы помочь читателям понять его прошлое и будущее.

EVM на RISC-V? Обсуждаем прошлое и настоящее RISC-V и его применение в сфере Web3

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

При подготовке материалов мне показалось, что столкновение этих мнений напоминает период «сотни школ мысли» в эпоху Чуньцю в китайской истории. Поэтому, вдохновившись идеей, я объединил их высказывания в современном формате круглого стола / Telegram Space, представив вам «виртуальный круглый стол», где акцент сделан на динамике дискуссии. Ведь, как говорится, благородный человек гармоничен, но сохраняет свою индивидуальность.

Для быстрого понимания основных тезисов ниже представлена структурированная таблица с горизонтальным сравнением ключевых характеристик основных виртуальных машин Web3, составленная на основе глубоких обсуждений более чем 10 технических лидеров.

Включает архитектуру, производительность и проблемы внедрения 9 классов решений, таких как RISC-V, WASM, EVM и др.: ( прокрутите влево или вправо, чтобы увидеть полную таблицу )

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

Модератор: Прежде всего давайте приветствуем @VitalikButerin[1], соучредителя Ethereum. Как новаторская виртуальная машина, EVM давно известна всем. Сейчас мы знаем, что вы хотите внести лучшие инновации, можете ли вы рассказать нам об этом?

@VitalikButerin: Привет всем! Меня зовут Vitalik, китайские пользователи часто называют меня «маленький V» (смеется). Как многие уже знают, я недавно опубликовал предложение по переходу от EVM к RISC-V. Вы можете прочитать оригинал на форуме[2] (китайская версия[3]), здесь я не буду повторяться, а лишь отмечу ключевые моменты:

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

• Среди нескольких ограничивающих факторов масштабирования Ethereum L1 эффективность выполнения является одним из главных узких мест. Нам необходимо повысить эффективность и существенно упростить уровень исполнения.

• Старые контракты EVM продолжат работу и будут полностью двунаправленно совместимы с новыми контрактами RISC-V. Существует несколько способов реализации:

• Решение с наименьшим разрушительным воздействием — одновременная поддержка обеих виртуальных машин.

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

• Явное протокольное поддержание концепции «интерпретатора виртуальной машины» с требованием написать его логику на RISC-V. EVM станет первым примером.

• В будущем можно будет поддерживать и другие языки (Move может стать кандидатом).

• Процесс разработки может практически не измениться, разработчики могут даже не заметить изменений.

• Virtual Machine CKB в Nervos уже создал precedent, по своей сути представляя собой реализацию на базе RISC-V[4].

Модератор: Спасибо @VitalikButerin за рассказ о последних планах Ethereum. Я видел, что многие в оригинальном треде выразили поддержку, а некоторые отметили необходимость дальнейших исследований. Учитывая тему нашего текущего обсуждения — сравнительный анализ сильных и слабых сторон виртуальных машин — мы не будем углубляться в детали о реализуемости RISC-V из того треда. Конечно, мы также пригласили некоторых соответствующих теме гостей для участия в следующих разделах.

Модератор: Приглашаем нашего второго гостя сегодняшнего дня: @IAmNickDodson[5], основатель и CEO Fuel Network[6]. Ранее он был участником ConsenSys, участвовал в разработке инфраструктуры и инструментов для Ethereum, глубоко занимался оптимизацией клиентского программного обеспечения Ethereum (такого как Geth или Parity). Человек с большим опытом и весомым словом в вопросах проектирования и реализации ВМ.

@IAmNickDodson: Во-первых, пост Vitalika вселяет энтузиазм. Я начал знакомиться с EVM еще до запуска основной сети Ethereum и могу четко сказать: мы тогда знали о ее недостатках, и эти проблемы существуют до сих пор. Но нельзя отрицать, что она стала фундаментом для создания настоящих децентрализованных приложений, и мы благодарны за это. [src[7]]

Модератор: Подскажите, почему вы решили разработать FuelVM вместо использования уже существующих решений?

@IAmNickDodson: При проектировании FuelVM мы изучали множество архитектур: архитектуры наборов инструкций (ISA): MIPS, RISC-V, x86, ARM; решения ВМ: WASM; а также специализированные для блокчейна ВМ: EVM, BitcoinScript, MoveVM, SVM и т.д. У каждой есть свои преимущества, но ни одна не удовлетворяет наши потребности полностью. Ниже я приведу результаты анализа и свои размышления по этому выбору. До этого хочу, чтобы вы, сидящие перед экраном, тоже задумались над тремя ключевыми вопросами: Дизайнирована ли эта архитектура специально для блокчейн-сценариев? Сохраняет ли она производительность в условиях антагонистического газотаксинга? Реально ли она улучшает ситуацию по сравнению с EVM? [src[8]]

Модератор: Отлично, спасибо за самопрезентацию вышеупомянутых гостей. Далее, следуя порядку исследования @IAmNickDodson, мы выберем несколько представительных проектов/технологий ВМ. Пожалуйста, поделитесь своим взглядом и анализом, если есть разные мнения, смело подключайтесь.

MIPS/RISC-V

@IAmNickDodson: Эти наборы команд CPU изначально проектировались для ранних микропроцессоров и встраиваемых устройств.

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

Недостатки: По своей сути являются наборами команд CPU (а не архитектурой виртуального вычисления), набор инструкций MIPS слишком базовый, для выполнения функций одной инструкции x86 или специализированной ВМ требуется больше операций (см. раздел CISC ниже), не учитывается антагонистическое тарифицирование газа, не оптимизированы под сценарии блокчейна, низкая эффективность обработки доказательств с нулевым разглашением (см. исследования Starkware/Valida).

Даже если технологии ZK снижают потребность узлов в тарифицировании, в сценариях высокой пропускной способности по-прежнему необходимы предварительные вычисления / общие доказательства, где все еще требуется механизм защиты от DoS (тарификация остается有价值的). [src[9]]

Georgios Konstantopoulos[10] (партнер и CTO Paradigm[11]) Если вам нравится предложение @VitalikButerin, то вам точно понравится этот R55[12], который мы медленно разрабатывали последние несколько месяцев... [src[13]]

0xpedro.eth/acc[14]: R55 позволяет вам писать смарт-контракты на чистом Rust и выполнять их через RISC-V в клиентах Ethereum. Обычно Solidity компилируется в байткод EVM, но R55 компилирует Rust в инструкции RISC-V. Это открытый фреймворк, способный раскрыть потенциал аппаратных оптимизаций. Использование Rust в Ethereum? Интересная, но сложная задача. Сам по себе RISC-V не знает об состоянии Ethereum (хранение, вызовы и т.д.), поэтому R55 добавляет системные вызовы. Используя ecall RISC-V, контракты на Rust могут читать память хранения (например, SLOAD), вызывать контракты или отправлять логи — тем самым бесшовно соединяя Rust с Ethereum.

R55 все еще находится в разработке, требуются настройки газа и безопасности, но будущее выглядит захватывающим: rollup или appchains смогут выполнять нативные Rust-контракты, а zkEVM сможет использовать RISC-V для криптографических операций. На мой взгляд, безопасность и скорость Rust делают его мощным инструментом для Ethereum. Приведет ли R55 к волне разработчиков на Rust для Ethereum? Возможно, сейчас рано говорить наверняка, но это определенно стоит отслеживать. [src[15]]

Dave Rauchwerk[16]: @VitalikButerin Отличная идея. Ключевое преимущество RISC-V — его четкая масштабируемость. Нам следует изучить определение набора пользовательских инструкций RISC-V, специально предназначенных для ускорения фундаментальных и критически важных для производительности операндов EVM. Открытость RISC-V позволяет использовать специализированное аппаратное обеспечение (ASIC, FPGA) помимо выполнения на универсальных CPU. Это открывает путь для значительного увеличения TPS L1 путем прямого ускорения базовой логики EVM на кристалле, достигая скорости, которая может быть на несколько порядков выше текущих методов программной интерпретации или JIT.

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

Кроме того, следует провести бенчмаркинг существующей реализации EVM с потенциальной программной моделью RISC-V. revive/PolkaVM выглядит потрясающе — пока он настроен только на RV32EM, но определенно заслуживает обсуждения. [src[17]]

Koute[18] (руководитель PolkaVM в Parity Technologies[19]): Раз уж зашла речь о PolkaVM, я подробно объясню, что это такое и как это работает.

PolkaVM в настоящее время поддерживает riscv64emac с расширением Zbb. Однако, в отличие от большинства (или всех?) других RISC-V ВМ, он не может напрямую исполнять бинарные файлы RISC-V (фактически, это не настоящая RISC-V ВМ!). Оффлайн мы извлекаем стандартные бинарные файлы RISC-V ELF, собранные обычным компилятором, а затем преобразуем их в более ограниченный и эффективный кастомный байткод, специально спроектированный для использования ВМ (а не нативного железа, как RISC-V). Наша идея — минимизировать сложность самой ВМ (которая должна выполняться ончейн), переложив максимум сложности на оффлайн-инструменты (работающие оффчейн), и повысить безопасность за счет удаления ненужных функций (например, в исходном RISC-V можно перейти по любому адресу; в байткоде PolkaVM пространство адресов кода полностью виртуализировано, переход невозможен, и байткод вообще не загружается в память, доступную программе).

Что касается производительности, мы очень близки к производительности голого железа[1]; она сопоставима с современными WASM ВМ * (wasmtime), но гарантирует O(n) времени перекомпиляции и ускоряет перекомпиляцию программы в нативный код в сотни раз. Конкретнее, перекомпиляция программы из исходного байткода PolkaVM в нативный код происходит значительно быстрее, чем кэширование артефактов перекомпиляции и поиск по их хешу (другими словами, перекомпиляция программы занимает меньше времени, чем вычисление её хеша), и при этом это * не жертвует производительностью выполнения во время работы.

Мы в основном используем RISC-V не потому, что это отличный байткод для ВМ (на самом деле он таковым не является), а потому, что он прост, хорошо поддерживается и относительно легко конвертируется во что-то другое. Так мы получаем лучшее из двух миров — отличную совместимость с ПО (вы можете использовать существующие компиляторы и языки программирования, например, в недавнем порте Quake на PolkaVM), но также получаете преимущества кастомного, оптимизированного байткода (экстремально высокая скорость компиляции, производительность, близкая к нативной, простота и гибкость). [src[20]]

dilrong[21]: @VitalikButerin утверждает, что замена виртуальной машины Ethereum (EVM) на RISC-V повысит эффективность доказательств с нулевым разглашением (ZK) в 50–100 раз. Однако, действительно ли RISC-V превосходит всё остальное? EVM стабильно работала около девяти лет и является проверенной платформой, тогда как опыт практического применения RISC-V в средах исполнения блокчейна пока ограничен. Хотя PolkaVM уже использует RISC-V, я считаю, что он недостаточно проверен, поскольку еще не прошел тщательного аудита и тестирования в основной сети.

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

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

Хотя переход на RISC-V может принести определенные преимущества, я считаю, что улучшение ZK-EVM и оптимизация текущей EVM представляют собой более практичные и стабильные альтернативы. [src[22]]

Eduardo Bart[23] (Core Developer ВМ Cartesi[24]): Будучи разработчиком, активно участвующим в создании виртуальной машины Cartesi Machine[25] для блокчейн-приложений на базе RISC-V, я хотел бы поделиться несколькими аргументами в пользу изучения RISC-V на уровне исполнения Ethereum.

Я думаю, одно из главных преимуществ внедрения RISC-V — немедленный доступ к зрелым инструментам и экосистеме. Не нужно строить полностью кастомную среду: использование RISC-V позволяет разработчикам (и ядру протокола) в полной мере пользоваться десятилетиями накопленным опытом компиляторов (GCC, LLVM), отладчиков, библиотек и даже целых ОС (Linux). По сравнению с новыми, недокаченными тулчеинами это значительно снижает порог входа и может снизить риски багов в компиляторах. Это прекрасно ложится на цель allow контрактам, написанным на Rust или даже C++, компилироваться через стандартный бэкенд для таргетинга на Ethereum. Для тех, кто опасается багов в LLVM или GCC, существует возможность усилить безопасность использованием формально верифицированных компиляторов вроде CompCert[26], которые в настоящее время поддерживают таргетинг на RISC-V. В более глобальном масштабе возможно даже запускать приложения поверх ВМ, покрывающей спецификацию привилегированного ISA RISC-V (подобно той, что я разрабатываю) на сертифицированном ядре ОС RISC-V (например, seL4[27]), что открывает перспективы для сложных приложений, требующих среды ОС.

Обеспокоенность некоторых по поводу производительности обоснована, но решаема. Мой опыт показывает, что при правильной реализации RISC-V не приносит жертв в производительности исполнения. Хотя операции с u256 естественно раскладываются на несколько инструкций, на практике в хорошо оптимизированной RISC-V ВМ стоимость такого разбиения в большинстве случаев не окажет сильного влияния на производительность. Кроме того, методы оптимизации на уровне ВМ способны существенно снизить эти накладные расходы, поскольку ISA RISC-V обладает достаточной расширяемостью для добавления кастомных расширений под блокчейн, что позволяет оптимизировать типичные криптографические операции (например, Keccak256).

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

Путь сложен, но я уверен, что потенциальные преимущества RISC-V в масштабируемости, зрелости инструментов и долгосрочной поддержке делают его весьма перспективным направлением для сред исполнения блокчейна будущего. Уже множество существующих в индустрии RISC-V ВМ доказывают, что устойчивые и готовые к продакшену реализации возможны. В частности, Cartesi Machine демонстрирует мощь использования стандартного открытого ISA. Это стабильный, высокопроизводительный эмулятор RISC-V, реализующий стандартный ISA RV64GC, способный запустить весь стек ПО Linux и неискаженные бинарные файлы RV64GC ELF. Важно отметить, что оно абсолютно детерминировано, включая операции с плавающей запятой. Тем, кто хочет проверить его возможности, рекомендую эксперименты с моим WebCM[28] — это серверлес-терминал, который непосредственно в браузере запускает виртуальный Linux путем симуляции RISC-V машины, движимой эмулятором Cartesi Machine, скомпилированным в WebAssembly.

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

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

Что касается стратегии внедрения, я считаю, что стоит серьезно рассмотреть «радикальный подход» — определить протокол, интегрирующий концепцию интерпретатора ВМ, скомпилированного в RISC-V. Такой подход откроет путь, позволяющий базовой RISC-V ВМ Ethereum оставаться минимизированной и простой, но при этом достаточно гибкой для размещения различных интерпретаторов ВМ вне EVM, предоставляя разработчикам больше свободы.

Короче говоря, я уверен, что использование стандарта вроде RISC-V предоставляет колоссальные преимущества в инструментах, знакомстве разработчиков, гибкости и даже потенциале долгосрочного аппаратного ускорения. Мой опыт работы с Cartesi Machine укрепляет убеждение: RISC-V — это мощный и реалистичный фундамент для блокчейн-вычислений следующего поколения, способных к верификации. Я очень воодушевлен тем, что его рассматривают для основного уровня исполнения Ethereum. [src[29]]

Xuejie Xiao[30]: Всем привет, я первоначальный дизайнер и текущий мейнтейнер Nervos CKB-VM. С точки зрения Nervos выбор в пользу CKB-VM продиктован исключительно мышлением от первых принципов: нам нужна была песочница, которая проста, безопасна и быстры, и максимально легковесна для запуска на коммерческих CPU. Практика показала, что набор инструкций CPU — лучший выбор, и среди остальных вариантов выделяется именно RISC-V. Конечно, есть и другие открытые ядра RISC CPU, но, на наш взгляд, RISC-V пользуется наибольшим вниманием, что означает больший приток людей в разработку тулчейна. Для нас это огромное преимущество.

Когда мы обсуждаем EVM против RISC-V, я предлагаю идти дальше: либо сравнивать оба варианта с учетом встроенных прелоадов (precompiles), либо без них. Нельзя сравнивать EVM с прелоадами и RISC-V без них, и наоборот — на мой взгляд, это некорректно. Предположим использование реализации RISC-V на базе JIT или AOT, либо внедрение инструкций AVX: в таком случае мы можем получить производительность, сопоставимую с EVM, использующим RISC-V ВМ без прелоадов.

Насколько нам известно, семь лет назад RISC-V было лучшим решением, и в обозримом будущем оно по-прежнему остается нашим выбором №1. Если кто-то скажет, что RISC-V — это аппаратное решение, пусть так будет. Мы реализовали его чисто программно, и оно идеально соответствует нашим требованиям. В этом смысле мы довольны текущим положением дел и продолжим двигаться по этому пути. [src[31]]

Модератор: CK-Virtual Machine (CKB-VM) — это виртуальная машина на основе набора инструкций RISC-V, используемая для исполнения смарт-контрактов в Nervos CKB, написанная на Rust. Те, кому интересно, могут ознакомиться со статьей @Xuejie Xiao, опубликованной в 2018 году: An Introduction to Nervos CKB-VM[32]. Посмотрите, о чем они думали тогда — отличный материал!

ZKM[33]: План @VitalikButerin по внедрению RISC-V для Ethereum чрезвычайно смел, но зрелость и история MIPS делают его неожиданной сильной стороной — фиксированный набор инструкций, отлично подходящий для ZK-доказательств с низкой задержкой. MIPS обслуживает критические системы уже 40 лет — Ethereum мог бы воспользоваться этой стабильностью, добиться сопоставимого (а то и лучшего) повышения эффективности, снизив риски внедрения непомерно разрекламированного и все еще развивающегося ISA типа RISC-V. Раз MIPS уже проверен временем, зачем ставить на болезненное взросление RISC-V? [src[34]]

WebAssembly (WASM)

@IAmNickDodson: Создан для исполнения произвольного кода в браузерах / изолированных средах. Преимущества: поддержка множества языков/сред, возможность компиляции в нативный код, четкая открытая спецификация, позднее добавление функций тарификации (но с дополнительными накладными расходами). Недостатки: стековая архитектура (исследования показывают более низкую производительность, но это требует критического осмысления), не создан специально для блокчейна, функции тарификации были добавлены позже как заплатка, влияя на производительность, крайне плохой опыт отладки.

Теоретически WASM — хороший вариант, но на практике отладка превращается в ад. Несколько команд, делающих ставку исключительно на WASM, с которыми мы общались, признались, что жалеют об этом. По сравнению с ними RISC-V/MIPS гораздо понятнее, и это, вероятно, причина выбора Succinct/RISC0. [src[35]]

Peter Kieltyka[36] (соучредитель Sequence[37]): @VitalikButerin знаю, это звучит натянуто, но рассмотрите EVM+/Stylus от команды Offchain Labs как будущий уровень исполнения L1. Он полностью совместим с байткодом EVM, выполняется в WASM ВМ и поддерживает любые языки с WASM-поддержкой (например, Rust), обеспечивая значительный прирост производительности и сохраняя полную runtime-совместимость с контрактами EVM. Кажется, это самый простой путь апгрейда без потери совместимости. [src[38]]

Xuejie Xiao[39]: Многие считают WASM идеальным выбором для блокчейнных ВМ, в первую очередь потому, что WASM проектировался для программной реализации (если это имеет смысл, проигнорируем это пока). Знаете ли вы, что до появления WASM некоторое время пользовался популярностью подмножество JavaScript под названием asm.js? Позже asm.js трансформировался в WASM и каким-то образом стал куда масштабнее первоначального замысла asm.js (по моему скромному мнению, сейчас WASM больше напоминает чисто спроектированную JVM, нежели.asm.js). Но не забудем о начальной цели asm.js: люди искали программный IR, который детерминированно отображался бы на нативные инструкции CPU, а не JIT, работающий в 90% случаев. Если RISC-V способен достичь такой цели, я считаю его прекрасным кандидатом на роль программной ВМ. [src[40]]

Hazel Hu[41] (Delphinus Lab[42]): Хотя @VitalikButerin выступает за RISC-V, существует несколько технических маршрутов для ZK-ВМ. ZK-ВМ не является эксклюзивом для ETH; это самостоятельный компонент, потенциально крупнее самой экосистемы ETH. ETH нужны ZKVM, но ZKVM не ограничивается рамками Ethereum. [ src[43]]

Системы ZK используют принципы RISC (Reduced Instruction Set Computing). Здесь есть два пути: первый — создание собственного кастомного ISA, как в специфичном для ZK языке Cairo (слишком крутая кривая обучения); второй — использование готового ISA. Один из них — RISC-V. Проекты ZK ВМ на базе RISC-V включают @RiscZero[44], @SuccinctLabs[45], @NexusLabs[46] и поддерживаемый @a16z[47] Jolt.

Еще в 2018 году в экосистеме Ethereum запустили проект eWASM. Изобретатель EVM @gavofyork[48] заявлял о возможности замены EVM на WASM, а основатель Polygon @sandeepnailwal[49] всегда оставался жестким сторонником WASM. Однако eWASM так и не получил широкого распространения из-за инженерной сложности, смены приоритетов и роста популярности L2-решений; в последующих дорожных картах eWASM был отложен.

После публикации предложения @VitalikButerin, основатель Zebra @shumochu[50] и партнер исследовательского центра 1kx @_weidai[51] и другие указали, что WASM может подходить уровню исполнения Ethereum лучше, чем RISC-V, по следующим причинам:

Упрощенный процесс: RISC-V создавался изначально для аппаратной реализации, а не в качестве промежуточного представления. Если использовать его как уровень исполнения контрактов Ethereum, все равно потребуется построить слой ВМ для обработки потребления газа и контроля потока исполнения, что добавляет сложности.

Благоприятен для статического анализа: В WASM нет инструкций перехода, структура кода проста, что облегчает верификацию свойств контрактов.

Широкая языковая поддержка: Разработчики могут писать программы на большинстве популярных языков и компилировать их в WASM, что сильно снижает порог входа. Основатель Miden @bobbinth[52] дополнительно предложил: если цель — дружелюбность к ZK, можно спроектировать ISA лучше, чем RISC-V, или использовать компонентную модель WASM. [src[53]]

Моя команда в @Delphinuslab[54]开源ила первую в индустрии ZKWASM ВМ. Хотя пока доступен только SDK для Solidity, фактически settlement контрактов ZKVM может происходить на любой цепи, и в будущем её вполне можно интегрировать с Solana, Sui и другими гетерогенными цепями, не относящимися к EVM.

В чем именно заключается польза ZKWASM ВМ?

1. Позволит большему числу разработчиков войти в мир блокчейна на родном для них языке, без принудительного изучения Solidity (и более сложных/нишевых блокчейн-языков) или Rust.

2. Даст возможность массовому Web2.5-микросервисам в виде браузерных виджетов «в один клик» выходить в блокчейн. При полной реализации тысячи браузерных мини-программ смогут быстро деплоиться на цепь.

3. Поможет разорвать «невозможный треугольник», обеспечив баланс между децентрализацией, эффективностью и безопасностью. [src[55]]

x86/ARM

@IAmNickDodson: Оба крупных набора команд CPU не являются открытыми: ARM относится к RISC (Reduced Instruction Set Computer), x86 — к CISC (Complex Instruction Set Computer). По мере эволюции аппаратного обеспечения CPU оба стали невероятно сложными. Примечательно, что хотя в мире CPU CISC постепенно вытесняется RISC из-за своей сложности, в контексте блокчейна CISC демонстрирует большие преимущества. [src[56]]

Xuejie Xiao[57]: x64 слишком тяжеловесен (когда мы впервые пробовали RISC-V, кто-то даже пытался строить блокчейнную ВМ на базе x64!), а с лицензированием Arm ситуация туманна: проблема может существовать, а может и нет. [src[58]]

Bitcoin Script

@IAmNickDodson: Первая блокчейнная ВМ, специально разработанная для программирования в Bitcoin:

Преимущества: Создана специально под блокчейн и модель транзакций Bitcoin, адаптирована к антагонистической среде, поддерживает базовые операции вроде многосигнатурных кошельков.

Недостатки: Функционал крайне ограничен, серьезно зависит от пропускной способности сети Bitcoin.

Из Bitcoin Script мы унаследовали мощный паттерн P2SH (payment to script hash) — условное программирование. Этот обрезкаемый программный паттерн (может быть удален с полного нод после выполнения) поддерживает богатые сценарии: внебиржевые сделки / многосигнатурные кошельки / аукционы товаров. Архитектура Bitcoin подсказывает нам: дизайн ВМ должен быть глубоко синхронизирован с моделью транзакций. [src[59]]

MoveVM

@IAmNickDodson: Специализированная блокчейнная ВМ, разработанная командой Meta, делает упор на безопасность:

Преимущества: Нативный дизайн для блокчейна, поддержка антагонистического газотаксинга, наличие специализированного языка Move.

Недостатки: Ради безопасности пожертвована значительная гибкость состояния, чрезмерная RISC-оптимизация (см. анализ выше), фрагментация экосистемы (несовместимые форки в SUI/Aptos).

Экосистема Move почти замерла в 2020-21 годах. Мы отказались от её внедрения, не желая зависеть от чужой архитектуры, не позволяющей нам инновационно развиваться. А её «безопасность» была скорее упаковкой RISC-системы, не предотвращающей написание плохого кода. Тогдашний формальный верификация применялась лишь к простым функциям, а не к полным приложениям, offering крайне низкую ценность. [src[60]]

EVM

@IAmNickDodson: Можно назвать PHP мира блокчейна, держащей на себе смарт-контракты стоимостью в сотни миллиардов:

Преимущества: Блокчейн-нативный дизайн, совершенный механизм тарификации, полная экосистемная совместимость, отточенный язык Solidity.

Недостатки: Дизайн с 256-битным размером слова, поддержка только вызовов/контрактов без скриптовых возможностей, отсутствие условного программирования (нет аналога P2SH), построена на излишне упрощенной модели транзакций, низкая эффективность (трата вычислений из-за размера слова и дизайна операндов), высоко-стэйтед дизайн делает обращения к хранилищу узким местом производительности.

Хотя отдельные команды утверждают, что решают проблему через новые базы данных или схемы доступа к состоянию, по сути эти вычисления могли бы быть избежаны. EVM отлично подходит для быстрого создания экосистемы, но с точки зрения модели транзакций и пространства дизайна проявляет недостаток инноваций. Возможно, обращение Виталика именно это и отражает. [src[61]]

Alex Vlasov[62]: Пока непонятно, действительно ли RISC-V лучше EVM. EVM стековая, поэтому её файл регистров мал. EVM оперирует 256-битными числами, что может стать проблемой, если доминируют значительно меньшие значения. Однако доказатель может обращаться к реальному трассу выполнения и выбирать более легкие варианты реализации для малых значений (например, байтовая декомпозиция 32-битного значения занимает меньше строк в доказательстве, чем 256-битного). [src[63]]

Другой аспект — стоимость формальной верификации смарт-контрактов. ISA EVM менее ограничен, чем RISC-V, поэтому F/V в целом сложнее. Контракты RISC-V обычно содержат больше циклов и операций с памятью, что создает трудности для F/V.

Например, исследование (/www.cs.utexas.edu/~isil/solis.pdf[64]) показывает, что около пятой части контрактов EVM содержит один или несколько циклов. Поскольку EVM оперирует 256-битными значениями, в коде RISC-V потребуется больше циклов. Даже при раскрытии цикла это приводит к более массивным SMT-запросам.

RISC-V имеет более насыщенные модели памяти, предполагающие больше операций с памятью (например, 1024 стэковых слотов по 256 бит в EVM против 16-32 регистров 32/64 бит в RISC-V). Следовательно, алиасинг (когда два синтаксически разных выражения ссылаются на одну ячейку памяти) станет серьезнее. Это осложнит статический анализ, включая реконструкцию графа вызовов и псевдоним-анализ.

Я предполагаю, что формальный вывод для контрактов RISC-V с циклами/алиасингом будет сложнее, чем для контрактов EVM. [src[65]]

SVM

@IAmNickDodson: Виртуальная машина Solana набирает обороты в последние годы:

Преимущества: Блокчейн-нативный дизайн, поддержка антагонистического газотаксинга, возможность компиляции в нативный код, высокопроизводительный дизайн.

Недостатки: Сложная и трудная для понимания архитектура, плохой опыт разработки на Rust и подобных языках, отсутствие зрелого специализированного языка.

Мы не выбрали SVM главным образом из-за предположений в его модели транзакций — простое проектирование, похожее на Ethereum, ставит акцент на скорости, а не на сложных взаиморасчетах, что расходится с нашей целевой моделью. [src[66]]

CairoVM

Akash Balasubramani (менеджер экосистемы StarkWare): @IAmNickDodson, блестящий анализ! Было бы здорово, если бы вы включили CairoVM. [src[67]]

@IAmNickDodson: Не включил только потому, что во время исследований 2020/21 годов оно еще не попало в наше поле зрения. Я преданный фанат Cairo и технологии STARK. [src[68]]

Eli Ben-Sasson (соучредитель StarkWare): @IAmNickDodson, отличная дискуссия! Единственный совет — добавить анализ Cairo. Позвольте мне дополнить: Преимущества: спроектировано специально для блокчейна и эффективности zkSTARK, линейная безопасность типов, эффективный расчет газа (Sierra). Недостатки: меньшая узнаваемость / неполноценность тулчейна :) [src[69]]

Модератор: Спасибо всем за блестящие комментарии. Каковы же ваши итоговые выводы? Какие инсайты вы хотели бы поделиться с нами?

@IAmNickDodson: Проработав все ВМ, мы поняли: сама по себе важность виртуальной машины переоценена. Теоретически все эти ВМ (кроме BitcoinScript) могут выполнить нужные вычисления с разной эффективностью. Настоящая ключевая вещь — это скоординированный дизайн ВМ и модели транзакций. Многие сети слишком зацикливаются на ВМ, игнорируя модель транзакций, которая и определяет суть блокчейнного поведения. [src[70]]

Именно в этом заключается уникальность FuelVM, вот комплексные оптимизации FuelVM [src[71]]:

• Эффективность памяти (общие контексты памяти уменьшают копирование)

• Интеллектуальное использование регистров и памяти (например, помещение всей транзакции в видимую память для runtime-саморефлексии)

• Минимизация обращений к IO до предела

• Усиление возможностей слоя транзакций (транзакции берут больше нагрузки, ВМ берет меньше)

• Модель транзакций сочетает доступ к состоянию с возможностью мульти-активных / мульти-условных / мульти-режимных потоков выполнения

• Золотая середина между CISC и RISC

• Отсутствие глобального дерева состояний (модель UTXO по умолчанию предотвращает двойное расходование через исторический трейлинг)

• Все операнды оптимизированы для эффективности газотаксинга

• Поддержка разнообразных типов программ, таких как предикатное условное программирование

• Соответствующий язык Sway сочетает производительность Rust с UX разработки Solidity

Традиционное мнение считает, что блокчейнные ВМ должны стремиться к максимальной минималистичности инструкций (в целях безопасности и компиляции в нативный код). Но проблема в том, что в сценариях оптимистичной проверки каждое действие требует тарификации. Чем проще ВМ, тем больше операндов нужно для реализации одной функции, тем выше нагрузка на ончейн-расчеты газа. Поэтому FuelVM решает задачу путем создания большего числа высокоэффективных операндов — делать больше с помощью меньшего числа действий. FuelVM можно считать синтезом CISC и RISC. Хотя большее число инструкций обычно увеличивает объем байткода (что может влиять при ограниченной полосе пропускания, но сжатие помогает), это значительно снижает накладные расходы газотаксинга в оптимистичных проверках и предоставляет разработчикам более мощные инструменты. Даже в сценариях ZK composite-операнды дают лучшие результаты оптимизации. Простота ≠ Лучше. [src[72]]

Модератор: Хотите ли вы что-нибудь сказать инженерам, выбирающим другие технологические стеки ВМ? Например, команде Ethereum :)

@IAmNickDodson: Если Ethereum выберет путь RISC, ему обязательно需要同步 пересмотреть модель транзакций. ВМ — лишь часть головоломки. RISC-V сам по себе не решит вопросы учета токенов, нарушения парадигмы смарт-контрактов или создания высокопроизводительных блокчейнных приложений для людей и роботов. Fuel выбрал поступать правильно, а не модно, что означает постоянную боль (достаточно взглянуть на наш токен), но также предлагает новый дизайн-паттерн для open-source блокчейн-экосистем.

Если вы планируете создать блокчейн и вам нужна архитектура, глубоко соответствующая сути блокчейна, FuelVM/Sway определенно стоит рассмотреть. Производительность просто невероятная: 150 тысяч TPS на процессоре M4, 10 мс на мягкое подтверждение, работает от тостеров до суперкомпьютеров. Узнать больше про FuelVM можно здесь: Why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain[73]

Xuejie Xiao[74]: Еще один момент касательно ZK. Прежде всего, это лишь мое личное видение. У RISC-V есть два различных кейса, связанных с нуля-разглашением: 1) ВМ / IR для репрезентации программ, которые будут доказываться ZK, и 2) базовая платформа для выполнения ZK-валидаторов. Простая, хотя и неточная аналогия: над алгоритмом ZK-доказательств работает одна ВМ (пункт 1), а под ним — другая ВМ (пункт 2). Их следует обсуждать отдельно.

Nervos CKB-VM использует строгий дизайн без прекомпилов, идеально попадая во второй пункт: вы можете скомпилировать код валидатора ZK в RISC-V и запустить этот валидатор на Nervos CKB-VM. В этом смысле Nervos CKB сможет гибко поддерживать любые ZK-решения. Иными словами, я считаю Nervos CKB-VM отличным выбором для ВМ, работающей под ZK-алгоритмами.

Первый пункт выступает как отдельный кейс. Я плохо знаком с внутренними механизмами доказательств ZK, поэтому не могу утверждать, является ли RISC-V подходящим решением. Мне кажется, некоторые особенности алгоритмов ZK могут влиять на выбор ВМ для работы над алгоритмами доказательств.

Возможно, я ошибаюсь, но мне кажется, что @VitalikButerin здесь говорит именно о втором пункте, или о надлежащей ВМ под ZK-алгоритмами. Может, нам и не стоит спорить, подходит ли RISC-V под ZK-доказательства?

porter | ZKsync[75]: ZKsync готов к следующим изменениям: новая доказательная система Boojum2 уже на базе RISC-V. Несколько вещей принесут пользу всему Ethereum (не только ZKsync): скоро выйдет совершенно новый компилятор Solidity->LLVM->RISC-V. [src[76]]

@alacheng[77]: В направлении ZK (если при масштабировании L1 валидация узлов не требует повторного выполнения, то данные zkvm заменят zkevm). @SuccinctLabs[78] и @RiscZero[79] — оба zk risc-v vm. @UntoLabs[80] создало цепь из核心团队 sol-экосистемы, где exec-layer vm является risc-v vm. [src[81]]

Модератор: Огромное спасибо всем участникам за блестящие выступления. На этом наш «виртуальный круглый стол» завершается. Из-за ограничений по времени и объему мы не смогли представить все уникальные ВМ. Возможно, в будущем я подготовлю продолжение или вторую серию. Если зрителей интересуют подробности, пожалуйста, кликайте на [src] в конце каждого комментария/выступления.

Заключение

В ходе этого «виртуального круглого стола» мы увидели, как различные блокчейн-проекты выбрали принципиально разные технологические пути: EVM стремится к экосистемной совместимости, RISC-V концентрируется на аппаратной эффективности, WASM принимает полиязычную разработку, MoveVM делает упор на безопасность активов, а FuelVM пробивает границы производительности. Это наглядно демонстрирует, что в мире блокчейнов не существует универсального оптимального решения, есть лишь поиск наилучшего баланса для достижения конкретных целей.

Через эту техническую дискуссию мы можем увидеть:

• Выбор Ethereum сделать консервативный апгрейд обусловлен приоритетом ценности экосистемы

• Решение Nervos выбрала RISC-V рождено из крайнего стремления к дружбе с железом

• Ставка Aptos/Sui на MoveVM отражает почти маниакальный фокус на безопасности

• Fuel нашел свой собственный путь, преодолевая узкие места производительности через гибридную архитектуру

За всеми этими выборами стоят разные ответы команд на вопрос «чем должен быть блокчейн». Понимание логики этих технических решений, вероятно, ценнее споров о том, что лучше, — это позволяет нам увидеть истинное разнообразие отрасли и предвкушает перспективное цветущее многообразие Web3 в будущем. Захватывающе, верно?

Отказ от ответственности

Содержание данной статьи представляет собой агрегацию и реструктуризацию открытых технических обсуждений, предназначенных для объективного сравнения и анализа современных популярных технологий виртуальных машин Web3. Все упомянутые в тексте проекты, технологические решения и продукты (включая, но не ограничиваясь EVM, RISC-V, WASM, MoveVM, FuelVM и т.д.) собраны на основе публичных обсуждений сообщества разработчиков и отражают исключительно личные мнения соответствующих выступающих, не представляя позицию автора статьи или платформы публикации.

Информация для читателей:

1. Технический нейтралитет: Обсуждение виртуальных машин в статье носит исключительно технический характер и не является рекомендацией или одобрением каких-либо проектов, токенов или продуктов;

2. Срок актуальности: Технологии блокчейна развиваются быстро, информация в статье собрана на основе открытых источников за 2025 год, реальное развитие могло уже измениться;

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

4. Не инвестиционный совет: Содержание данной статьи никоим образом не является инвестиционным советом, и любой технический анализ не должен служить основой для инвестиций.

Технология блокчейна находится в стадии быстрого развития, и любой технический выбор должен оцениваться исходя из конкретных сценариев применения. Мы поощряем читателей самостоятельно формировать суждения, опираясь на первичную информацию, такую как официальная документация проектов и аудиты.

Авторские права

Содержание данной статьи было собрано, агрегировано и переработано на основе открытых материалов Интернета (включая, но не ограничиваясь техническими форумами, социальными сетями, документами разработчиков и т.д.). Для поддержания связности повествования и удобства чтения редакция внесла в исходный материал следующие изменения:

1. Редактирование контента: Включая, но не ограничиваясь цитированием мнений, извлечением ключевых фраз,重组 абзацев и необходимым использованием контекста вне контекста, некоторые части могут содержать потерю связи с предыдущим контекстом;

2. Языковой перевод: Материалы, переведенные с английского на китайский или наоборот, могут содержать смысловые отклонения или различия в формулировках и не являются дословным переводом;

3. Упрощение терминологии: Некоторые профессиональные термины или технические описания были адаптированы для более широкой аудитории, что могло привести к потере исходной точности.

Важное примечание:

• Все мнения и технические рассуждения подлежат окончательному толкованию исключительно их авторами, поэтому необходимо опираться на содержание исходных ссылок [src], указанных в конце каждого комментария;

• Данная статья опубликована без предварительного согласия упомянутых проектных команд, технических групп или выступающих и служит исключительно в качестве благотворительного сбора материалов для технического обсуждения;

• Если материалы вызывают вопросы в отношении формулировок, наличия авторских споров или подозрений в нарушении прав, пожалуйста, свяжитесь с @OpenBuildxyz[82] для своевременного уведомления, мы незамедлительно проверим и исправим.

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