Полный текст долгосрочного предложения Виталика по исполнительному уровню L1: замена EVM на RISC-V

Источник: Виталик Бутерин

Компиляция: KarenZ, Форсайт-новости

20 апреля Виталик Бутерин представил важное предложение по платформе Ethereum Magicians для долгосрочного уровня исполнения L1 Ethereum. Он предложил заменить существующую EVM (виртуальную машину Ethereum) на архитектуру RISC-V в качестве языка виртуальных машин для написания смарт-контрактов, стремясь коренным образом повысить операционную эффективность уровня исполнения Ethereum, преодолеть одно из текущих основных узких мест масштабирования и значительно упростить уровень выполнения.

Издание Foresight News собрало полный текст предложения, чтобы помочь читателям понять это техническое видение. Ниже приводится компиляция первоначального предложения:

В этой статье представлена радикальная идея о будущем уровня исполнения Ethereum, не менее амбициозная, чем инициативы Beam Chain уровня консенсуса. Предложение направлено на то, чтобы значительно повысить эффективность уровня исполнения Ethereum, устранить одно из основных узких мест масштабирования и значительно упростить уровень исполнения — на самом деле, это может быть единственным способом достичь этого.

Основная идея: заменить EVM на RISC-V в качестве языка виртуальных машин для смарт-контрактов.

Важные примечания:

• Такие концепции, как система учетных записей, кросс-контрактные звонки, хранение и т. д., будут полностью сохранены. Эти абстрактные конструкции хорошо работают, и разработчики привыкли их использовать. ТАКИЕ КОДЫ ОПЕРАЦИЙ, КАК SLOAD, SSTORE, BALANCE, CALL И Т. Д., ПРЕОБРАЗУЮТСЯ В СИСТЕМНЫЕ ВЫЗОВЫ RISC-V.

• В этом режиме смарт-контракты могут быть написаны на Rust, но я ожидаю, что большинство разработчиков продолжат писать контракты на Solidity (или Vyper), который будет адаптироваться к RISC-V в качестве нового бэкенда. Потому что смарт-контракты, написанные на Rust, на самом деле менее читабельны, в то время как Solidity и Vyper более понятны и просты для чтения. Опыт разработки может быть практически не затронут, а разработчики могут даже не заметить изменения.

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

Nervos CKB VM создала прецедент и по сути является реализацией RISC-V.

Почему?

В краткосрочной перспективе предстоящие EIP (например, списки доступа на уровне блоков, отложенное выполнение, распределенное хранение истории и EIP-4444) устранят основные узкие места масштабирования Ethereum L1. В среднесрочной перспективе будет решено больше проблем с безгражданством и ZK-EVM. В долгосрочной перспективе основными ограничивающими факторами для масштабирования Ethereum L1 станут:

1. Стабильность протоколов доступности данных, выборки и архивного хранения

2. Поддержание спроса на конкуренцию на рынке производства блоков

3. Доказательство использования ZK-EVM

Я покажу, что замена ZK-EVM на RISC-V может решить ключевые узкие места в (2) и (3).

В следующей таблице показано количество циклов, необходимых для каждого шага уровня выполнения Squinct ZK-EVM Proof EVM:

Описание диаграммы: Четыре основных сегмента, отнимающих много времени: deserialize_inputs, initialize_witness_db, state_root_computation и block_execution

initialize_witness_db и state_root_computation связаны с деревьями состояний, и deserialize_inputs включают в себя процесс преобразования блочных и следящих данных во внутренние представления, более 50% которых фактически пропорционально размеру следящих данных.

Эти разделы можно значительно оптимизировать, заменив текущее 16-аренное дерево Меркла Патриция кеччака на двоичное дерево, использующее легко доказуемую хеш-функцию. Если мы используем Poseidon, мы можем доказать 2 миллиона хешей в секунду на ноутбуке (по сравнению с примерно 15 000 хешей в секунду для keccak). Кроме Посейдона, есть много других вариантов. В целом, для этих компонентов есть много возможностей для оптимизации. Кроме того, мы можем устранить accrue_logs_bloom, удалив налет.

На оставшуюся block_execution приходится около половины текущих циклов доказыва. Чтобы добиться 100-кратного увеличения общей эффективности proof, требуется эффективность проверки EVM не менее 50x. Одно из решений заключается в создании более эффективной реализации доказательства для EVM, а другое — в том, чтобы заметить, что текущий анализатор ZK-EVM фактически компилирует EVM в RISC-V для доказательства, предоставляя разработчикам смарт-контрактов прямой доступ к виртуальной машине RISC-V.

Некоторые данные показывают, что повышение эффективности более чем в 100 раз может произойти в определенных ситуациях:

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

(Стоит отметить, что время, затрачиваемое на «операции EVM» и «другие операции» при обычном выполнении EVM, также близко к 50/50, поэтому мы интуитивно предполагаем, что удаление EVM в качестве «промежуточного уровня» принесет столь же значительный выигрыш.)

Детали реализации

Есть несколько путей реализации этого предложения. Наименее разрушительное решение — поддерживать обе виртуальные машины и разрешить написание контракта на одной из них. Оба типа контрактов имеют доступ к одним и тем же функциям: постоянному хранению (SLOAD/SSTORE), возможности хранить балансы ETH, инициировать/принимать звонки и многое другое. Контракты EVM и RISC-V могут вызываться друг к другу - с точки зрения RISC-V, вызов контракта EVM эквивалентен выполнению системного вызова со специальными параметрами; Контракт EVM, получивший сообщение, интерпретирует его как CALL.

Более радикальный подход с точки зрения протокола заключается в преобразовании существующего контракта EVM в вызов контракта интерпретатора EVM, написанного на RISC-V, для выполнения существующего кода EVM. То есть, если контракт EVM имеет код C и интерпретатор EVM находится по адресу X, то контракт будет заменен на логику верхнего уровня, которая при вызове извне с аргументом вызова D, вызывает X и передает (C, D), а затем ожидает возвращаемого значения и пересылает данные. Если интерпретатор EVM сам вызывает контракт, прося запустить CALL или SLOAD/SSTORE, то контракт выполняет эти операции.

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

Основное преимущество второго и третьего вариантов заключается в том, что они значительно упрощают спецификацию уровня выполнения. УЧИТЫВАЯ СЛОЖНОСТЬ ДАЖЕ УДАЛЕНИЯ ТАКИХ ПОСТЕПЕННЫХ УПРОЩЕНИЙ, КАК САМОУНИЧТОЖЕНИЕ, ЭТОТ ХОД МЫСЛЕЙ МОЖЕТ БЫТЬ ЕДИНСТВЕННЫМ ЖИЗНЕСПОСОБНЫМ ПУТЕМ ДЛЯ УПРОЩЕНИЯ. Tinygrad придерживается жесткого правила «не более 10 000 строк кода», и оптимальный блокчейн, лежащий в основе, должен быть в состоянии легко уложиться в этот лимит и оптимизировать его дальше. Инициатива Beam Chain обещает значительно упростить уровень консенсуса Ethereum, и такое радикальное изменение может быть единственным способом добиться аналогичного роста на уровне исполнения.