Новое предложение Виталика: заменить текущую EVM на RISC-V

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

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

Важное уточнение:

• Концепции аккаунта, межконтрактных вызовов, хранения и т. д. останутся абсолютно одинаковыми. Эти абстракции хорошо работают, и разработчики привыкли к ним. Операционные коды такие как 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-EVM. В долгосрочной перспективе основными ограничивающими факторами масштабирования Ethereum Layer1 являются:

• Стабильность образцов доступности данных и исторического хранения
• Надеюсь сохранить конкурентоспособность рынка производства блоков
• Возможности проверки ZK-EVM

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

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

! nsRqhscTyRR2vPvAOgUE58HVgFHuLUgGxTescWwT.jpeg

Есть четыре части, которые занимают много времени: десериализация_inputs, инициализация_witness_db, состояние_root_computation и блок_execution.

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

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

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

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

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

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