Как известно, EVM является одним из самых важных основных компонентов Ethereum, играя ключевую роль как "исполнительный движок" и "среда выполнения смарт-контрактов". Наличие виртуальной машины в сети публичных блокчейнов, состоящей из тысяч узлов, позволяет смарт-контрактам выполняться одинаково на узлах с различными аппаратными конфигурациями, обеспечивая согласованность результатов. Эта кросс-платформенная совместимость весьма схожа с Java Virtual Machine (JVM).
Умные контракты перед тем, как быть размещенными в блокчейне, компилируются в байт-код EVM. При выполнении контракта EVM последовательно считывает этот байт-код, каждая команда имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas в процессе выполнения команд, и объем потребления зависит от сложности операций.
В качестве основного исполнительного движка Ethereum EVM использует последовательный способ обработки транзакций. Все транзакции ставятся в очередь в одном единственном порядке и выполняются по определенной последовательности. Этот дизайн прост в обслуживании, но по мере увеличения числа пользователей и технологических итераций его производственные узкие места становятся все более очевидными, особенно после достижения зрелости технологий Rollup, что особенно заметно в сетях второго уровня Ethereum.
Секвенсер, как ключевой компонент Layer2, выполняет все вычислительные задачи в виде одного сервера. Если эффективность сопутствующих внешних модулей будет достаточно высокой, конечное узкое место будет зависеть от самой эффективности секвенсера, и в этом случае последовательное выполнение станет огромным препятствием.
Некоторая команда путем экстремальной оптимизации уровня DA и модуля чтения и записи данных сделала так, что Sequencer может выполнять до 2000 более транзакций ERC-20 в секунду. Эта цифра кажется высокой, но для сложных транзакций значение TPS обязательно значительно снизится. Таким образом, параллелизация обработки транзакций станет неизбежной тенденцией будущего.
Два основных компонента выполнения транзакций Ethereum
Помимо 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 выглядит следующим образом:
Транзакции внутри блока обрабатываются по порядку, каждая транзакция имеет отдельный экземпляр для выполнения конкретной операции.
Хотя каждая транзакция использует разные экземпляры EVM, все транзакции используют одну и ту же базу данных состояния stateDB.
В процессе выполнения сделки EVM необходимо постоянно взаимодействовать с stateDB, считывать соответствующие данные и записывать измененные данные обратно в stateDB.
После завершения всех сделок данные в stateDB будут отправлены в глобальное состояние дерева и будет сгенерирован новый корень состояния.
Очевидно, что в EVM есть узкое место в режиме последовательного выполнения: транзакции должны выполняться в порядке очереди, и если возникает смарт-контракт, требующий много времени, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы и значительно ограничивает эффективность.
Оптимизация многопоточности EVM
Параллельный EVM похож на банк с несколькими кассами, который может открывать несколько потоков для одновременной обработки множественных транзакций, что может значительно повысить эффективность. Но сложность заключается в проблеме конфликта состояния, которая требует координации.
Некоторые идеи параллельной оптимизации EVM в проекте ZKRollup следующие:
Параллельное выполнение сделок с использованием нескольких потоков: настройка нескольких потоков для одновременной обработки различных сделок, при этом потоки не мешают друг другу, что может увеличить скорость обработки сделок в несколько раз.
Назначьте временную базу данных состояния для каждого потока: каждому потоку назначается отдельная временная база данных состояния (pending-stateDB). Потоки выполняют транзакции, не изменяя напрямую глобальную stateDB, а временно фиксируя результаты изменения состояния в pending-stateDB.
Синхронизация изменений состояния: После выполнения всех транзакций в блоке EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если в процессе выполнения различных транзакций не возникло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал обработку операций чтения и записи, чтобы обеспечить правильный доступ к статусным данным транзакций и избежать конфликтов:
Операция чтения: Когда транзакция требует чтения состояния, EVM сначала проверяет ReadSet ожидаемого состояния. Если необходимые данные существуют, они считываются непосредственно из pending-stateDB. Если в ReadSet не найдено соответствующей пары ключ-значение, данные исторического состояния считываются из глобального stateDB соответствующего предыдущего блока.
Операции записи: все операции записи не записываются непосредственно в глобальную stateDB, а сначала фиксируются в WriteSet ожидающего состояния. После завершения выполнения транзакции, результаты изменения состояния пытаются быть объединены в глобальную stateDB с помощью проверки конфликтов.
Для решения проблемы конфликтов состояний была введена механика обнаружения конфликтов:
Обнаружение конфликтов: EVM отслеживает ReadSet и WriteSet различных транзакций. Если несколько транзакций пытаются читать и записывать один и тот же элемент состояния, это считается конфликтом.
Обработка конфликтов: при обнаружении конфликта конфликтная транзакция будет помечена как требующая повторного выполнения.
После выполнения всех транзакций изменения, зафиксированные в нескольких pending-stateDB, будут объединены в глобальном stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и сгенерирует новый корень состояния.
Оптимизация параллельного выполнения многопоточности значительно повышает производительность, особенно при обработке сложных транзакций смарт-контрактов. Исследования показывают, что в условиях низкой конфликтности нагрузка, TPS в тестах по сравнению с традиционным последовательным выполнением увеличивается в 3–5 раз. В условиях высокой конфликтности, теоретически, если использовать все методы оптимизации, можно достичь повышения в 60 раз.
Резюме
План оптимизации многопоточности EVM значительно увеличивает способность обработки транзакций EVM, распределяя временные хранилища состояния для каждой транзакции и параллельно выполняя транзакции в разных потоках. Оптимизируя операции чтения и записи и вводя механизмы обнаружения конфликтов, публичные цепочки EVM могут обеспечить масштабную параллелизацию транзакций при гарантии согласованности состояния, решая проблемы производительности, возникающие в традиционной последовательной модели исполнения. Это закладывает важную основу для будущего развития Rollup Ethereum.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
8
Репост
Поделиться
комментарий
0/400
TokenVelocityTrauma
· 08-02 02:05
Необходимо улучшить узкие места в производительности.
Посмотреть ОригиналОтветить0
ForkPrince
· 07-30 22:41
Оптимизация и улучшение очень ожидаются
Посмотреть ОригиналОтветить0
MEVVictimAlliance
· 07-30 14:54
Эффективность значительно увеличилась
Посмотреть ОригиналОтветить0
FalseProfitProphet
· 07-30 10:43
Параллелизация ускорила это невероятно
Посмотреть ОригиналОтветить0
ShitcoinConnoisseur
· 07-30 10:42
Серьезное узкое место в производительности последовательного выполнения
Оптимизация EVM: многопоточная параллельная обработка для повышения эффективности обработки транзакций
Путь оптимизации параллелизации EVM
Как известно, EVM является одним из самых важных основных компонентов Ethereum, играя ключевую роль как "исполнительный движок" и "среда выполнения смарт-контрактов". Наличие виртуальной машины в сети публичных блокчейнов, состоящей из тысяч узлов, позволяет смарт-контрактам выполняться одинаково на узлах с различными аппаратными конфигурациями, обеспечивая согласованность результатов. Эта кросс-платформенная совместимость весьма схожа с Java Virtual Machine (JVM).
Умные контракты перед тем, как быть размещенными в блокчейне, компилируются в байт-код EVM. При выполнении контракта EVM последовательно считывает этот байт-код, каждая команда имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas в процессе выполнения команд, и объем потребления зависит от сложности операций.
В качестве основного исполнительного движка Ethereum EVM использует последовательный способ обработки транзакций. Все транзакции ставятся в очередь в одном единственном порядке и выполняются по определенной последовательности. Этот дизайн прост в обслуживании, но по мере увеличения числа пользователей и технологических итераций его производственные узкие места становятся все более очевидными, особенно после достижения зрелости технологий Rollup, что особенно заметно в сетях второго уровня Ethereum.
Секвенсер, как ключевой компонент Layer2, выполняет все вычислительные задачи в виде одного сервера. Если эффективность сопутствующих внешних модулей будет достаточно высокой, конечное узкое место будет зависеть от самой эффективности секвенсера, и в этом случае последовательное выполнение станет огромным препятствием.
Некоторая команда путем экстремальной оптимизации уровня DA и модуля чтения и записи данных сделала так, что Sequencer может выполнять до 2000 более транзакций ERC-20 в секунду. Эта цифра кажется высокой, но для сложных транзакций значение TPS обязательно значительно снизится. Таким образом, параллелизация обработки транзакций станет неизбежной тенденцией будущего.
Два основных компонента выполнения транзакций Ethereum
Помимо 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 выглядит следующим образом:
Очевидно, что в EVM есть узкое место в режиме последовательного выполнения: транзакции должны выполняться в порядке очереди, и если возникает смарт-контракт, требующий много времени, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы и значительно ограничивает эффективность.
Оптимизация многопоточности EVM
Параллельный EVM похож на банк с несколькими кассами, который может открывать несколько потоков для одновременной обработки множественных транзакций, что может значительно повысить эффективность. Но сложность заключается в проблеме конфликта состояния, которая требует координации.
Некоторые идеи параллельной оптимизации EVM в проекте ZKRollup следующие:
Параллельное выполнение сделок с использованием нескольких потоков: настройка нескольких потоков для одновременной обработки различных сделок, при этом потоки не мешают друг другу, что может увеличить скорость обработки сделок в несколько раз.
Назначьте временную базу данных состояния для каждого потока: каждому потоку назначается отдельная временная база данных состояния (pending-stateDB). Потоки выполняют транзакции, не изменяя напрямую глобальную stateDB, а временно фиксируя результаты изменения состояния в pending-stateDB.
Синхронизация изменений состояния: После выполнения всех транзакций в блоке EVM последовательно синхронизирует результаты изменений состояния, записанные в каждом pending-stateDB, в глобальный stateDB. Если в процессе выполнения различных транзакций не возникло конфликтов состояния, записи из pending-stateDB могут быть успешно объединены в глобальный stateDB.
Проект оптимизировал обработку операций чтения и записи, чтобы обеспечить правильный доступ к статусным данным транзакций и избежать конфликтов:
Операция чтения: Когда транзакция требует чтения состояния, EVM сначала проверяет ReadSet ожидаемого состояния. Если необходимые данные существуют, они считываются непосредственно из pending-stateDB. Если в ReadSet не найдено соответствующей пары ключ-значение, данные исторического состояния считываются из глобального stateDB соответствующего предыдущего блока.
Операции записи: все операции записи не записываются непосредственно в глобальную stateDB, а сначала фиксируются в WriteSet ожидающего состояния. После завершения выполнения транзакции, результаты изменения состояния пытаются быть объединены в глобальную stateDB с помощью проверки конфликтов.
Для решения проблемы конфликтов состояний была введена механика обнаружения конфликтов:
После выполнения всех транзакций изменения, зафиксированные в нескольких pending-stateDB, будут объединены в глобальном stateDB. Если объединение прошло успешно, EVM отправит окончательное состояние в глобальное состояние дерева и сгенерирует новый корень состояния.
Оптимизация параллельного выполнения многопоточности значительно повышает производительность, особенно при обработке сложных транзакций смарт-контрактов. Исследования показывают, что в условиях низкой конфликтности нагрузка, TPS в тестах по сравнению с традиционным последовательным выполнением увеличивается в 3–5 раз. В условиях высокой конфликтности, теоретически, если использовать все методы оптимизации, можно достичь повышения в 60 раз.
Резюме
План оптимизации многопоточности EVM значительно увеличивает способность обработки транзакций EVM, распределяя временные хранилища состояния для каждой транзакции и параллельно выполняя транзакции в разных потоках. Оптимизируя операции чтения и записи и вводя механизмы обнаружения конфликтов, публичные цепочки EVM могут обеспечить масштабную параллелизацию транзакций при гарантии согласованности состояния, решая проблемы производительности, возникающие в традиционной последовательной модели исполнения. Это закладывает важную основу для будущего развития Rollup Ethereum.