Исследование узких мест последовательного выполнения EVM и оптимизация параллелизации
Общеизвестно, что EVM является основным движком выполнения и средой выполнения смарт-контрактов в Ethereum, и является одним из ключевых компонентов Ethereum. В публичной цепи блоков, состоящей из множества узлов, технологии виртуальных машин играют жизненно важную роль в обеспечении согласованности результатов выполнения смарт-контрактов на различных узлах.
EVM может выполнять смарт-контракты в унифицированном формате на различных операционных системах и устройствах, что обеспечивает кроссплатформенную совместимость и гарантирует, что каждый узел получит одинаковые результаты после выполнения контракта. Это похоже на принцип работы виртуальной машины Java (JVM).
В обычных случаях смарт-контракты сначала компилируются в байт-код EVM, а затем хранятся в блокчейне. При выполнении контракта EVM последовательно считывает этот байт-код, каждая инструкция соответствует определенной стоимости газа. EVM отслеживает потребление газа в процессе выполнения каждой инструкции, конкретное количество потребления зависит от сложности операции.
В качестве основного исполнительного движка Ethereum EVM обрабатывает транзакции в последовательном режиме, все транзакции ставятся в очередь в одном единственном порядке и выполняются последовательно в соответствии с определённым порядком. Причина выбора последовательного, а не параллельного режима заключается в строгом соблюдении требований к согласованности блокчейна, чтобы гарантировать, что группа транзакций обрабатывается во всех узлах в одном и том же порядке.
С 2014 по 2015 год команда основателей Ethereum, из-за нехватки времени, выбрала простой и легкий в обслуживании последовательный способ выполнения. Однако, с развитием технологии блокчейн и расширением пользовательской базы, требования к TPS и пропускной способности постоянно растут. Особенно после того, как технология Rollup стала зрелой и была внедрена, производственные узкие места, вызванные последовательным выполнением EVM, стали более очевидными в сетях второго уровня Ethereum.
В качестве ключевого компонента Layer2, Sequencer берет на себя все вычислительные задачи в виде одного сервера. Если внешние модули, работающие с Sequencer, достаточно эффективны, то конечная узкая точка будет зависеть от самой эффективности Sequencer, и в этот момент последовательное выполнение станет серьезным препятствием.
Некоторые команды, проводя экстремальную оптимизацию уровня DA и модуля чтения-записи данных, смогли добиться того, что Sequencer может выполнять порядка 2000 и более транзакций ERC-20 в секунду. Эта цифра кажется очень высокой, но для более сложных сделок значение TPS обязательно значительно снизится. Поэтому параллелизация обработки транзакций станет неизбежной тенденцией будущего.
Два основных компонента выполнения сделок в Ethereum
Помимо EVM, другой ключевой компонент, связанный с выполнением транзакций, - это stateDB, который используется для управления состоянием аккаунтов и хранения данных в Ethereum. Ethereum использует структуру дерева Merkle Patricia Trie в качестве индекса базы данных, и каждый раз, когда EVM выполняет транзакцию, некоторые данные в stateDB изменяются, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех аккаунтов Ethereum, включая EOA-аккаунты и контрактные аккаунты, хранящие такие данные, как баланс аккаунта, код смарт-контракта и т. д. В процессе выполнения транзакции stateDB будет читать и записывать данные соответствующих аккаунтов. После завершения выполнения транзакции stateDB должен отправить новое состояние в нижнюю базу данных для постоянной обработки.
В общем, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB выполняет роль глобального хранилища состояния, управляя изменениями состояния всех аккаунтов и контрактов. Оба элемента вместе создают среду выполнения транзакций Ethereum.
Конкретный процесс последовательного выполнения
Типы транзакций в Ethereum делятся на переводы EOA и контрактные транзакции. Перевод EOA — это самый простой тип транзакции, то есть перевод ETH между обычными счетами, не связанный с вызовом контракта, скорость обработки очень высокая, а комиссии за газ крайне низкие.
В отличие от этого, контрактная торговля включает вызов и выполнение смарт-контрактов. EVM при обработке контрактных сделок должен интерпретировать и выполнять инструкции байт-кода в смарт-контракте по одной, чем сложнее логика контракта и чем больше задействованных инструкций, тем больше ресурсов требуется.
Например, время обработки перевода ERC-20 составляет примерно в два раза больше, чем время перевода EOA, а более сложные смарт-контракты, такие как торговые операции на DEX, могут занимать в десятки раз больше времени, чем переводы EOA. Это связано с тем, что DeFi-протоколы требуют обработки сложной логики, такой как ликвидные пулы, расчет цен, обмен токенов и т.д., что требует выполнения большого количества вычислений.
В режиме последовательного выполнения процесс обработки транзакций с совместной работой компонентов EVM и stateDB выглядит следующим образом:
В дизайне Ethereum транзакции в блоке обрабатываются последовательно, каждая транзакция имеет отдельный экземпляр для выполнения конкретных операций. Хотя каждая транзакция использует разные экземпляры EVM, все транзакции используют одну и ту же базу данных состояния stateDB.
В процессе выполнения транзакций EVM необходимо постоянно взаимодействовать с stateDB, считывать соответствующие данные из stateDB и записывать изменённые данные обратно в stateDB.
Когда все транзакции в блоке будут выполнены, данные в stateDB будут отправлены в глобальное состояние дерева и сгенерируют новый корень состояния. Корень состояния является важным параметром в каждом блоке, который фиксирует "сжатый результат" нового глобального состояния после выполнения блока.
Очевидно, что последовательный режим выполнения EVM имеет явные узкие места: транзакции должны выполняться в порядке очереди, и если возникает длительная транзакция с умным контрактом, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы, а эффективность значительно ограничена.
Оптимизация многопоточности и параллелизма EVM
Если провести аналогию с примерами из жизни, последовательное выполнение похоже на банк с одним окошком, тогда как параллельный EVM напоминает банк с несколькими окошками. В параллельном режиме можно открыть несколько потоков для одновременной обработки нескольких транзакций, что может значительно повысить эффективность, но необходимо решить проблему конфликтов состояния.
Если несколько транзакций одновременно заявляют о необходимости изменить данные определенного аккаунта, это может привести к конфликтам при обработке. Например, если определенный NFT может быть выпущен только один раз, и транзакции 1 и 2 обе заявляют о намерении выпустить этот NFT, очевидно, что это приведет к ошибке, если оба запроса будут удовлетворены. На практике конфликты состояния возникают гораздо чаще, поэтому параллельная обработка должна иметь меры для разрешения конфликтов состояния.
Принципы параллельной оптимизации EVM для определенного проекта
Некоторый проект ZKRollup предлагает подход к параллельной оптимизации EVM, при котором каждой нити выделяется одна транзакция, и в каждой нити предоставляется временная база данных состояния, называемая pending-stateDB. Конкретные детали следующие:
Параллельное выполнение транзакций с многопоточностью: настройка нескольких потоков для одновременной обработки различных транзакций, потоки не мешают друг другу, что может увеличить скорость обработки транзакций в несколько раз.
Выделение временной базы данных состояния для каждого потока: для каждого потока выделяется независимая временная база данных состояния (pending-stateDB). Каждый поток, выполняя транзакцию, не изменяет глобальную stateDB напрямую, а временно записывает результаты изменения состояния в pending-stateDB.
Синхронизация изменений состояния: После выполнения всех транзакций в одном блоке EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если во время выполнения различных транзакций не произошло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал обработку операций чтения и записи, чтобы обеспечить правильный доступ к статусным данным транзакций и избежать конфликтов:
Операция чтения: когда транзакции необходимо прочитать состояние, EVM сначала проверяет ReadSet ожидаемого состояния. Если в ReadSet есть необходимые данные, они считываются непосредственно из pending-stateDB. Если в ReadSet не найдены соответствующие пары ключ-значение, то данные исторического состояния считываются из глобального stateDB соответствующего предыдущего блока.
Операции записи: все операции записи (то есть изменения состояния) не записываются непосредственно в глобальную stateDB, а сначала фиксируются в WriteSet ожидающего состояния. После завершения выполнения транзакции, с помощью обнаружения конфликтов вновь пытаются объединить результаты изменения состояния в глобальную stateDB.
Ключевая проблема параллельного выполнения заключается в конфликте состояний, который становится особенно заметным, когда несколько транзакций пытаются читать и записывать состояние одного и того же счета. Для этого была введена механика обнаружения конфликтов:
Обнаружение конфликтов: в процессе выполнения транзакций EVM будет отслеживать ReadSet и WriteSet различных транзакций. Если будет обнаружено, что несколько транзакций пытаются читать и записывать одни и те же элементы состояния, это будет расцениваться как конфликт.
Обработка конфликтов: Когда обнаруживается конфликт, конфликтная транзакция будет помечена как требующая повторного выполнения.
После завершения всех выполненных сделок, записи изменений из нескольких pending-stateDB будут объединены в глобальный stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и создаст новый корень состояния.
Улучшение производительности за счет оптимизации параллельных потоков является значительным, особенно при обработке сложных сделок с умными контрактами. Исследования показывают, что в условиях низкой конфликтности производительность TPS по сравнению с традиционным последовательным выполнением возросла примерно в 3-5 раз. В условиях высокой конфликтности, теоретически, если применить все методы оптимизации, можно достичь увеличения в 60 раз.
Резюме
Оптимизация многопоточности EVM значительно повысила способность обработки транзакций EVM, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизмы обнаружения конфликтов, публичные блокчейны на базе EVM могут достичь массовой параллелизации транзакций при обеспечении согласованности состояния, решая проблемы с производительностью, возникающие при традиционной последовательной модели выполнения. Это заложило важную основу для будущего развития Rollup на Ethereum.
В будущем можно будет дополнительно исследовать, как оптимизировать эффективность хранения для повышения производительности, решения для оптимизации в условиях высокого конфликта, а также как использовать GPU для оптимизации и другие аспекты.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
3
Поделиться
комментарий
0/400
LeverageAddict
· 07-20 10:07
Опять кто-то делает параллельные операции, как и моя L2 Позиция, тоже зависла.
Посмотреть ОригиналОтветить0
WenMoon
· 07-20 09:51
Ух ты, L2 тоже нужно ускорить.
Посмотреть ОригиналОтветить0
EntryPositionAnalyst
· 07-20 09:44
L2 параллелизация уже понята, теперь следую за evm
Оптимизация параллелизма EVM: преодоление узких мест последовательного выполнения для повышения производительности Layer2
Исследование узких мест последовательного выполнения EVM и оптимизация параллелизации
Общеизвестно, что EVM является основным движком выполнения и средой выполнения смарт-контрактов в Ethereum, и является одним из ключевых компонентов Ethereum. В публичной цепи блоков, состоящей из множества узлов, технологии виртуальных машин играют жизненно важную роль в обеспечении согласованности результатов выполнения смарт-контрактов на различных узлах.
EVM может выполнять смарт-контракты в унифицированном формате на различных операционных системах и устройствах, что обеспечивает кроссплатформенную совместимость и гарантирует, что каждый узел получит одинаковые результаты после выполнения контракта. Это похоже на принцип работы виртуальной машины Java (JVM).
В обычных случаях смарт-контракты сначала компилируются в байт-код EVM, а затем хранятся в блокчейне. При выполнении контракта EVM последовательно считывает этот байт-код, каждая инструкция соответствует определенной стоимости газа. EVM отслеживает потребление газа в процессе выполнения каждой инструкции, конкретное количество потребления зависит от сложности операции.
В качестве основного исполнительного движка Ethereum EVM обрабатывает транзакции в последовательном режиме, все транзакции ставятся в очередь в одном единственном порядке и выполняются последовательно в соответствии с определённым порядком. Причина выбора последовательного, а не параллельного режима заключается в строгом соблюдении требований к согласованности блокчейна, чтобы гарантировать, что группа транзакций обрабатывается во всех узлах в одном и том же порядке.
С 2014 по 2015 год команда основателей Ethereum, из-за нехватки времени, выбрала простой и легкий в обслуживании последовательный способ выполнения. Однако, с развитием технологии блокчейн и расширением пользовательской базы, требования к TPS и пропускной способности постоянно растут. Особенно после того, как технология Rollup стала зрелой и была внедрена, производственные узкие места, вызванные последовательным выполнением EVM, стали более очевидными в сетях второго уровня Ethereum.
В качестве ключевого компонента Layer2, Sequencer берет на себя все вычислительные задачи в виде одного сервера. Если внешние модули, работающие с Sequencer, достаточно эффективны, то конечная узкая точка будет зависеть от самой эффективности Sequencer, и в этот момент последовательное выполнение станет серьезным препятствием.
Некоторые команды, проводя экстремальную оптимизацию уровня DA и модуля чтения-записи данных, смогли добиться того, что Sequencer может выполнять порядка 2000 и более транзакций ERC-20 в секунду. Эта цифра кажется очень высокой, но для более сложных сделок значение TPS обязательно значительно снизится. Поэтому параллелизация обработки транзакций станет неизбежной тенденцией будущего.
Два основных компонента выполнения сделок в Ethereum
Помимо EVM, другой ключевой компонент, связанный с выполнением транзакций, - это stateDB, который используется для управления состоянием аккаунтов и хранения данных в Ethereum. Ethereum использует структуру дерева Merkle Patricia Trie в качестве индекса базы данных, и каждый раз, когда EVM выполняет транзакцию, некоторые данные в stateDB изменяются, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех аккаунтов Ethereum, включая EOA-аккаунты и контрактные аккаунты, хранящие такие данные, как баланс аккаунта, код смарт-контракта и т. д. В процессе выполнения транзакции stateDB будет читать и записывать данные соответствующих аккаунтов. После завершения выполнения транзакции stateDB должен отправить новое состояние в нижнюю базу данных для постоянной обработки.
В общем, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB выполняет роль глобального хранилища состояния, управляя изменениями состояния всех аккаунтов и контрактов. Оба элемента вместе создают среду выполнения транзакций Ethereum.
Конкретный процесс последовательного выполнения
Типы транзакций в Ethereum делятся на переводы EOA и контрактные транзакции. Перевод EOA — это самый простой тип транзакции, то есть перевод ETH между обычными счетами, не связанный с вызовом контракта, скорость обработки очень высокая, а комиссии за газ крайне низкие.
В отличие от этого, контрактная торговля включает вызов и выполнение смарт-контрактов. EVM при обработке контрактных сделок должен интерпретировать и выполнять инструкции байт-кода в смарт-контракте по одной, чем сложнее логика контракта и чем больше задействованных инструкций, тем больше ресурсов требуется.
Например, время обработки перевода ERC-20 составляет примерно в два раза больше, чем время перевода EOA, а более сложные смарт-контракты, такие как торговые операции на DEX, могут занимать в десятки раз больше времени, чем переводы EOA. Это связано с тем, что DeFi-протоколы требуют обработки сложной логики, такой как ликвидные пулы, расчет цен, обмен токенов и т.д., что требует выполнения большого количества вычислений.
В режиме последовательного выполнения процесс обработки транзакций с совместной работой компонентов EVM и stateDB выглядит следующим образом:
В дизайне Ethereum транзакции в блоке обрабатываются последовательно, каждая транзакция имеет отдельный экземпляр для выполнения конкретных операций. Хотя каждая транзакция использует разные экземпляры EVM, все транзакции используют одну и ту же базу данных состояния stateDB.
В процессе выполнения транзакций EVM необходимо постоянно взаимодействовать с stateDB, считывать соответствующие данные из stateDB и записывать изменённые данные обратно в stateDB.
Когда все транзакции в блоке будут выполнены, данные в stateDB будут отправлены в глобальное состояние дерева и сгенерируют новый корень состояния. Корень состояния является важным параметром в каждом блоке, который фиксирует "сжатый результат" нового глобального состояния после выполнения блока.
Очевидно, что последовательный режим выполнения EVM имеет явные узкие места: транзакции должны выполняться в порядке очереди, и если возникает длительная транзакция с умным контрактом, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы, а эффективность значительно ограничена.
Оптимизация многопоточности и параллелизма EVM
Если провести аналогию с примерами из жизни, последовательное выполнение похоже на банк с одним окошком, тогда как параллельный EVM напоминает банк с несколькими окошками. В параллельном режиме можно открыть несколько потоков для одновременной обработки нескольких транзакций, что может значительно повысить эффективность, но необходимо решить проблему конфликтов состояния.
Если несколько транзакций одновременно заявляют о необходимости изменить данные определенного аккаунта, это может привести к конфликтам при обработке. Например, если определенный NFT может быть выпущен только один раз, и транзакции 1 и 2 обе заявляют о намерении выпустить этот NFT, очевидно, что это приведет к ошибке, если оба запроса будут удовлетворены. На практике конфликты состояния возникают гораздо чаще, поэтому параллельная обработка должна иметь меры для разрешения конфликтов состояния.
Принципы параллельной оптимизации EVM для определенного проекта
Некоторый проект ZKRollup предлагает подход к параллельной оптимизации EVM, при котором каждой нити выделяется одна транзакция, и в каждой нити предоставляется временная база данных состояния, называемая pending-stateDB. Конкретные детали следующие:
Параллельное выполнение транзакций с многопоточностью: настройка нескольких потоков для одновременной обработки различных транзакций, потоки не мешают друг другу, что может увеличить скорость обработки транзакций в несколько раз.
Выделение временной базы данных состояния для каждого потока: для каждого потока выделяется независимая временная база данных состояния (pending-stateDB). Каждый поток, выполняя транзакцию, не изменяет глобальную stateDB напрямую, а временно записывает результаты изменения состояния в pending-stateDB.
Синхронизация изменений состояния: После выполнения всех транзакций в одном блоке EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если во время выполнения различных транзакций не произошло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал обработку операций чтения и записи, чтобы обеспечить правильный доступ к статусным данным транзакций и избежать конфликтов:
Операция чтения: когда транзакции необходимо прочитать состояние, EVM сначала проверяет ReadSet ожидаемого состояния. Если в ReadSet есть необходимые данные, они считываются непосредственно из pending-stateDB. Если в ReadSet не найдены соответствующие пары ключ-значение, то данные исторического состояния считываются из глобального stateDB соответствующего предыдущего блока.
Операции записи: все операции записи (то есть изменения состояния) не записываются непосредственно в глобальную stateDB, а сначала фиксируются в WriteSet ожидающего состояния. После завершения выполнения транзакции, с помощью обнаружения конфликтов вновь пытаются объединить результаты изменения состояния в глобальную stateDB.
Ключевая проблема параллельного выполнения заключается в конфликте состояний, который становится особенно заметным, когда несколько транзакций пытаются читать и записывать состояние одного и того же счета. Для этого была введена механика обнаружения конфликтов:
Обнаружение конфликтов: в процессе выполнения транзакций EVM будет отслеживать ReadSet и WriteSet различных транзакций. Если будет обнаружено, что несколько транзакций пытаются читать и записывать одни и те же элементы состояния, это будет расцениваться как конфликт.
Обработка конфликтов: Когда обнаруживается конфликт, конфликтная транзакция будет помечена как требующая повторного выполнения.
После завершения всех выполненных сделок, записи изменений из нескольких pending-stateDB будут объединены в глобальный stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и создаст новый корень состояния.
Улучшение производительности за счет оптимизации параллельных потоков является значительным, особенно при обработке сложных сделок с умными контрактами. Исследования показывают, что в условиях низкой конфликтности производительность TPS по сравнению с традиционным последовательным выполнением возросла примерно в 3-5 раз. В условиях высокой конфликтности, теоретически, если применить все методы оптимизации, можно достичь увеличения в 60 раз.
Резюме
Оптимизация многопоточности EVM значительно повысила способность обработки транзакций EVM, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизмы обнаружения конфликтов, публичные блокчейны на базе EVM могут достичь массовой параллелизации транзакций при обеспечении согласованности состояния, решая проблемы с производительностью, возникающие при традиционной последовательной модели выполнения. Это заложило важную основу для будущего развития Rollup на Ethereum.
В будущем можно будет дополнительно исследовать, как оптимизировать эффективность хранения для повышения производительности, решения для оптимизации в условиях высокого конфликта, а также как использовать GPU для оптимизации и другие аспекты.