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

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

Важные пояснения:

• Концепции учетных записей, вызовов между контрактами, хранения и т. д. останутся точно такими же. Эти абстракции работают хорошо, и разработчики привыкли к ним. Опкоды вроде SLOAD, SSTORE, BALANCE, CALL и т. д. станут системными вызовами RISC-V.
• В таком мире смарт-контракты могут быть написаны на Rust, но я ожидаю, что большинство разработчиков будут продолжать писать смарт-контракты на Solidity (или Vyper), которые адаптируются для добавления RISC-V в качестве бэкенда. Это потому что смарт-контракты, написанные на Rust, на самом деледовольноуродливый, и Solidity и Vyper - многобольшечитаемыйПотенциально devex изменится совсем немного, и разработчики могут едва заметить изменения.
• Старые контракты EVM будут продолжать работать и будут полностью двусторонне совместимы с новыми контрактами RISC-V. Есть несколько способов сделать это, о чем я расскажу позже в этом посте.

Один прецедент для этого - Nervos CKB VM, который в основном RISC-V.

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

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

1. Стабильность протоколов выборки доступности данных и хранения истории
2. Желание сохранить производство блоков конкурентным рынком
3. ZK-EVM доказательственные возможности

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

Это таблица количества циклов, которые Succinct ZK-EVM использует для доказательства различных частей уровня выполнения 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). Есть также много вариантов, кроме Poseidon. В целом, есть возможности массово сократить эти компоненты. В качестве бонуса мы можем избавиться от accrue_logs_bloom, ну, избавление от цветения.

Остается выполнение блока, которое занимает примерно половину циклов доказателя, затраченных сегодня. Если мы хотим увеличить общую эффективность доказателя в 100 раз, нет обхода факта, что нам нужно как минимум 50 раз увеличить эффективность доказателя EVM. Одно из того, что мы могли бы сделать, это попытаться создать реализации EVM, которые намного более эффективны с точки зрения циклов доказателя. Другое, что мы можем сделать, это заметить, что доказатели ZK-EVM сегодня уже работают, доказывая реализации EVM, скомпилированные до RISC-V, и предоставляют разработчикам смарт-контрактов прямой доступ к этому RISC-V VM.

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

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

(Кстати, приблизительно 50/50 разделение между “EVM” и “другие вещи” также появляется в обычном выполнении EVM, и мы интуитивно ожидаем, что выгоды от удаления 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 имеет жесткое правило никогда не превышая 10000 строк кода; оптимальный базовый уровень блокчейна должен хорошо вписываться в эти рамки и становиться еще более компактным. Усилия по созданию цепочки Beam обещают значительно упростить уровень консенсуса Ethereum. Но для того чтобы уровень исполнения получил аналогичные выгоды, этот радикальный подход может быть единственно возможным путем.

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

1. Эта статья взята из [ Ethereum Маги]. Все авторские права принадлежат оригинальному автору [Виталик Бутерин]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь Gate Learnкоманда, и они незамедлительно этим займутся.
2. Ответственность за отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Команда Gate Learn занимается переводом статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.