Путь параллелизации EVM: от последовательного к многопоточному исполнению
Как известно, EVM является核心执行引擎 Ethereum, отвечающим за выполнение смарт-контрактов. Для обеспечения того, чтобы смарт-контракты на разных узлах могли получать одинаковые результаты выполнения, EVM предоставляет унифицированную виртуальную среду, аналогичную виртуальной машине Java (JVM).
Умные контракты при развертывании на блокчейне сначала компилируются в байт-код EVM. EVM при выполнении контракта последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas при выполнении каждой инструкции, и количество потребляемого Gas зависит от сложности операции.
Традиционный EVM обрабатывает транзакции последовательно, все транзакции ставятся в очередь и выполняются по порядку. Этот дизайн прост в обслуживании, но с увеличением числа пользователей и повышением требований к TPS, производственные узкие места последовательного выполнения становятся все более явными, особенно в решениях второго уровня.
Кроме EVM, еще одним ключевым компонентом выполнения транзакций в Ethereum является stateDB, который используется для управления состоянием учетных записей и хранения данных. EVM обновляет данные в stateDB каждый раз, когда выполняет транзакцию, и эти изменения в конечном итоге отражаются в глобальном дереве состояния.
В режиме последовательного выполнения процесс взаимодействия EVM и stateDB при обработке транзакций выглядит следующим образом:
Транзакции внутри блока обрабатываются по порядку по одной.
Каждая транзакция использует независимый экземпляр EVM, но совместно использует одну и ту же stateDB
В процессе выполнения EVM постоянно взаимодействует с stateDB, считывая и записывая данные.
После завершения всех транзакций изменения в stateDB будут отправлены в глобальное состояние.
Основная проблема этого последовательного режима заключается в том, что сложные транзакции смарт-контрактов могут блокировать другие транзакции, не позволяя полностью использовать аппаратные ресурсы.
Чтобы решить эту проблему, некоторые проекты начали исследовать параллельные оптимизации EVM. В качестве примера возьмем один проект Layer 2, его основная идея заключается в том, чтобы для каждого потока выделить временную базу данных состояния (pending-stateDB):
Параллельное выполнение различных транзакций с использованием многопоточности
Каждый поток использует независимую pending-stateDB для записи изменений состояния
После завершения всех сделок изменения из pending-stateDB будут синхронизированы с глобальным stateDB.
Данное решение имеет специальную обработку для операций чтения и записи:
Операция чтения сначала проверяет pending-stateDB, если данных нет, то считывает глобальный stateDB
Операции записи временно хранятся в pending-stateDB и не изменяют глобальный stateDB напрямую.
Чтобы избежать конфликтов состояния, данное решение вводит механизм обнаружения конфликтов:
Мониторинг наличия перекрытия между наборами чтения и записи различных сделок.
Пометить связанные транзакции для повторного выполнения при обнаружении конфликта
В конце концов, несколько изменений в pending-stateDB объединяются в глобальный stateDB для генерации нового корня состояния.
Эта схема параллельной оптимизации может увеличить TPS в 3-5 раз при низкой конфликтной нагрузке. В условиях высокой конфликтности теоретически можно достичь увеличения в 60 раз.
В целом, параллелизация EVM является важным направлением для повышения производительности Ethereum и его Layer 2. С помощью технологий, таких как многопоточное параллельное выполнение и временные хранилища состояний, можно значительно увеличить пропускную способность обработки транзакций при обеспечении согласованности. В будущем можно будет улучшить производительность EVM за счет дальнейшей оптимизации эффективности хранения, улучшения стратегий обработки конфликтов и других мер.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
5
Поделиться
комментарий
0/400
FlatTax
· 07-24 20:11
60 раз? Быка не дует
Посмотреть ОригиналОтветить0
FastLeaver
· 07-22 02:02
Неплохо, можно увеличить TPS в 60 раз.
Посмотреть ОригиналОтветить0
NftDeepBreather
· 07-22 00:27
После этого BTC возвращается на трон
Посмотреть ОригиналОтветить0
CounterIndicator
· 07-22 00:11
бычий значит вершина, падение значит основание
Посмотреть ОригиналОтветить0
SerumDegen
· 07-22 00:10
просто еще один копиум, чтобы пампить eth, если честно... покажите мне реальные цифры tps сначала
Проблема параллелизации EVM: многопоточное выполнение повышает пропускную способность обработки транзакций
Путь параллелизации EVM: от последовательного к многопоточному исполнению
Как известно, EVM является核心执行引擎 Ethereum, отвечающим за выполнение смарт-контрактов. Для обеспечения того, чтобы смарт-контракты на разных узлах могли получать одинаковые результаты выполнения, EVM предоставляет унифицированную виртуальную среду, аналогичную виртуальной машине Java (JVM).
Умные контракты при развертывании на блокчейне сначала компилируются в байт-код EVM. EVM при выполнении контракта последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость Gas. EVM отслеживает потребление Gas при выполнении каждой инструкции, и количество потребляемого Gas зависит от сложности операции.
Традиционный EVM обрабатывает транзакции последовательно, все транзакции ставятся в очередь и выполняются по порядку. Этот дизайн прост в обслуживании, но с увеличением числа пользователей и повышением требований к TPS, производственные узкие места последовательного выполнения становятся все более явными, особенно в решениях второго уровня.
Кроме EVM, еще одним ключевым компонентом выполнения транзакций в Ethereum является stateDB, который используется для управления состоянием учетных записей и хранения данных. EVM обновляет данные в stateDB каждый раз, когда выполняет транзакцию, и эти изменения в конечном итоге отражаются в глобальном дереве состояния.
В режиме последовательного выполнения процесс взаимодействия EVM и stateDB при обработке транзакций выглядит следующим образом:
Основная проблема этого последовательного режима заключается в том, что сложные транзакции смарт-контрактов могут блокировать другие транзакции, не позволяя полностью использовать аппаратные ресурсы.
Чтобы решить эту проблему, некоторые проекты начали исследовать параллельные оптимизации EVM. В качестве примера возьмем один проект Layer 2, его основная идея заключается в том, чтобы для каждого потока выделить временную базу данных состояния (pending-stateDB):
Данное решение имеет специальную обработку для операций чтения и записи:
Чтобы избежать конфликтов состояния, данное решение вводит механизм обнаружения конфликтов:
В конце концов, несколько изменений в pending-stateDB объединяются в глобальный stateDB для генерации нового корня состояния.
Эта схема параллельной оптимизации может увеличить TPS в 3-5 раз при низкой конфликтной нагрузке. В условиях высокой конфликтности теоретически можно достичь увеличения в 60 раз.
В целом, параллелизация EVM является важным направлением для повышения производительности Ethereum и его Layer 2. С помощью технологий, таких как многопоточное параллельное выполнение и временные хранилища состояний, можно значительно увеличить пропускную способность обработки транзакций при обеспечении согласованности. В будущем можно будет улучшить производительность EVM за счет дальнейшей оптимизации эффективности хранения, улучшения стратегий обработки конфликтов и других мер.