Соучредитель Ethereum Виталик Бутерин выдвинул «радикальное» долгосрочное предложение для уровня выполнения в сети Ethereum: заменить байт-код виртуальной машины Ethereum (EVM) на архитектуру RISC-V с открытым исходным кодом. Предложение опубликовано в посте на форуме Ethereum Magicians.
RISС-V — архитектура процессоров и ПО, которая может служить альтернативой ARM и x86. Nvidia, Google и Alibaba уже всерьез занимаются разработкой процессоров и чипсетов на RISC-V.
«В этом посте предлагается радикальная идея для будущего уровня выполнения Ethereum, которая столь же амбициозна, как и работа над цепочкой блоков для уровня консенсуса. Она направлена на значительное повышение эффективности уровня выполнения Ethereum, устранение одного из основных узких мест в масштабировании, а также может значительно повысить простоту уровня выполнения — на самом деле, это, пожалуй, единственный способ сделать это» — написал Бутерин.
«Идея состоит в том, чтобы заменить EVM на RISC-V в качестве языка виртуальной машины, на котором написаны смарт-контракты», — отметил Бутерин. Внедрение RISC-V также может в некоторых случаях повысить эффективность выполнения в сети в 100 раз.
Он дал важные пояснения:
- Концепции учетных записей, вызовов кросс-контрактов, хранения данных и т. д. останутся точно такими же. Эти абстракции отлично работают, и разработчики привыкли к ним. Коды операций, такие как
SLOAD,SSTORE,BALANCE,CALLи т. д., станут системными вызовами RISC-V. - В таком мире смарт-контракты могли бы быть написаны на Rust, но Бутерин ожидает, что большинство разработчиков продолжат писать смарт-контракты на Solidity (или Vyper), которые адаптируются для добавления RISC-V в качестве бэкенда. Это связано с тем, что смарт-контракты, написанные на Rust, на самом деле довольно «уродливы», а Solidity и Vyper намного более удобны для чтения, отметил он. Потенциально девексинг изменится очень незначительно, и разработчики едва ли заметят эти изменения.
- Контракты EVM старого образца будут продолжать работать и будут полностью двусторонне совместимы с контрактами RISC-V нового образца. Есть пара способов сделать это, добавил Бутерин.
Одним из прецедентов для этого является виртуальная машина Nervos CKB, которая по сути является RISC-V, написал основатель Ethereum.
В краткосрочной перспективе основные проблемы масштабируемости Ethereum L1 будут решены с помощью будущих EIP, таких как списки доступа на уровне блоков, отложенное выполнение и распределенное хранилище истории, а также EIP-4444.
«Если мы хотим в 100 раз повысить общую эффективность прувера, нам нужно как минимум в 50 раз повысить эффективность прувера EVM. Единственное, что мы можем сделать, — это попытаться создать реализации EVM, которые будут гораздо эффективнее с точки зрения циклов работы прувера. Другое, что мы можем сделать, — это заметить, что ZK-EVM-доказательства сегодня уже работают с реализациями EVM, скомпилированными до RISC-V, и предоставить разработчикам смарт-контрактов прямой доступ к этой виртуальной машине RISC-V», — написал Бутерин.
Некоторые цифры показывают, что в ограниченных случаях это может повысить эффективность более чем в 100 раз.
Другие криптопроекты уже экспериментировали с внедрением RISC-V, например PolkaVM от Polkadot, представленный в августе 2023 года. Подход Polkadot аналогичен первому предложению Бутерина и предполагает поддержку нескольких виртуальных машин вместо преобразования всех существующих контрактов с помощью хардфорка основной сети.
Детали реализации
Существует несколько способов реализации такого рода предложений. Наименее разрушительный из них — поддержка двух виртуальных машин и возможность написания контрактов на любой из них.
Более радикальный подход с точки зрения протокола заключается в преобразовании существующих контрактов EVM в контракты, которые вызывают контракт-интерпретатор EVM, написанный на RISC-V, и который выполняет существующий код EVM.
Промежуточный вариант — использовать второй вариант, но создать для него явную функцию протокола — по сути, закрепить концепцию «интерпретатора виртуальной машины» и потребовать, чтобы его логика была написана на RISC-V.
Ключевым преимуществом второго и третьего предложений является то, что они значительно упрощают спецификацию уровня выполнения.
