Эта статья выдвигает радикальную идею о будущем уровня исполнения Ethereum, амбиции которой сопоставимы с усилиями уровня консенсуса, такими как beacon chain. Она направлена на значительное повышение эффективности уровня исполнения 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. В среднесрочной перспективе мы решаем дальнейшие проблемы с безгражданством и ЗК-ЭВМ. В долгосрочной перспективе основными ограничивающими факторами для масштабирования Ethereum L1 станут:
Стабильность выборки доступности данных (data availability sampling) и протоколов исторического хранения (history storage protocols).
Сохранить желание производства блоков для конкурентного рынка.
Способности доказательства ZK-EVM.
Я докажу, что замена ZK-EVM на RISC-V может решить ключевые узкие места в (2) и (3).
Вот таблица количества циклов, необходимых для доказательства различных частей уровня исполнения EVM с использованием Succinct ZK-EVM:
Среди этих четырех частей наиболее трудоемкими являются: десериализация_inputs, инициализация_witness_db, состояние_root_computation и блокирование_execution.
И initialize_witness_db, и state_root_computation связаны с деревом состояний.
deserialize_inputs относится к процессу преобразования данных блока и свидетелей во внутреннее представление. Таким образом, на самом деле более 50% времени связано с размерами свидетелей.
Эти разделы можно значительно оптимизировать, заменив текущее 16-арное дерево Меркла-Патрисии на двоичное дерево, использующее удобную для доказательства хеш-функцию. Если мы используем Poseidon, мы можем доказать 2 миллиона хэшей в секунду на ноутбуке (по сравнению с 15 000 хешей в секунду для keccak). Кроме «Посейдона» есть много других вариантов. В целом, для этих компонентов есть много возможностей для оптимизации. В качестве дополнительного бонуса мы можем избавиться от нарастания_logs_bloom, убрав налет.
Таким образом, остается блок_execution, на который в настоящее время приходится около половины циклов прувера. Если мы хотим увеличить общую эффективность прувера в 100 раз, мы должны увеличить эффективность прувера EVM как минимум в 50 раз. Мы можем попытаться создать более эффективные реализации EVM, чтобы сократить циклы проверки. Другой подход заключается в том, чтобы отметить, что текущие доказательства ZK-EVM были проверены компиляцией EVM в RISC-V, поэтому можно напрямую разрешить разработчикам смарт-контрактов использовать виртуальную машину RISC-V.
Некоторые данные показывают, что в определенных случаях это может привести к увеличению эффективности более чем в 100 раз:
На практике я ожидаю, что оставшееся время prover будет в основном определяться сегодняшними precompiles. Если мы возьмем RISC-V в качестве основной VM, то график gas будет отражать время доказательства, поэтому будет экономическое давление, побуждающее разработчиков прекратить использование более дорогих precompiles. Тем не менее, повышение эффективности может не быть таким потрясающим, как показывают данные, но у нас есть все основания полагать, что оно будет весьма значительным.
(Кстати, стоит упомянуть, что соотношение EVM и "других частей" примерно по 50% также наблюдается в обычном выполнении EVM, и мы интуитивно ожидаем, что улучшение, вызванное удалением EVM в качестве "посредника", также будет значительным.)
Детали реализации
Существует несколько способов реализации этого предложения. Вот несколько возможных методов:
Наименее разрушительный способ: поддержка двух виртуальных машин (VM), позволяющая контрактам быть написанными на любой из них. Оба типа контрактов могут получать доступ к одинаковым функциям: постоянное хранение (SLOAD и SSTORE), удержание ETH-баланса, инициирование и получение вызовов и т.д. Контракты EVM и RISC-V могут свободно вызывать друг друга; с точки зрения RISC-V, вызов контракта EVM выглядит как выполнение syscall с особыми параметрами; получающий сообщение контракт EVM интерпретирует его как CALL.
Более радикальный подход: преобразование существующего контракта EVM в контракт интерпретатора, написанный RISC-V, для выполнения существующего кода EVM. То есть, если EVM-контракт имеет код C, а интерпретатор EVM находится по адресу X, то контракт будет заменен логикой верхнего уровня: при вызове извне с аргументом вызова D, он вызовет X с (C, D), а затем дождется возвращаемого значения и перенаправит. Если интерпретатор EVM сам вызывает контракт и запрашивает CALL или SLOAD/SSTORE, контракт выполнит соответствующее действие.
Промежуточный маршрут: использовать второй способ, но создать четкие характеристики протокола — по сути, записать концепцию "интерпретатора виртуальной машины" в протокол и требовать, чтобы его логика была написана на RISC-V. EVM будет первым интерпретатором, но могут быть и другие интерпретаторы (например, Move может быть кандидатом).
Ключевым преимуществом второго и третьего предложений является то, что они значительно упрощают спецификацию уровня исполнения — на самом деле, этот подход может быть единственным реальным способом достижения упрощения, учитывая, что даже такая инкрементная упрощенная мера, как удаление SELFDESTRUCT, является очень сложной задачей. В Tinygrad существует жесткое правило: код никогда не превышает 10 000 строк; оптимизированный уровень блокчейна должен легко соответствовать этому ограничению, а возможно, даже быть меньше. Усилия по созданию beacon chain вселяют огромную надежду на значительное упрощение уровня консенсуса Ethereum. Но чтобы уровень исполнения мог достичь аналогичного упрощения, такая радикальная реформа может быть единственным жизнеспособным путем.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Виталик Бутерин представил новое предложение: заменить EVM на RISC-V в долгосрочном слое выполнения L1 Ethereum.
Автор оригинала: Виталик Бутерин
Оригинальный текст переведен: Люк, Mars Finance
Эта статья выдвигает радикальную идею о будущем уровня исполнения Ethereum, амбиции которой сопоставимы с усилиями уровня консенсуса, такими как beacon chain. Она направлена на значительное повышение эффективности уровня исполнения 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. В среднесрочной перспективе мы решаем дальнейшие проблемы с безгражданством и ЗК-ЭВМ. В долгосрочной перспективе основными ограничивающими факторами для масштабирования Ethereum L1 станут:
Стабильность выборки доступности данных (data availability sampling) и протоколов исторического хранения (history storage protocols).
Сохранить желание производства блоков для конкурентного рынка.
Способности доказательства ZK-EVM.
Я докажу, что замена ZK-EVM на RISC-V может решить ключевые узкие места в (2) и (3).
Вот таблица количества циклов, необходимых для доказательства различных частей уровня исполнения EVM с использованием Succinct ZK-EVM:
Среди этих четырех частей наиболее трудоемкими являются: десериализация_inputs, инициализация_witness_db, состояние_root_computation и блокирование_execution.
И initialize_witness_db, и state_root_computation связаны с деревом состояний.
deserialize_inputs относится к процессу преобразования данных блока и свидетелей во внутреннее представление. Таким образом, на самом деле более 50% времени связано с размерами свидетелей.
Эти разделы можно значительно оптимизировать, заменив текущее 16-арное дерево Меркла-Патрисии на двоичное дерево, использующее удобную для доказательства хеш-функцию. Если мы используем Poseidon, мы можем доказать 2 миллиона хэшей в секунду на ноутбуке (по сравнению с 15 000 хешей в секунду для keccak). Кроме «Посейдона» есть много других вариантов. В целом, для этих компонентов есть много возможностей для оптимизации. В качестве дополнительного бонуса мы можем избавиться от нарастания_logs_bloom, убрав налет.
Таким образом, остается блок_execution, на который в настоящее время приходится около половины циклов прувера. Если мы хотим увеличить общую эффективность прувера в 100 раз, мы должны увеличить эффективность прувера EVM как минимум в 50 раз. Мы можем попытаться создать более эффективные реализации EVM, чтобы сократить циклы проверки. Другой подход заключается в том, чтобы отметить, что текущие доказательства ZK-EVM были проверены компиляцией EVM в RISC-V, поэтому можно напрямую разрешить разработчикам смарт-контрактов использовать виртуальную машину RISC-V.
Некоторые данные показывают, что в определенных случаях это может привести к увеличению эффективности более чем в 100 раз:
На практике я ожидаю, что оставшееся время prover будет в основном определяться сегодняшними precompiles. Если мы возьмем RISC-V в качестве основной VM, то график gas будет отражать время доказательства, поэтому будет экономическое давление, побуждающее разработчиков прекратить использование более дорогих precompiles. Тем не менее, повышение эффективности может не быть таким потрясающим, как показывают данные, но у нас есть все основания полагать, что оно будет весьма значительным.
(Кстати, стоит упомянуть, что соотношение EVM и "других частей" примерно по 50% также наблюдается в обычном выполнении EVM, и мы интуитивно ожидаем, что улучшение, вызванное удалением EVM в качестве "посредника", также будет значительным.)
Детали реализации
Существует несколько способов реализации этого предложения. Вот несколько возможных методов:
Наименее разрушительный способ: поддержка двух виртуальных машин (VM), позволяющая контрактам быть написанными на любой из них. Оба типа контрактов могут получать доступ к одинаковым функциям: постоянное хранение (SLOAD и SSTORE), удержание ETH-баланса, инициирование и получение вызовов и т.д. Контракты EVM и RISC-V могут свободно вызывать друг друга; с точки зрения RISC-V, вызов контракта EVM выглядит как выполнение syscall с особыми параметрами; получающий сообщение контракт EVM интерпретирует его как CALL.
Более радикальный подход: преобразование существующего контракта EVM в контракт интерпретатора, написанный RISC-V, для выполнения существующего кода EVM. То есть, если EVM-контракт имеет код C, а интерпретатор EVM находится по адресу X, то контракт будет заменен логикой верхнего уровня: при вызове извне с аргументом вызова D, он вызовет X с (C, D), а затем дождется возвращаемого значения и перенаправит. Если интерпретатор EVM сам вызывает контракт и запрашивает CALL или SLOAD/SSTORE, контракт выполнит соответствующее действие.
Промежуточный маршрут: использовать второй способ, но создать четкие характеристики протокола — по сути, записать концепцию "интерпретатора виртуальной машины" в протокол и требовать, чтобы его логика была написана на RISC-V. EVM будет первым интерпретатором, но могут быть и другие интерпретаторы (например, Move может быть кандидатом).
Ключевым преимуществом второго и третьего предложений является то, что они значительно упрощают спецификацию уровня исполнения — на самом деле, этот подход может быть единственным реальным способом достижения упрощения, учитывая, что даже такая инкрементная упрощенная мера, как удаление SELFDESTRUCT, является очень сложной задачей. В Tinygrad существует жесткое правило: код никогда не превышает 10 000 строк; оптимизированный уровень блокчейна должен легко соответствовать этому ограничению, а возможно, даже быть меньше. Усилия по созданию beacon chain вселяют огромную надежду на значительное упрощение уровня консенсуса Ethereum. Но чтобы уровень исполнения мог достичь аналогичного упрощения, такая радикальная реформа может быть единственным жизнеспособным путем.