20 апреля Виталик Бутерин на платформе Ethereum Magicians предложил важную инициативу о долгосрочном уровне выполнения L1 Ethereum. Он предложил использовать архитектуру RISC-V вместо существующей EVM (виртуальной машины Ethereum) в качестве языка виртуальной машины для написания смарт-контрактов, с целью коренным образом повысить эффективность работы уровня выполнения 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 станут:
Стабильность выборки доступности данных и протокола исторического хранения
Сохранение конкурентоспособности рынка производства блоков
Доказательные возможности ZK-EVM
Я докажу, что замена 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% пропорционально размеру данных свидетельства.
Заменив текущий keccak 16-арный Merkle patricia tree на бинарное дерево с использованием легко доказываемых хеш-функций, можно значительно оптимизировать эти части. Если использовать Poseidon, мы можем доказывать 2 миллиона хешей в секунду на ноутбуке (для сравнения, keccak около 15 000 hash/sec). Кроме Poseidon, есть много других вариантов. В целом, у этих компонентов есть большой потенциал для оптимизации. Кроме того, мы можем устранить accrue_logs_bloom, удалив bloom.
На оставшийся блок_execution приходится около половины текущих циклов пруверы. Для достижения 100-кратного увеличения общей эффективности цветопробы требуется эффективность проверки EVM не менее 50x. Одно решение состоит в том, чтобы создать более эффективную реализацию доказательства для EVM, а другое — заметить, что текущий прувер ZK-EVM фактически компилирует EVM в RISC-V для доказательства, предоставляя разработчикам смарт-контрактов прямой доступ к виртуальной машине RISC-V.
Некоторые данные показывают, что в определенных ситуациях эффективность может увеличиться более чем в 100 раз:
В реальном применении оставшееся время prover может быть в основном занято текущими операциями предварительной компиляции (precompiles). Если использовать RISC-V в качестве основной виртуальной машины, график Gas будет отражать фактическое время доказательства, а экономическое давление побудит разработчиков сократить использование высокозатратной предварительной компиляции. Тем не менее, приросты не будут настолько значительными, но у нас есть все основания полагать, что эти приросты будут весьма значительными.
(Стоит отметить, что в обычном выполнении 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, и такое радикальное изменение может быть единственным способом добиться аналогичного ускорения на уровне исполнения.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Полный текст предложения Vitalik о долгосрочном L1 уровне исполнения: заменить EVM на RISC-V
Источник: Виталик Бутерин
Подборка: KarenZ, Форсайт Новости
20 апреля Виталик Бутерин на платформе Ethereum Magicians предложил важную инициативу о долгосрочном уровне выполнения L1 Ethereum. Он предложил использовать архитектуру RISC-V вместо существующей EVM (виртуальной машины Ethereum) в качестве языка виртуальной машины для написания смарт-контрактов, с целью коренным образом повысить эффективность работы уровня выполнения 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 станут:
Стабильность выборки доступности данных и протокола исторического хранения
Сохранение конкурентоспособности рынка производства блоков
Доказательные возможности ZK-EVM
Я докажу, что замена 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% пропорционально размеру данных свидетельства.
Заменив текущий keccak 16-арный Merkle patricia tree на бинарное дерево с использованием легко доказываемых хеш-функций, можно значительно оптимизировать эти части. Если использовать Poseidon, мы можем доказывать 2 миллиона хешей в секунду на ноутбуке (для сравнения, keccak около 15 000 hash/sec). Кроме Poseidon, есть много других вариантов. В целом, у этих компонентов есть большой потенциал для оптимизации. Кроме того, мы можем устранить accrue_logs_bloom, удалив bloom.
На оставшийся блок_execution приходится около половины текущих циклов пруверы. Для достижения 100-кратного увеличения общей эффективности цветопробы требуется эффективность проверки EVM не менее 50x. Одно решение состоит в том, чтобы создать более эффективную реализацию доказательства для EVM, а другое — заметить, что текущий прувер ZK-EVM фактически компилирует EVM в RISC-V для доказательства, предоставляя разработчикам смарт-контрактов прямой доступ к виртуальной машине RISC-V.
Некоторые данные показывают, что в определенных ситуациях эффективность может увеличиться более чем в 100 раз:
В реальном применении оставшееся время prover может быть в основном занято текущими операциями предварительной компиляции (precompiles). Если использовать RISC-V в качестве основной виртуальной машины, график Gas будет отражать фактическое время доказательства, а экономическое давление побудит разработчиков сократить использование высокозатратной предварительной компиляции. Тем не менее, приросты не будут настолько значительными, но у нас есть все основания полагать, что эти приросты будут весьма значительными.
(Стоит отметить, что в обычном выполнении 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, и такое радикальное изменение может быть единственным способом добиться аналогичного ускорения на уровне исполнения.