Параллелизация EVM: ключ к решению проблем с производительностью Ethereum
EVM, как исполнительный движок Ethereum и среда выполнения смарт-контрактов, является одним из его самых основных компонентов. Чтобы гарантировать, что смарт-контракты дают одинаковые результаты на разных узлах и соответствуют требованиям согласованности, технология виртуальных машин стала наилучшим выбором. EVM может выполнять смарт-контракты одинаковым образом на различных операционных системах и устройствах, что обеспечивает кросс-платформенную совместимость.
Умные контракты перед тем, как попасть в блокчейн, компилируются в байт-код EVM. При выполнении контракта EVM последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость газа. EVM отслеживает потребление газа в процессе выполнения каждой инструкции, а количество потребляемого газа зависит от сложности операций.
В качестве основного исполнительного механизма EVM обрабатывает транзакции последовательным образом, все транзакции ставятся в очередь и выполняются в установленном порядке. Эта простая и удобная в обслуживании конструкция, однако, с ростом числа пользователей и развитием технологий, её производственные ограничения становятся всё более заметными, особенно в Layer2.
Для ключевого компонента Layer2 Sequencer, если эффективность сопутствующих модулей достаточно высока, конечное узкое место будет зависеть от эффективности самого Sequencer. Некоторые команды с помощью экстремальной оптимизации смогли сделать так, что Sequencer может выполнять около 2000 транзакций ERC-20 в секунду. Однако для более сложных сделок TPS неизбежно значительно снизится. Поэтому параллелизация обработки транзакций становится неизбежной тенденцией будущего.
Ядро компонентов выполнения транзакций Ethereum
Помимо EVM, еще одним ключевым компонентом, тесно связанным с выполнением транзакций, является stateDB, который используется для управления состоянием аккаунтов и хранения данных Ethereum. Ethereum использует структуру данных Merkle Patricia Trie в качестве индекса базы данных. Каждое выполнение транзакции изменяет определенные данные в stateDB, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB отвечает за поддержание состояния всех аккаунтов Ethereum, включая EOA-аккаунты и контрактные аккаунты, хранит данные о балансе аккаунтов, кодах смарт-контрактов и т. д. В процессе выполнения транзакции stateDB будет читать и записывать соответствующие данные аккаунтов. После завершения выполнения транзакции stateDB отправляет новое состояние в базу данных нижнего уровня для постоянного хранения.
В общем, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех аккаунтов и контрактов. Оба компонента совместно создают среду выполнения транзакций Ethereum.
Ограничения последовательного выполнения
Транзакции в Ethereum делятся на два типа: переводы EOA и сделки с контрактами. Переводы EOA — это самый простой тип транзакций, они обрабатываются быстро и имеют низкую газовую плату. Сделки с контрактами связаны с вызовом и выполнением смарт-контрактов, EVM необходимо построчно интерпретировать и выполнять байт-код инструкции в контракте, что приводит к большей сложности и расходу ресурсов.
В режиме последовательного выполнения транзакции внутри блока обрабатываются поочередно. Каждая транзакция имеет независимый экземпляр EVM, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM постоянно взаимодействует с stateDB, читая данные и записывая измененные результаты.
Явно видно, что узкое место в этой модели последовательного выполнения: транзакции должны выполняться в очереди, и если возникает длительная транзакция смарт-контракта, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы, что значительно ограничивает эффективность.
Многопоточная параллельная оптимизация EVM
Чтобы преодолеть ограничения последовательного исполнения, в отрасли была предложена многопоточная оптимизация EVM. Эта схема аналогична банку, где несколько касс одновременно обслуживают клиентов и способны обрабатывать несколько транзакций одновременно, что значительно повышает эффективность. Однако основной проблемой, с которой сталкивается параллельное исполнение, является проблема конфликтов состояния, для которой необходимо предпринять специальные меры.
Некоторые проекты имеют следующий подход к параллельной оптимизации EVM:
Настройте несколько потоков для одновременной обработки различных транзакций, при этом потоки не мешают друг другу.
Выделите независимую временную базу данных состояния (pending-stateDB) для каждого потока. Когда потоки выполняют транзакции, изменения состояния временно записываются в pending-stateDB, а не напрямую изменяют глобальную stateDB.
После завершения выполнения всех транзакций в блоке, изменения состояния из каждого pending-stateDB последовательно синхронизируются с глобальным stateDB. Если конфликтов нет, записи могут быть успешно объединены.
Данное решение оптимизировало операции чтения и записи:
Операция чтения: сначала проверьте ReadSet в состоянии ожидания, если есть необходимые данные, считывайте их напрямую; в противном случае считайте историческое состояние из глобальной stateDB предыдущего блока.
Запись операции: все изменения сначала записываются в WriteSet в состоянии ожидания, и только после завершения выполнения транзакции они пытаются объединиться с глобальной stateDB.
Для решения проблемы конфликтов состояния была введена механика обнаружения конфликтов:
Мониторинг различных транзакций ReadSet и WriteSet, обнаружение конфликтов, когда несколько транзакций пытаются читать и записывать одни и те же элементы состояния.
Отметить конфликтующие транзакции для повторного выполнения.
После завершения всех выполненных транзакций изменения в нескольких pending-stateDB объединяются в глобальный stateDB. После успешного объединения окончательное состояние отправляется в глобальное состояние дерева, создавая новый корень состояния.
Исследования показывают, что при низкой конфликтности нагрузки параллельное выполнение TPS по сравнению с традиционным последовательным выполнением увеличивает производительность в 3-5 раз. При высокой конфликтности нагрузки, теоретически, после полной оптимизации это может достичь увеличения в 60 раз.
Резюме
Оптимизация многопоточности EVM значительно увеличивает способность обработки транзакций, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и внедряя механизм обнаружения конфликтов, удалось достичь масштабируемой параллелизации транзакций при обеспечении согласованности состояния, что решает проблемы производительности традиционной последовательной модели выполнения. Это заложило важную основу для будущего развития Ethereum Rollup.
В будущем можно дополнительно исследовать, как оптимизировать эффективность хранения, справляться с высокими конфликтными ситуациями и использовать GPU для оптимизации и других направлений, чтобы еще больше повысить производительность EVM.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 Лайков
Награда
6
6
Поделиться
комментарий
0/400
down_only_larry
· 8ч назад
рост ла Виталик Бутерин наконец-то прозрел
Посмотреть ОригиналОтветить0
BlockTalk
· 8ч назад
Любите смотреть - смотрите, в любом случае TPS поднялся.
Посмотреть ОригиналОтветить0
LiquidityOracle
· 8ч назад
Снова надуваю небо
Посмотреть ОригиналОтветить0
All-InQueen
· 8ч назад
То есть переводы стали быстрее?
Посмотреть ОригиналОтветить0
ProveMyZK
· 8ч назад
Эта оптимизация производительности принадлежит к числу лучших игроков.
Посмотреть ОригиналОтветить0
SmartContractPlumber
· 8ч назад
Прямо смотрите на риски масштабируемости, дизайн механизма блокировки слишком наивен.
Параллелизация EVM: прорыв в повышении производительности Ethereum
Параллелизация EVM: ключ к решению проблем с производительностью Ethereum
EVM, как исполнительный движок Ethereum и среда выполнения смарт-контрактов, является одним из его самых основных компонентов. Чтобы гарантировать, что смарт-контракты дают одинаковые результаты на разных узлах и соответствуют требованиям согласованности, технология виртуальных машин стала наилучшим выбором. EVM может выполнять смарт-контракты одинаковым образом на различных операционных системах и устройствах, что обеспечивает кросс-платформенную совместимость.
Умные контракты перед тем, как попасть в блокчейн, компилируются в байт-код EVM. При выполнении контракта EVM последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость газа. EVM отслеживает потребление газа в процессе выполнения каждой инструкции, а количество потребляемого газа зависит от сложности операций.
В качестве основного исполнительного механизма EVM обрабатывает транзакции последовательным образом, все транзакции ставятся в очередь и выполняются в установленном порядке. Эта простая и удобная в обслуживании конструкция, однако, с ростом числа пользователей и развитием технологий, её производственные ограничения становятся всё более заметными, особенно в Layer2.
Для ключевого компонента Layer2 Sequencer, если эффективность сопутствующих модулей достаточно высока, конечное узкое место будет зависеть от эффективности самого Sequencer. Некоторые команды с помощью экстремальной оптимизации смогли сделать так, что Sequencer может выполнять около 2000 транзакций ERC-20 в секунду. Однако для более сложных сделок TPS неизбежно значительно снизится. Поэтому параллелизация обработки транзакций становится неизбежной тенденцией будущего.
Ядро компонентов выполнения транзакций Ethereum
Помимо EVM, еще одним ключевым компонентом, тесно связанным с выполнением транзакций, является stateDB, который используется для управления состоянием аккаунтов и хранения данных Ethereum. Ethereum использует структуру данных Merkle Patricia Trie в качестве индекса базы данных. Каждое выполнение транзакции изменяет определенные данные в stateDB, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.
stateDB отвечает за поддержание состояния всех аккаунтов Ethereum, включая EOA-аккаунты и контрактные аккаунты, хранит данные о балансе аккаунтов, кодах смарт-контрактов и т. д. В процессе выполнения транзакции stateDB будет читать и записывать соответствующие данные аккаунтов. После завершения выполнения транзакции stateDB отправляет новое состояние в базу данных нижнего уровня для постоянного хранения.
В общем, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех аккаунтов и контрактов. Оба компонента совместно создают среду выполнения транзакций Ethereum.
Ограничения последовательного выполнения
Транзакции в Ethereum делятся на два типа: переводы EOA и сделки с контрактами. Переводы EOA — это самый простой тип транзакций, они обрабатываются быстро и имеют низкую газовую плату. Сделки с контрактами связаны с вызовом и выполнением смарт-контрактов, EVM необходимо построчно интерпретировать и выполнять байт-код инструкции в контракте, что приводит к большей сложности и расходу ресурсов.
В режиме последовательного выполнения транзакции внутри блока обрабатываются поочередно. Каждая транзакция имеет независимый экземпляр EVM, но все транзакции используют одну и ту же stateDB. В процессе выполнения EVM постоянно взаимодействует с stateDB, читая данные и записывая измененные результаты.
Явно видно, что узкое место в этой модели последовательного выполнения: транзакции должны выполняться в очереди, и если возникает длительная транзакция смарт-контракта, другие транзакции могут только ждать, что не позволяет в полной мере использовать аппаратные ресурсы, что значительно ограничивает эффективность.
Многопоточная параллельная оптимизация EVM
Чтобы преодолеть ограничения последовательного исполнения, в отрасли была предложена многопоточная оптимизация EVM. Эта схема аналогична банку, где несколько касс одновременно обслуживают клиентов и способны обрабатывать несколько транзакций одновременно, что значительно повышает эффективность. Однако основной проблемой, с которой сталкивается параллельное исполнение, является проблема конфликтов состояния, для которой необходимо предпринять специальные меры.
Некоторые проекты имеют следующий подход к параллельной оптимизации EVM:
Настройте несколько потоков для одновременной обработки различных транзакций, при этом потоки не мешают друг другу.
Выделите независимую временную базу данных состояния (pending-stateDB) для каждого потока. Когда потоки выполняют транзакции, изменения состояния временно записываются в pending-stateDB, а не напрямую изменяют глобальную stateDB.
После завершения выполнения всех транзакций в блоке, изменения состояния из каждого pending-stateDB последовательно синхронизируются с глобальным stateDB. Если конфликтов нет, записи могут быть успешно объединены.
Данное решение оптимизировало операции чтения и записи:
Операция чтения: сначала проверьте ReadSet в состоянии ожидания, если есть необходимые данные, считывайте их напрямую; в противном случае считайте историческое состояние из глобальной stateDB предыдущего блока.
Запись операции: все изменения сначала записываются в WriteSet в состоянии ожидания, и только после завершения выполнения транзакции они пытаются объединиться с глобальной stateDB.
Для решения проблемы конфликтов состояния была введена механика обнаружения конфликтов:
После завершения всех выполненных транзакций изменения в нескольких pending-stateDB объединяются в глобальный stateDB. После успешного объединения окончательное состояние отправляется в глобальное состояние дерева, создавая новый корень состояния.
Исследования показывают, что при низкой конфликтности нагрузки параллельное выполнение TPS по сравнению с традиционным последовательным выполнением увеличивает производительность в 3-5 раз. При высокой конфликтности нагрузки, теоретически, после полной оптимизации это может достичь увеличения в 60 раз.
Резюме
Оптимизация многопоточности EVM значительно увеличивает способность обработки транзакций, выделяя временные хранилища состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и внедряя механизм обнаружения конфликтов, удалось достичь масштабируемой параллелизации транзакций при обеспечении согласованности состояния, что решает проблемы производительности традиционной последовательной модели выполнения. Это заложило важную основу для будущего развития Ethereum Rollup.
В будущем можно дополнительно исследовать, как оптимизировать эффективность хранения, справляться с высокими конфликтными ситуациями и использовать GPU для оптимизации и других направлений, чтобы еще больше повысить производительность EVM.