Оптимизация параллелизма EVM: Повышение эффективности обработки транзакций Ethereum
EVM как основной исполнительный движок Ethereum, его позиционирование – "среда выполнения смарт-контрактов". Для обеспечения консистентных результатов выполнения смарт-контрактов на различных узлах EVM предоставляет кросс-платформенную виртуальную машину, аналогичную виртуальной машине Java (JVM).
Умные контракты при развертывании компилируются в байт-код EVM и хранятся в цепочке. EVM выполняет контракт, последовательно считывая этот байт-код; каждая инструкция имеет соответствующую стоимость в Газе. EVM отслеживает потребление Газа в процессе выполнения инструкций, и объем потребления зависит от сложности операций.
Традиционный EVM обрабатывает транзакции последовательно, все транзакции выполняются в единой очереди в определенном порядке. Этот дизайн прост в обслуживании, но с ростом числа пользователей и применением технологии Rollup все более очевидными становятся узкие места производительности последовательного выполнения.
В архитектуре Rollup Sequencer является ключевым компонентом Layer2 и выполняет все вычислительные задачи. Если другие внешние модули достаточно эффективны, последовательное выполнение Sequencer станет наибольшей узкой местом. Одна команда с помощью экстремальной оптимизации смогла достичь выполнения более 2000 транзакций ERC-20 в секунду, но для более сложных сделок TPS все еще значительно снижается. Таким образом, параллелизация обработки транзакций становится тенденцией будущего развития.
Помимо EVM, еще одной ключевой компонентой, связанной с выполнением транзакций в go-ethereum, является stateDB, который используется для управления состоянием счетов и хранения данных. Ethereum использует структуру данных Merkle Patricia Trie в качестве индексируемой базы данных, и каждый раз при выполнении транзакции EVM данные в stateDB изменяются, что в конечном итоге отражается в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех аккаунтов Ethereum, включая баланс аккаунтов, код смарт-контрактов и так далее. В процессе выполнения транзакции stateDB будет читать и записывать данные соответствующего аккаунта, а после завершения выполнения новые состояния будут отправлены в базу данных нижнего уровня для долговременного хранения.
EVM и stateDB совместно создают среду выполнения транзакций Ethereum. EVM отвечает за интерпретацию и выполнение команд смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех счетов и контрактов.
В режиме последовательного выполнения транзакции внутри блока обрабатываются по порядку. Каждая транзакция использует независимый экземпляр EVM, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM необходимо постоянно взаимодействовать с stateDB, считывая соответствующие данные и записывая результаты изменений.
После завершения выполнения всех транзакций в блоке данные в stateDB будут отправлены в глобальное состояние дерева, создавая новый корень состояния. Основная проблема этой последовательной модели заключается в том, что транзакции должны выполняться по очереди, что не позволяет в полной мере использовать аппаратные ресурсы, особенно при работе со сложными транзакциями смарт-контрактов, что снижает эффективность.
Чтобы повысить эффективность обработки транзакций, некоторые проекты начали пытаться оптимизировать многопоточность EVM. Это похоже на то, как банки открывают несколько касс для одновременного обслуживания клиентов, что может увеличить скорость обработки в несколько раз, но необходимо решить возможные проблемы с конфликтом состояния.
Некоторый проект ZKRollup оптимизирует EVM, выделяя для каждого потока временную базу данных состояния (pending-stateDB). Конкретная реализация включает:
Параллельное выполнение сделок в многопоточном режиме, без взаимного влияния.
Каждый поток имеет независимую pending-stateDB, изменения состояния записываются сюда при выполнении сделки.
После выполнения всех транзакций изменения из pending-stateDB будут синхронизированы в глобальный stateDB.
Данное решение оптимизировало операции чтения и записи:
При выполнении операции чтения сначала проверьте ReadSet в pending-stateDB; если нужные данные имеются, читайте их напрямую, иначе читайте историческое состояние из глобального stateDB.
Операции записи не записываются напрямую в глобальную stateDB, а сначала фиксируются в WriteSet временной stateDB.
Для обработки конфликтов состояния введён механизм обнаружения конфликтов:
Мониторинг различных транзакций ReadSet и WriteSet, обнаружение конфликтов, если несколько транзакций читают и записывают одни и те же элементы состояния.
Конфликтные транзакции будут помечены как требующие повторного выполнения.
После выполнения всех транзакций изменения нескольких записей в состоянии pending-stateDB будут объединены в глобальный stateDB, и после успешного выполнения они будут отправлены в глобальное состояние дерева и сгенерируют новый корень состояния.
Исследования показывают, что в условиях низкой конфликтности рабочей нагрузки TPS параллельного EVM по сравнению с традиционным последовательным выполнением увеличивается в 3-5 раз. В условиях высокой конфликтности рабочей нагрузки теоретически максимальное увеличение может достигать 60 раз.
Это решение по многопоточной параллельной оптимизации, через временную базу данных состояния и параллельное выполнение, значительно увеличило производительность обработки транзакций EVM. Оптимизация операций чтения и записи и внедрение механизма обнаружения конфликтов позволило добиться масштабной параллелизации транзакций при гарантии согласованности состояния, решая проблему производительности последовательного выполнения и закладывая основу для будущего развития Ethereum Rollup.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
5
Поделиться
комментарий
0/400
AirdropHunterZhang
· 07-29 02:07
Не буду. Каждый день 60 раз. Блинчики все еще по этой цене.
Посмотреть ОригиналОтветить0
GateUser-afe07a92
· 07-28 22:11
Это всего лишь небольшое увеличение TPS.
Посмотреть ОригиналОтветить0
ZKProofEnthusiast
· 07-28 22:09
Мастер Фу TPS так быстро еще и в блокчейне приватность?
Посмотреть ОригиналОтветить0
¯\_(ツ)_/¯
· 07-28 21:56
Продолжай майнинг, просто так.
Посмотреть ОригиналОтветить0
GateUser-aa7df71e
· 07-28 21:48
войти в позицию, братья, большой памп TPS скоро будет
Оптимизация EVM параллельно: Повышение эффективности обработки транзакций Ethereum в 5-60 раз
Оптимизация параллелизма EVM: Повышение эффективности обработки транзакций Ethereum
EVM как основной исполнительный движок Ethereum, его позиционирование – "среда выполнения смарт-контрактов". Для обеспечения консистентных результатов выполнения смарт-контрактов на различных узлах EVM предоставляет кросс-платформенную виртуальную машину, аналогичную виртуальной машине Java (JVM).
Умные контракты при развертывании компилируются в байт-код EVM и хранятся в цепочке. EVM выполняет контракт, последовательно считывая этот байт-код; каждая инструкция имеет соответствующую стоимость в Газе. EVM отслеживает потребление Газа в процессе выполнения инструкций, и объем потребления зависит от сложности операций.
Традиционный EVM обрабатывает транзакции последовательно, все транзакции выполняются в единой очереди в определенном порядке. Этот дизайн прост в обслуживании, но с ростом числа пользователей и применением технологии Rollup все более очевидными становятся узкие места производительности последовательного выполнения.
В архитектуре Rollup Sequencer является ключевым компонентом Layer2 и выполняет все вычислительные задачи. Если другие внешние модули достаточно эффективны, последовательное выполнение Sequencer станет наибольшей узкой местом. Одна команда с помощью экстремальной оптимизации смогла достичь выполнения более 2000 транзакций ERC-20 в секунду, но для более сложных сделок TPS все еще значительно снижается. Таким образом, параллелизация обработки транзакций становится тенденцией будущего развития.
Помимо EVM, еще одной ключевой компонентой, связанной с выполнением транзакций в go-ethereum, является stateDB, который используется для управления состоянием счетов и хранения данных. Ethereum использует структуру данных Merkle Patricia Trie в качестве индексируемой базы данных, и каждый раз при выполнении транзакции EVM данные в stateDB изменяются, что в конечном итоге отражается в глобальном состоянии дерева.
stateDB отвечает за поддержку состояния всех аккаунтов Ethereum, включая баланс аккаунтов, код смарт-контрактов и так далее. В процессе выполнения транзакции stateDB будет читать и записывать данные соответствующего аккаунта, а после завершения выполнения новые состояния будут отправлены в базу данных нижнего уровня для долговременного хранения.
EVM и stateDB совместно создают среду выполнения транзакций Ethereum. EVM отвечает за интерпретацию и выполнение команд смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех счетов и контрактов.
В режиме последовательного выполнения транзакции внутри блока обрабатываются по порядку. Каждая транзакция использует независимый экземпляр EVM, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM необходимо постоянно взаимодействовать с stateDB, считывая соответствующие данные и записывая результаты изменений.
После завершения выполнения всех транзакций в блоке данные в stateDB будут отправлены в глобальное состояние дерева, создавая новый корень состояния. Основная проблема этой последовательной модели заключается в том, что транзакции должны выполняться по очереди, что не позволяет в полной мере использовать аппаратные ресурсы, особенно при работе со сложными транзакциями смарт-контрактов, что снижает эффективность.
Чтобы повысить эффективность обработки транзакций, некоторые проекты начали пытаться оптимизировать многопоточность EVM. Это похоже на то, как банки открывают несколько касс для одновременного обслуживания клиентов, что может увеличить скорость обработки в несколько раз, но необходимо решить возможные проблемы с конфликтом состояния.
Некоторый проект ZKRollup оптимизирует EVM, выделяя для каждого потока временную базу данных состояния (pending-stateDB). Конкретная реализация включает:
Параллельное выполнение сделок в многопоточном режиме, без взаимного влияния.
Каждый поток имеет независимую pending-stateDB, изменения состояния записываются сюда при выполнении сделки.
После выполнения всех транзакций изменения из pending-stateDB будут синхронизированы в глобальный stateDB.
Данное решение оптимизировало операции чтения и записи:
При выполнении операции чтения сначала проверьте ReadSet в pending-stateDB; если нужные данные имеются, читайте их напрямую, иначе читайте историческое состояние из глобального stateDB.
Операции записи не записываются напрямую в глобальную stateDB, а сначала фиксируются в WriteSet временной stateDB.
Для обработки конфликтов состояния введён механизм обнаружения конфликтов:
Мониторинг различных транзакций ReadSet и WriteSet, обнаружение конфликтов, если несколько транзакций читают и записывают одни и те же элементы состояния.
Конфликтные транзакции будут помечены как требующие повторного выполнения.
После выполнения всех транзакций изменения нескольких записей в состоянии pending-stateDB будут объединены в глобальный stateDB, и после успешного выполнения они будут отправлены в глобальное состояние дерева и сгенерируют новый корень состояния.
Исследования показывают, что в условиях низкой конфликтности рабочей нагрузки TPS параллельного EVM по сравнению с традиционным последовательным выполнением увеличивается в 3-5 раз. В условиях высокой конфликтности рабочей нагрузки теоретически максимальное увеличение может достигать 60 раз.
Это решение по многопоточной параллельной оптимизации, через временную базу данных состояния и параллельное выполнение, значительно увеличило производительность обработки транзакций EVM. Оптимизация операций чтения и записи и внедрение механизма обнаружения конфликтов позволило добиться масштабной параллелизации транзакций при гарантии согласованности состояния, решая проблему производительности последовательного выполнения и закладывая основу для будущего развития Ethereum Rollup.