Оптимизация параллелизма EVM: обсуждение путей повышения производительности на примере Reddio
Как всем известно, EVM является одним из самых важных компонентов Ethereum, выполняя важные роли "исполнительного движка" и "среды выполнения смарт-контрактов". В блокчейне, который состоит из тысяч узлов, аппаратные конфигурации различных узлов могут значительно различаться. Чтобы гарантировать, что смарт-контракты будут получать согласованные результаты выполнения на всех узлах, технологии виртуальных машин стали идеальным решением.
EVM может выполнять смарт-контракты одинаковым образом на разных операционных системах и устройствах, такая кросс-платформенная совместимость гарантирует, что каждый узел получает одинаковые результаты после выполнения контракта. Это похоже на принцип работы виртуальной машины Java (JVM).
Смарт-контракты, которые мы видим в блокчейн-обозревателе, сначала компилируются в байт-код EVM, а затем хранятся в цепочке. Когда EVM выполняет контракт, он последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas в процессе выполнения каждой инструкции, расход зависит от сложности операции.
В качестве основного исполнительного движка Ethereum EVM обрабатывает транзакции последовательно, все транзакции ставятся в очередь и выполняются в определенном порядке. Причина, по которой не используется параллельная обработка, заключается в том, что блокчейн должен строго обеспечивать согласованность; одна и та же группа транзакций должна обрабатываться во всех узлах в одинаковом порядке. Если транзакции обрабатывать параллельно, сложно точно предсказать порядок транзакций, если не вводить сложные алгоритмы планирования.
В 2014-2015 годах команда основателей Ethereum, сталкиваясь с дефицитом времени, выбрала простую и легкую в обслуживании последовательную модель выполнения. Однако с развитием технологий блокчейн и увеличением числа пользователей требования к TPS и пропускной способности стали расти. После появления и зрелости технологии Rollup, производственные ограничения последовательного выполнения EVM стали явно проявляться в сетях второго уровня Ethereum.
Секвенсор как ключевой компонент Layer2 выполняет все вычислительные задачи в виде одного сервера. Если эффективность внешних модулей, работающих в паре с секвенсором, будет достаточно высокой, окончательное узкое место будет зависеть от эффективности самого секвенсора, и в этом случае последовательное выполнение станет серьезным препятствием.
Некоторые команды, проводя экстремальную оптимизацию уровня DA и модуля чтения-записи данных, могут достичь выполнения около 2000 и более транзакций ERC-20 в секунду с помощью Sequencer. Эта цифра кажется высокой, но если обрабатываемые транзакции намного сложнее, чем переводы ERC-20, значение TPS обязательно значительно упадет. Таким образом, параллелизация обработки транзакций станет неизбежной тенденцией в будущем.
Два основных компонента выполнения сделок в Эфириуме
Помимо EVM, другой ключевой компонент, связанный с выполнением транзакций в go-ethereum, - это stateDB, который управляет состоянием аккаунтов и хранением данных в Ethereum. Ethereum использует структуру дерева, называемую Merkle Patricia Trie, в качестве индекса базы данных. Каждый раз, когда EVM выполняет транзакцию, это изменяет некоторые данные, хранящиеся в stateDB, и эти изменения в конечном итоге отразятся в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех учетных записей Ethereum, включая EOA-учетные записи и учетные записи контрактов, хранящие данные, такие как баланс учетной записи, код смарт-контракта и т. д. В процессе выполнения транзакции stateDB будет выполнять чтение и запись данных соответствующих учетных записей. После завершения выполнения транзакции stateDB должен представить новое состояние для постоянной обработки в базу данных нижнего уровня.
В целом, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние на блокчейне в соответствии с результатами вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех учетных записей и контрактов. Оба элемента совместно создают среду выполнения транзакций Ethereum.
Конкретный процесс последовательного выполнения
Типы транзакций в Ethereum делятся на переводы EOA и контрактные транзакции. Перевод EOA является самым простым типом транзакции, т.е. перевод ETH между обычными счетами, не связанный с вызовами контрактов, скорость обработки очень высокая, а комиссия за газ также очень низкая.
Контрактная торговля включает в себя вызов и выполнение смарт-контрактов. Когда EVM обрабатывает контрактные сделки, он должен интерпретировать и выполнять байт-код инструкции смарт-контракта по одной. Чем сложнее логика контракта, тем больше инструкций вовлечено, и тем больше ресурсов будет потреблено.
Например, время обработки перевода ERC-20 составляет примерно в 2 раза больше времени перевода EOA, в то время как более сложные смарт-контракты, такие как операции торговли на некотором DEX, могут занимать в десятки раз больше времени, чем переводы EOA. Это происходит потому, что DeFi-протоколы при выполнении сделок требуют обработки ликвидных пулов, расчета цен, обмена токенов и других сложных логик, что требует большого объема вычислений.
В режиме последовательного выполнения процесс обработки транзакций между EVM и stateDB происходит следующим образом:
В дизайне Ethereum транзакции в блоке обрабатываются поочередно, каждая транзакция имеет отдельный экземпляр для выполнения конкретных операций. Хотя каждая транзакция использует разные экземпляры EVM, все транзакции используют одну и ту же базу данных состояния stateDB.
В процессе выполнения транзакции EVM должен постоянно взаимодействовать с stateDB, считывать соответствующие данные из stateDB и записывать измененные данные обратно в stateDB.
Когда все транзакции в блоке завершены, данные в stateDB будут отправлены в глобальное состояние и сгенерируют новый корень состояния. Корень состояния является важным параметром в каждом блоке, фиксируя "сжатый результат" нового глобального состояния после выполнения блока.
Очевидные ограничения в последовательной модели выполнения EVM: транзакции должны выполняться в порядке очереди, и если возникает длительная транзакция со смарт-контрактом, остальные транзакции могут только ждать до ее завершения. Это явно не позволяет в полной мере использовать аппаратные ресурсы, такие как ЦП, и существенно ограничивает эффективность.
Оптимизация многопоточности и параллелизма в EVM
Серийное выполнение и параллельное выполнение можно сравнить с банком, у которого только одна касса, и банком с несколькими кассами. В параллельном режиме можно открыть несколько потоков для одновременной обработки нескольких транзакций, что может значительно повысить эффективность, но сложность заключается в проблеме конфликтов состояния.
Если несколько транзакций заявляют о необходимости изменить данные определенной учетной записи, то при их одновременной обработке может возникнуть конфликт. Например, если один NFT можно создать только один раз, и транзакции 1 и 2 обе заявляют о создании этого NFT, то, если оба запроса будут удовлетворены, это явно приведет к ошибке. На практике конфликты состояния возникают гораздо чаще, поэтому параллельная обработка транзакций должна включать меры по предотвращению конфликтов состояния.
Принципы параллельной оптимизации Reddio для EVM
Некоторый проект ZKRollup использует подход параллельной оптимизации для EVM, выделяя одну транзакцию для каждого потока и предоставляя временную базу данных состояния в каждом потоке, называемую pending-stateDB. Конкретные детали следующие:
Параллельное выполнение транзакций с использованием нескольких потоков: настройте несколько потоков для одновременной обработки различных транзакций, которые не мешают друг другу. Это может увеличить скорость обработки транзакций в несколько раз.
Выделите временную базу данных состояния для каждого потока: выделите независимую временную базу данных состояния для каждого потока (pending-stateDB). Каждый поток, выполняя транзакции, не будет напрямую изменять глобальную stateDB, а временно будет записывать результаты изменений состояния в pending-stateDB.
Синхронизация изменений состояния: После того как все транзакции в блоке будут выполнены, EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если в процессе выполнения различных транзакций не произошло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал способ обработки операций чтения и записи, чтобы гарантировать, что транзакции могут правильно получать доступ к данным состояния и избегать конфликтов:
Чтение: когда транзакция требует чтения состояния, EVM сначала проверяет ReadSet в ожидающем состоянии. Если необходимые данные есть в ReadSet, они читаются непосредственно из pending-stateDB. Если соответствующая пара ключ-значение не найдена в ReadSet, данные исторического состояния считываются из global stateDB предыдущего блока.
Запись операций: Все операции записи (, то есть изменения состояния ), не будут напрямую записаны в глобальную stateDB, а сначала будут записаны в WriteSet ожидающего состояния. После завершения выполнения транзакции, через проверку на конфликты, будет сделана попытка объединить результаты изменения состояния в глобальную stateDB.
Ключевая проблема параллельного выполнения заключается в конфликте состояний, который особенно заметен, когда несколько транзакций пытаются читать и записывать состояние одного и того же счета. Для этого была введена механика обнаружения конфликтов:
Обнаружение конфликтов: в процессе выполнения транзакции EVM будет отслеживать ReadSet и WriteSet различных транзакций. Если будет обнаружено, что несколько транзакций пытаются читать и записывать одни и те же элементы состояния, это будет считаться конфликтом.
Обработка конфликтов: при обнаружении конфликта конфликтная транзакция будет помечена как требующая повторного выполнения.
После выполнения всех транзакций записи изменений в нескольких pending-stateDB будут объединены в глобальный stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и сгенерирует новый корень состояния.
Улучшение производительности за счет многопоточности и параллельной оптимизации является значительным, особенно при обработке сложных транзакций смарт-контрактов. Исследования показывают, что в пулах транзакций с низкой конфликтностью (, где меньше противоречий или используются одни и те же ресурсы, производительность TPS по сравнению с традиционным последовательным выполнением увеличилась примерно в 3-5 раз. В условиях высокой конфликтности, теоретически, если использовать все возможные методы оптимизации, можно достичь даже 60-кратного повышения.
![На примере Reddio описывается путь оптимизации параллельного EVM])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
Итоги
Оптимизационное решение по многопоточному параллельному выполнению EVM в данном проекте значительно увеличило способность обработки транзакций EVM, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизм обнаружения конфликтов, публичная цепочка EVM может достичь масштабной параллелизации транзакций при гарантии согласованности состояния, решая проблемы производительности, возникающие из традиционной модели последовательного выполнения. Это закладывает важную основу для будущего развития Ethereum Rollup.
![На примере Reddio объясняется путь оптимизации параллельного EVM])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
5
Репост
Поделиться
комментарий
0/400
SocialFiQueen
· 08-05 12:02
Это сопоставимо с Гонконгом.
Посмотреть ОригиналОтветить0
SerumSquirter
· 08-05 00:36
Зайди на reddio, давай быстрее работай
Посмотреть ОригиналОтветить0
SocialAnxietyStaker
· 08-03 20:27
Многопоточность удивительная啊
Посмотреть ОригиналОтветить0
GamefiEscapeArtist
· 08-03 20:25
Так долго работали, а v1 все еще не очень оптимизирован.
Оптимизация многопоточности EVM: разблокировка узких мест производительности Rollup
Оптимизация параллелизма EVM: обсуждение путей повышения производительности на примере Reddio
Как всем известно, EVM является одним из самых важных компонентов Ethereum, выполняя важные роли "исполнительного движка" и "среды выполнения смарт-контрактов". В блокчейне, который состоит из тысяч узлов, аппаратные конфигурации различных узлов могут значительно различаться. Чтобы гарантировать, что смарт-контракты будут получать согласованные результаты выполнения на всех узлах, технологии виртуальных машин стали идеальным решением.
EVM может выполнять смарт-контракты одинаковым образом на разных операционных системах и устройствах, такая кросс-платформенная совместимость гарантирует, что каждый узел получает одинаковые результаты после выполнения контракта. Это похоже на принцип работы виртуальной машины Java (JVM).
Смарт-контракты, которые мы видим в блокчейн-обозревателе, сначала компилируются в байт-код EVM, а затем хранятся в цепочке. Когда EVM выполняет контракт, он последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas в процессе выполнения каждой инструкции, расход зависит от сложности операции.
В качестве основного исполнительного движка Ethereum EVM обрабатывает транзакции последовательно, все транзакции ставятся в очередь и выполняются в определенном порядке. Причина, по которой не используется параллельная обработка, заключается в том, что блокчейн должен строго обеспечивать согласованность; одна и та же группа транзакций должна обрабатываться во всех узлах в одинаковом порядке. Если транзакции обрабатывать параллельно, сложно точно предсказать порядок транзакций, если не вводить сложные алгоритмы планирования.
В 2014-2015 годах команда основателей Ethereum, сталкиваясь с дефицитом времени, выбрала простую и легкую в обслуживании последовательную модель выполнения. Однако с развитием технологий блокчейн и увеличением числа пользователей требования к TPS и пропускной способности стали расти. После появления и зрелости технологии Rollup, производственные ограничения последовательного выполнения EVM стали явно проявляться в сетях второго уровня Ethereum.
Секвенсор как ключевой компонент Layer2 выполняет все вычислительные задачи в виде одного сервера. Если эффективность внешних модулей, работающих в паре с секвенсором, будет достаточно высокой, окончательное узкое место будет зависеть от эффективности самого секвенсора, и в этом случае последовательное выполнение станет серьезным препятствием.
Некоторые команды, проводя экстремальную оптимизацию уровня DA и модуля чтения-записи данных, могут достичь выполнения около 2000 и более транзакций ERC-20 в секунду с помощью Sequencer. Эта цифра кажется высокой, но если обрабатываемые транзакции намного сложнее, чем переводы ERC-20, значение TPS обязательно значительно упадет. Таким образом, параллелизация обработки транзакций станет неизбежной тенденцией в будущем.
Два основных компонента выполнения сделок в Эфириуме
Помимо EVM, другой ключевой компонент, связанный с выполнением транзакций в go-ethereum, - это stateDB, который управляет состоянием аккаунтов и хранением данных в Ethereum. Ethereum использует структуру дерева, называемую Merkle Patricia Trie, в качестве индекса базы данных. Каждый раз, когда EVM выполняет транзакцию, это изменяет некоторые данные, хранящиеся в stateDB, и эти изменения в конечном итоге отразятся в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех учетных записей Ethereum, включая EOA-учетные записи и учетные записи контрактов, хранящие данные, такие как баланс учетной записи, код смарт-контракта и т. д. В процессе выполнения транзакции stateDB будет выполнять чтение и запись данных соответствующих учетных записей. После завершения выполнения транзакции stateDB должен представить новое состояние для постоянной обработки в базу данных нижнего уровня.
В целом, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние на блокчейне в соответствии с результатами вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех учетных записей и контрактов. Оба элемента совместно создают среду выполнения транзакций Ethereum.
Конкретный процесс последовательного выполнения
Типы транзакций в Ethereum делятся на переводы EOA и контрактные транзакции. Перевод EOA является самым простым типом транзакции, т.е. перевод ETH между обычными счетами, не связанный с вызовами контрактов, скорость обработки очень высокая, а комиссия за газ также очень низкая.
Контрактная торговля включает в себя вызов и выполнение смарт-контрактов. Когда EVM обрабатывает контрактные сделки, он должен интерпретировать и выполнять байт-код инструкции смарт-контракта по одной. Чем сложнее логика контракта, тем больше инструкций вовлечено, и тем больше ресурсов будет потреблено.
Например, время обработки перевода ERC-20 составляет примерно в 2 раза больше времени перевода EOA, в то время как более сложные смарт-контракты, такие как операции торговли на некотором DEX, могут занимать в десятки раз больше времени, чем переводы EOA. Это происходит потому, что DeFi-протоколы при выполнении сделок требуют обработки ликвидных пулов, расчета цен, обмена токенов и других сложных логик, что требует большого объема вычислений.
В режиме последовательного выполнения процесс обработки транзакций между EVM и stateDB происходит следующим образом:
В дизайне Ethereum транзакции в блоке обрабатываются поочередно, каждая транзакция имеет отдельный экземпляр для выполнения конкретных операций. Хотя каждая транзакция использует разные экземпляры EVM, все транзакции используют одну и ту же базу данных состояния stateDB.
В процессе выполнения транзакции EVM должен постоянно взаимодействовать с stateDB, считывать соответствующие данные из stateDB и записывать измененные данные обратно в stateDB.
Когда все транзакции в блоке завершены, данные в stateDB будут отправлены в глобальное состояние и сгенерируют новый корень состояния. Корень состояния является важным параметром в каждом блоке, фиксируя "сжатый результат" нового глобального состояния после выполнения блока.
Очевидные ограничения в последовательной модели выполнения EVM: транзакции должны выполняться в порядке очереди, и если возникает длительная транзакция со смарт-контрактом, остальные транзакции могут только ждать до ее завершения. Это явно не позволяет в полной мере использовать аппаратные ресурсы, такие как ЦП, и существенно ограничивает эффективность.
Оптимизация многопоточности и параллелизма в EVM
Серийное выполнение и параллельное выполнение можно сравнить с банком, у которого только одна касса, и банком с несколькими кассами. В параллельном режиме можно открыть несколько потоков для одновременной обработки нескольких транзакций, что может значительно повысить эффективность, но сложность заключается в проблеме конфликтов состояния.
Если несколько транзакций заявляют о необходимости изменить данные определенной учетной записи, то при их одновременной обработке может возникнуть конфликт. Например, если один NFT можно создать только один раз, и транзакции 1 и 2 обе заявляют о создании этого NFT, то, если оба запроса будут удовлетворены, это явно приведет к ошибке. На практике конфликты состояния возникают гораздо чаще, поэтому параллельная обработка транзакций должна включать меры по предотвращению конфликтов состояния.
Принципы параллельной оптимизации Reddio для EVM
Некоторый проект ZKRollup использует подход параллельной оптимизации для EVM, выделяя одну транзакцию для каждого потока и предоставляя временную базу данных состояния в каждом потоке, называемую pending-stateDB. Конкретные детали следующие:
Параллельное выполнение транзакций с использованием нескольких потоков: настройте несколько потоков для одновременной обработки различных транзакций, которые не мешают друг другу. Это может увеличить скорость обработки транзакций в несколько раз.
Выделите временную базу данных состояния для каждого потока: выделите независимую временную базу данных состояния для каждого потока (pending-stateDB). Каждый поток, выполняя транзакции, не будет напрямую изменять глобальную stateDB, а временно будет записывать результаты изменений состояния в pending-stateDB.
Синхронизация изменений состояния: После того как все транзакции в блоке будут выполнены, EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если в процессе выполнения различных транзакций не произошло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал способ обработки операций чтения и записи, чтобы гарантировать, что транзакции могут правильно получать доступ к данным состояния и избегать конфликтов:
Чтение: когда транзакция требует чтения состояния, EVM сначала проверяет ReadSet в ожидающем состоянии. Если необходимые данные есть в ReadSet, они читаются непосредственно из pending-stateDB. Если соответствующая пара ключ-значение не найдена в ReadSet, данные исторического состояния считываются из global stateDB предыдущего блока.
Запись операций: Все операции записи (, то есть изменения состояния ), не будут напрямую записаны в глобальную stateDB, а сначала будут записаны в WriteSet ожидающего состояния. После завершения выполнения транзакции, через проверку на конфликты, будет сделана попытка объединить результаты изменения состояния в глобальную stateDB.
Ключевая проблема параллельного выполнения заключается в конфликте состояний, который особенно заметен, когда несколько транзакций пытаются читать и записывать состояние одного и того же счета. Для этого была введена механика обнаружения конфликтов:
Обнаружение конфликтов: в процессе выполнения транзакции EVM будет отслеживать ReadSet и WriteSet различных транзакций. Если будет обнаружено, что несколько транзакций пытаются читать и записывать одни и те же элементы состояния, это будет считаться конфликтом.
Обработка конфликтов: при обнаружении конфликта конфликтная транзакция будет помечена как требующая повторного выполнения.
После выполнения всех транзакций записи изменений в нескольких pending-stateDB будут объединены в глобальный stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и сгенерирует новый корень состояния.
Улучшение производительности за счет многопоточности и параллельной оптимизации является значительным, особенно при обработке сложных транзакций смарт-контрактов. Исследования показывают, что в пулах транзакций с низкой конфликтностью (, где меньше противоречий или используются одни и те же ресурсы, производительность TPS по сравнению с традиционным последовательным выполнением увеличилась примерно в 3-5 раз. В условиях высокой конфликтности, теоретически, если использовать все возможные методы оптимизации, можно достичь даже 60-кратного повышения.
![На примере Reddio описывается путь оптимизации параллельного EVM])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
Итоги
Оптимизационное решение по многопоточному параллельному выполнению EVM в данном проекте значительно увеличило способность обработки транзакций EVM, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизм обнаружения конфликтов, публичная цепочка EVM может достичь масштабной параллелизации транзакций при гарантии согласованности состояния, решая проблемы производительности, возникающие из традиционной модели последовательного выполнения. Это закладывает важную основу для будущего развития Ethereum Rollup.
![На примере Reddio объясняется путь оптимизации параллельного EVM])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(