Цель состоит в значительном повышении эффективности уровня выполнения и упрощения уровня выполнения, а также в преодолении узких мест в расширении.
Источник:Виталик Бутерин
Составитель: KarenZ, Foresight News
20 апреля Виталик Бутерин на платформе Ethereum Magicians предложил важное предложение о долгосрочном уровне выполнения L1 Ethereum. Он предложил заменить существующую EVM (виртуальную машину Ethereum) архитектурой RISC-V в качестве языка виртуальной машины для написания смарт-контрактов, с целью коренного повышения эффективности работы уровня выполнения 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. В среднесрочной перспективе будет решено больше проблем с безгражданством и ЗК-ЭВМ. В долгосрочной перспективе основными ограничивающими факторами для масштабирования 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% которых фактически пропорционально размеру следящих данных.
Эти разделы можно значительно оптимизировать, заменив текущее 16-арное дерево патрисии Меркла на двоичное дерево, использующее легко доказуемую хеш-функцию. Если мы используем Poseidon, то можем доказать 2 миллиона хэшей в секунду на ноутбуке (для сравнения, keccak составляет около 15 000 хешей/сек). Кроме «Посейдона» есть много других вариантов. В целом, для этих компонентов есть много возможностей для оптимизации. Кроме того, мы можем устранить нарастание_logs_bloom, удалив налет.
Остальная часть block_execution составляет примерно половину текущего цикла доказательства (prover cycles). Чтобы достичь 100-кратного повышения общей эффективности доказательства, эффективность доказательства EVM должна быть увеличена как минимум в 50 раз. Одно из решений заключается в создании более эффективной реализации доказательства для 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, и такое радикальное изменение может быть единственным способом добиться аналогичного ускорения на уровне исполнения.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик долгосрочное предложение для уровня L1: заменить EVM на RISC-V
Источник: Виталик Бутерин
Составитель: KarenZ, Foresight News
20 апреля Виталик Бутерин на платформе Ethereum Magicians предложил важное предложение о долгосрочном уровне выполнения L1 Ethereum. Он предложил заменить существующую EVM (виртуальную машину Ethereum) архитектурой RISC-V в качестве языка виртуальной машины для написания смарт-контрактов, с целью коренного повышения эффективности работы уровня выполнения Ethereum, преодоления одного из основных узких мест масштабируемости и значительно упрощения ясности уровня выполнения.
Foresight News полностью перевел это предложение, чтобы помочь читателям понять эту технологическую концепцию. Ниже приводится перевод оригинального текста предложения:
В данной статье предложена радикальная идея о будущем уровня исполнения Ethereum, которая по амбициозности не уступает плану Beam Chain для уровня консенсуса. Этот проект направлен на значительное повышение эффективности уровня исполнения Ethereum, решение одной из основных проблем масштабируемости и значительное упрощение уровня исполнения — фактически, это может быть единственным способом достижения этой цели.
Основная идея: заменить EVM на RISC-V в качестве языка виртуальной машины для написания смарт-контрактов.
Важное замечание:
Nervos CKB VM установил прецедент, по сути, это реализация RISC-V.
Почему так?
В ближайшей перспективе предстоящие EIP (например, списки доступа на уровне блоков, отложенное выполнение, распределенное хранилище истории и EIP-4444) устранят основные узкие места масштабирования Ethereum L1. В среднесрочной перспективе будет решено больше проблем с безгражданством и ЗК-ЭВМ. В долгосрочной перспективе основными ограничивающими факторами для масштабирования 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-арное дерево патрисии Меркла на двоичное дерево, использующее легко доказуемую хеш-функцию. Если мы используем Poseidon, то можем доказать 2 миллиона хэшей в секунду на ноутбуке (для сравнения, keccak составляет около 15 000 хешей/сек). Кроме «Посейдона» есть много других вариантов. В целом, для этих компонентов есть много возможностей для оптимизации. Кроме того, мы можем устранить нарастание_logs_bloom, удалив налет.
Остальная часть block_execution составляет примерно половину текущего цикла доказательства (prover cycles). Чтобы достичь 100-кратного повышения общей эффективности доказательства, эффективность доказательства EVM должна быть увеличена как минимум в 50 раз. Одно из решений заключается в создании более эффективной реализации доказательства для 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, и такое радикальное изменение может быть единственным способом добиться аналогичного ускорения на уровне исполнения.