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

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

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

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

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

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

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

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

Зачем это делать?

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

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

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

Описание диаграммы: четыре основных этапа, требующих много времени, — это deserialize_inputs, initialize_witness_db, state_root_computation и block_execution.

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

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

Оставшиеся block_executions составляют около половины текущих циклов проверки. Чтобы достичь 100-кратного повышения общей эффективности доказательства, эффективность доказательства EVM необходимо увеличить как минимум в 50 раз. Одним из решений является создание более эффективной реализации доказательства для 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, который получает сообщение, интерпретирует его как ВЫЗОВ.

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

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

Основное преимущество второго и третьего вариантов заключается в том, что они значительно упрощают спецификацию уровня исполнения. Учитывая, что даже постепенное упрощение, такое как удаление SELFDESTRUCT, затруднительно, этот подход может оказаться единственным жизнеспособным путем упрощения. Tinygrad следует жесткому правилу « не более 10 000 строк кода », и оптимальный базовый уровень блокчейна должен быть способен легко соответствовать этому ограничению и еще больше его оптимизировать. Проект Beam Chain обещает значительно упростить уровень консенсуса Ethereum, и это радикальное изменение может оказаться единственным реальным путем к достижению аналогичных улучшений на уровне исполнения.