Разработчики опровергают Виталика: предположения неверны, и RISC-V — не лучший выбор

Эта статья от: Сборник разработчиков Ethereum levochka.eth

|Odaily Planet Daily (@OdailyChina); @azuma_eth Примечание редактора

:

Вчера соучредитель Ethereum Виталик выпустил радикальную статью об обновлении уровня исполнения Ethereum (см. статью "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the future), упомянув, что надеется заменить его на RISC-V EVM как язык виртуальных машин для смарт-контрактов.

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

Ниже приведена оригинальная статья на сайте levochka.eth, составленная ежедневной газетой Odaily.

Пожалуйста, не делайте этого.

Этот план не имеет смысла, потому что вы делаете неправильные предположения о проверке системы и ее производительности.

Гипотеза валидации

Насколько я понимаю, основными аргументами в пользу этой схемы являются «масштабируемость» и «удобство сопровождения».

Во-первых, я хочу поговорить о ремонтопригодности.

На самом деле, все RISC-V zk-VM требуют «предварительной компиляции» для обработки ресурсоемких операций. Предварительно составленный список SP 1 можно найти в документации Succinct, и вы обнаружите, что он охватывает почти все важные «вычислительные» опкоды в EVM.

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

Действительно, если производительность достаточно хороша, может быть относительно легко выполнить обслуживание «не-EVM» части клиента. Я не уверен, достаточно ли это хорошо, но я менее уверен в этой части по следующим причинам:

• "вычисление дерева состояний" действительно может быть значительно ускорено с помощью дружественной предварительной компиляции, такой как Poseidon.

• Тем не менее, неясно, можно ли «десериализацию» обрабатывать элегантным и удобным в обслуживании способом.
  

• Кроме того, есть некоторые сложные детали (такие как учет газа и различные проверки), которые могут подпадать под «время оценки блока», но на самом деле должны быть классифицированы как «не-EVM» детали, которые, как правило, более уязвимы к давлению технического обслуживания.

Во-вторых, часть о масштабируемости.

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

Таким образом, утверждение в оригинальном тексте о том, что "время окончательного доказательства будет определяться текущей операцией прекомпиляции", технически верно, но оно чрезмерно оптимистично - оно предполагает, что в будущем прекомпиляции не будет, тогда как на самом деле (в этом будущем сценарии) прекомпиляция все еще будет существовать, и это точно то же самое, что и ресурсоемкие опкоды в EVM (такие как подписи, хеши и, возможно, большие аналоги).

Трудно судить о примере с Фибоначчи, не вдаваясь в самые тонкие детали, но преимущества проявляются, по крайней мере, отчасти:

• разница между интерпретацией и накладными расходами на исполнение;

• Циклическая раскрутка (уменьшение "потока управления" RISC-V, неясно, может ли быть реализован Solidity, но даже один опкод все равно может генерировать большое количество обращений к потоку управления/памяти из-за накладных расходов на интерпретацию);

• использовать меньшие типы данных;

Здесь я хотел бы отметить, что для того, чтобы реализовать преимущества пунктов 1 и 2, необходимо устранить «накладные расходы на интерпретацию». Это соответствует философии RISC-V, но это не тот RISC-V, который мы сейчас обсуждаем, а скорее похожий "(?)RISC-V" - он требует определенных дополнительных возможностей, таких как поддержка контрактных концепций.

Вот в чем проблема

, значит, здесь есть некоторые проблемы.

• Чтобы улучшить удобство обслуживания, вам нужен RISC-V (с предварительной компиляцией), который компилирует EVM - вот и все.

• Чтобы улучшить масштабируемость, необходимо нечто совершенно иное — новая архитектура, которая может быть похожа на RISC-V, которая понимает концепцию «контрактов», совместима с ограничениями времени выполнения Ethereum и может выполнять код контракта напрямую (без «накладных расходов на интерпретацию»).

Теперь я предполагаю, что вы имеете в виду второй случай (поскольку остальная часть статьи, кажется, подразумевает это). Хочу обратить ваше внимание на то, что весь код за пределами этой среды по-прежнему будет написан на актуальном языке RISC-V zkVM, что оказывает существенное влияние на сопровождение.

В качестве альтернативы

мы можем скомпилировать байт-код из высокоуровневого опкода EVM. Компилятор отвечает за то, чтобы сборщик оставался инвариантным, например, не испытывал «переполнения стека». Я бы хотел, чтобы это было показано в обычном EVM. Правильно составленные SNARK могут быть снабжены инструкциями по развертыванию контракта.

Мы также можем построить «формальное доказательство», которое докажет, что некоторые инварианты сохраняются. Насколько я могу судить, этот подход (не «виртуализация») использовался в некоторых браузерных контекстах. Генерируя SNARK этого формального доказательства, вы можете достичь аналогичных результатов. 

Конечно, самый простой вариант – стиснуть зубы и сделать ......

Создание минимально «цепного» MMU

, что вы можете неявно выразить в статье, но позвольте мне предупредить, что если вы хотите устранить накладные расходы на виртуализацию, вам придется выполнять скомпилированный код напрямую, а это означает, что вам нужно каким-то образом запретить контракту (теперь исполняемому) записывать данные в память ядра (не реализации EVM).

Поэтому нам нужен некий «блок управления памятью» (MMU). Механизм пейджинга традиционных компьютеров может быть не нужен, потому что пространство «физической» памяти почти бесконечно. Этот MMU должен быть как можно более компактным (потому что он находится на том же уровне абстракции, что и сама архитектура), но некоторые функции, такие как атомарность транзакций, могут быть перенесены на этот слой.

На этом этапе доказуемая EVM становится программой ядра, работающей на этой архитектуре.

Интересно

, что во всех этих условиях лучшей «архитектурой набора инструкций» (ISA) для этой задачи может быть не RISC-V, а что-то похожее на EOF-EVM по следующим причинам:

• «Маленькие» коды операций на самом деле приводят к большому доступу к памяти, что трудно эффективно обрабатывать существующими методами аттестации.

• Чтобы уменьшить накладные расходы на ветвление, мы показали, как доказать код «статических скачков» (EOF) с производительностью на уровне предварительной компиляции в нашей недавней статье Morgana.

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