Параллельная оптимизация EVM: Ключ к повышению производительности Блокчейн
EVM, как основной исполнительный движок Ethereum, всегда обрабатывал транзакции в последовательном режиме. Этот метод, хотя и прост в обслуживании, с ростом числа пользователей и развитием технологий все больше демонстрирует свои ограничения по производительности. Особенно в условиях широкого применения технологии Rollup, последовательное выполнение EVM стало важным фактором, сдерживающим развитие второго уровня сети.
Секвенсер как ключевой компонент Layer2 берет на себя все вычислительные задачи в виде единого сервера. Когда эффективность других модулей достаточно высока, мощность обработки самого Секвенсера становится окончательным узким местом. Некоторые команды оптимизировали уровень DA и модули чтения и записи данных, что позволяет Секвенсеру выполнять около 2000 транзакций ERC-20 в секунду. Эта цифра кажется немалой, но при более сложных сделках TPS неизбежно значительно снизится. Таким образом, параллелизация обработки транзакций становится неизбежной тенденцией будущего.
В структуре кода Ethereum, помимо EVM, stateDB также является ключевым компонентом, тесно связанным с выполнением транзакций. Он отвечает за управление состоянием учетных записей и хранением данных Ethereum. Каждый раз, когда EVM выполняет транзакцию, определенные данные в stateDB изменяются, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB в основном поддерживает состояние всех аккаунтов Ethereum, включая обычные аккаунты и контракты, хранит информацию о балансе аккаунтов, коде смарт-контрактов и т.д. В процессе выполнения транзакции stateDB читает и записывает соответствующие данные аккаунта, а после завершения выполнения отправляет новое состояние на постоянное сохранение в базу данных.
В традиционной модели последовательного выполнения транзакции внутри одного Блока обрабатываются по порядку. Каждая транзакция выполняется с использованием отдельного экземпляра EVM для конкретных операций, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM необходимо часто взаимодействовать с stateDB, считывая и записывая соответствующие данные.
Недостатки этой модели последовательного выполнения очевидны: транзакции должны ожидать своей очереди на выполнение, и если возникает сложная транзакция, требующая много времени, последующие транзакции вынуждены ждать, что не позволяет в полной мере использовать аппаратные ресурсы и серьезно ограничивает эффективность обработки.
Чтобы преодолеть этот瓶颈, индустрия предложила многопоточное параллельное оптимизационное решение для EVM. Основная идея заключается в том, чтобы открыть несколько потоков для одновременной обработки нескольких транзакций, значительно повышая эффективность. Однако, основным вызовом параллельного выполнения является то, как решить проблему конфликтов состояния.
Некоторые проекты, оптимизирующие EVM для параллельной работы, заслуживают внимания. Они выделяют для каждого потока одну транзакцию и временную базу данных состояния (pending-stateDB). Конкретные шаги следующие:
Многопоточное параллельное выполнение транзакций, потоки не мешают друг другу.
Каждый поток имеет независимую pending-stateDB, при выполнении транзакций глобальная stateDB не изменяется напрямую, а изменения состояния временно сохраняются в pending-stateDB.
После завершения выполнения всех транзакций в блоке, EVM последовательно синхронизирует изменения состояния из каждой pending-stateDB в глобальную stateDB.
Проект также оптимизировал операции чтения и записи:
При выполнении операции чтения EVM сначала проверяет ReadSet в ожидаемом состоянии. Если данные необходимы, они считываются напрямую из pending-stateDB; в противном случае они считываются из глобального stateDB предыдущего блока.
Запись операции не записывается напрямую в глобальную stateDB, а сначала фиксируется в WriteSet ожидающего состояния. После завершения выполнения транзакции осуществляется попытка объединения с глобальной stateDB через проверку конфликтов.
Для решения проблемы конфликтов состояния этот проект внедрил механизм обнаружения конфликтов:
В процессе выполнения мониторятся ReadSet и WriteSet различных транзакций, и если несколько транзакций читают и записывают одни и те же элементы состояния, это рассматривается как конфликт.
Отметить конфликтные транзакции как требующие повторного выполнения.
После завершения всех транзакций записи изменений нескольких pending-stateDB объединяются в глобальный stateDB. После успешного объединения окончательное состояние отправляется в глобальное дерево состояния, создавая новый корень состояния.
Многопоточная параллельная оптимизация значительно повысила производительность, особенно при обработке сложных сделок со смарт-контрактами. Исследования показывают, что в условиях низкой конфликтности производительность TPS в бенчмарках увеличилась в 3-5 раз по сравнению с традиционным последовательным выполнением. При высокой конфликтности, теоретически, при использовании всех методов оптимизации можно достичь увеличения в 60 раз.
Этот оптимизационный план многопоточности EVM значительно увеличил способность обработки транзакций EVM, выделяя временные библиотеки состояния для каждой транзакции и выполняя их параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизм обнаружения конфликтов, он достиг масштабной параллелизации транзакций, обеспечивая при этом согласованность состояния, эффективно решая проблему производительности традиционной модели последовательного выполнения. Это заложило важную основу для будущего расширения экосистемы Ethereum.
Будущие направления исследований могут включать дальнейшую оптимизацию эффективности хранения, улучшение решений для обработки в условиях высокой конфликтности, а также изучение возможности оптимизации с использованием GPU. Эти достижения предоставят новый импульс для устойчивого развития Блокчейн технологий.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
7
Репост
Поделиться
комментарий
0/400
MEVVictimAlliance
· 8ч назад
Параллельные задачи, быстро разберитесь, а то я застрял.
Посмотреть ОригиналОтветить0
MelonField
· 8ч назад
Все еще хвалят EVM, это выглядит не очень хорошо.
Посмотреть ОригиналОтветить0
MetaDreamer
· 8ч назад
Увеличение производительности в 60 раз? gm снова должен взяться за дело.
Посмотреть ОригиналОтветить0
TestnetScholar
· 8ч назад
Эта карта, давай быстрее оптимизировать
Посмотреть ОригиналОтветить0
faded_wojak.eth
· 8ч назад
Карла На луну啊
Посмотреть ОригиналОтветить0
BugBountyHunter
· 8ч назад
Если застрял, нужно работать параллельно и конкурировать!
Посмотреть ОригиналОтветить0
DefiPlaybook
· 8ч назад
Этот предел не ждет, чтобы его обобрали? Боты в восторге от того, что вырвались вперёд.
Оптимизация EVM параллельных вычислений: ключевая технология, повышающая производительность Блокчейн в 60 раз
Параллельная оптимизация EVM: Ключ к повышению производительности Блокчейн
EVM, как основной исполнительный движок Ethereum, всегда обрабатывал транзакции в последовательном режиме. Этот метод, хотя и прост в обслуживании, с ростом числа пользователей и развитием технологий все больше демонстрирует свои ограничения по производительности. Особенно в условиях широкого применения технологии Rollup, последовательное выполнение EVM стало важным фактором, сдерживающим развитие второго уровня сети.
Секвенсер как ключевой компонент Layer2 берет на себя все вычислительные задачи в виде единого сервера. Когда эффективность других модулей достаточно высока, мощность обработки самого Секвенсера становится окончательным узким местом. Некоторые команды оптимизировали уровень DA и модули чтения и записи данных, что позволяет Секвенсеру выполнять около 2000 транзакций ERC-20 в секунду. Эта цифра кажется немалой, но при более сложных сделках TPS неизбежно значительно снизится. Таким образом, параллелизация обработки транзакций становится неизбежной тенденцией будущего.
В структуре кода Ethereum, помимо EVM, stateDB также является ключевым компонентом, тесно связанным с выполнением транзакций. Он отвечает за управление состоянием учетных записей и хранением данных Ethereum. Каждый раз, когда EVM выполняет транзакцию, определенные данные в stateDB изменяются, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB в основном поддерживает состояние всех аккаунтов Ethereum, включая обычные аккаунты и контракты, хранит информацию о балансе аккаунтов, коде смарт-контрактов и т.д. В процессе выполнения транзакции stateDB читает и записывает соответствующие данные аккаунта, а после завершения выполнения отправляет новое состояние на постоянное сохранение в базу данных.
В традиционной модели последовательного выполнения транзакции внутри одного Блока обрабатываются по порядку. Каждая транзакция выполняется с использованием отдельного экземпляра EVM для конкретных операций, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM необходимо часто взаимодействовать с stateDB, считывая и записывая соответствующие данные.
Недостатки этой модели последовательного выполнения очевидны: транзакции должны ожидать своей очереди на выполнение, и если возникает сложная транзакция, требующая много времени, последующие транзакции вынуждены ждать, что не позволяет в полной мере использовать аппаратные ресурсы и серьезно ограничивает эффективность обработки.
Чтобы преодолеть этот瓶颈, индустрия предложила многопоточное параллельное оптимизационное решение для EVM. Основная идея заключается в том, чтобы открыть несколько потоков для одновременной обработки нескольких транзакций, значительно повышая эффективность. Однако, основным вызовом параллельного выполнения является то, как решить проблему конфликтов состояния.
Некоторые проекты, оптимизирующие EVM для параллельной работы, заслуживают внимания. Они выделяют для каждого потока одну транзакцию и временную базу данных состояния (pending-stateDB). Конкретные шаги следующие:
Многопоточное параллельное выполнение транзакций, потоки не мешают друг другу.
Каждый поток имеет независимую pending-stateDB, при выполнении транзакций глобальная stateDB не изменяется напрямую, а изменения состояния временно сохраняются в pending-stateDB.
После завершения выполнения всех транзакций в блоке, EVM последовательно синхронизирует изменения состояния из каждой pending-stateDB в глобальную stateDB.
Проект также оптимизировал операции чтения и записи:
При выполнении операции чтения EVM сначала проверяет ReadSet в ожидаемом состоянии. Если данные необходимы, они считываются напрямую из pending-stateDB; в противном случае они считываются из глобального stateDB предыдущего блока.
Запись операции не записывается напрямую в глобальную stateDB, а сначала фиксируется в WriteSet ожидающего состояния. После завершения выполнения транзакции осуществляется попытка объединения с глобальной stateDB через проверку конфликтов.
Для решения проблемы конфликтов состояния этот проект внедрил механизм обнаружения конфликтов:
В процессе выполнения мониторятся ReadSet и WriteSet различных транзакций, и если несколько транзакций читают и записывают одни и те же элементы состояния, это рассматривается как конфликт.
Отметить конфликтные транзакции как требующие повторного выполнения.
После завершения всех транзакций записи изменений нескольких pending-stateDB объединяются в глобальный stateDB. После успешного объединения окончательное состояние отправляется в глобальное дерево состояния, создавая новый корень состояния.
Многопоточная параллельная оптимизация значительно повысила производительность, особенно при обработке сложных сделок со смарт-контрактами. Исследования показывают, что в условиях низкой конфликтности производительность TPS в бенчмарках увеличилась в 3-5 раз по сравнению с традиционным последовательным выполнением. При высокой конфликтности, теоретически, при использовании всех методов оптимизации можно достичь увеличения в 60 раз.
Этот оптимизационный план многопоточности EVM значительно увеличил способность обработки транзакций EVM, выделяя временные библиотеки состояния для каждой транзакции и выполняя их параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизм обнаружения конфликтов, он достиг масштабной параллелизации транзакций, обеспечивая при этом согласованность состояния, эффективно решая проблему производительности традиционной модели последовательного выполнения. Это заложило важную основу для будущего расширения экосистемы Ethereum.
Будущие направления исследований могут включать дальнейшую оптимизацию эффективности хранения, улучшение решений для обработки в условиях высокой конфликтности, а также изучение возможности оптимизации с использованием GPU. Эти достижения предоставят новый импульс для устойчивого развития Блокчейн технологий.