Путь параллельной оптимизации EVM

Известно, что EVM является основным исполнительным движком Ethereum и средой выполнения смарт-контрактов. В качестве открытой сети, состоящей из множества узлов, публичные блокчейны сталкиваются с проблемой достижения согласованного выполнения на устройствах с огромными различиями в аппаратных параметрах. Технология виртуальных машин предлагает возможность решения этой проблемы, позволяя смарт-контрактам выполняться одинаково на разных операционных системах и устройствах, обеспечивая согласованность результатов.

Умные контракты перед добавлением в блокчейн компилируются в байт-код EVM. При выполнении контракта EVM последовательно считывает этот байт-код, каждая инструкция имеет соответствующую стоимость Gas. EVM отслеживает расход Gas в процессе выполнения каждой инструкции, и объем потребления зависит от сложности операций.

Традиционно EVM обрабатывает транзакции последовательным образом, все транзакции ставятся в очередь в едином порядке и выполняются в определенной последовательности. Этот дизайн прост и удобен в обслуживании, но с развитием технологий блокчейн и расширением пользовательской базы требования к TPS и пропускной способности постоянно повышаются. С成熟ностью технологии Rollup производственные узкие места последовательного выполнения EVM становятся особенно очевидными в сети второго уровня Ethereum.

Секвенсер, как ключевой компонент Layer2, выполняет все вычислительные задачи в виде одного сервера. Если сопутствующие модули достаточно эффективны, то окончательное узкое место будет зависеть от эффективности самого секвенсера, и в этом случае последовательное выполнение станет серьезным препятствием. Поэтому параллелизация обработки транзакций становится неизбежной тенденцией в будущем.

Основной компонент выполнения транзакций Ethereum

Помимо EVM, еще одним ключевым компонентом, связанным с выполнением транзакций в go-ethereum, является stateDB, который управляет состоянием аккаунтов и хранением данных в Ethereum. Ethereum использует структуру данных Merkle Patricia Trie в качестве индекса базы данных. Каждое выполнение транзакции изменяет некоторые данные в stateDB, и эти изменения в конечном итоге отражаются в глобальном состоянии дерева.

stateDB отвечает за поддержание состояния всех аккаунтов Ethereum, включая EOA-аккаунты и контрактные аккаунты, храня балансы аккаунтов, коды смарт-контрактов и другие данные. В процессе выполнения транзакции stateDB осуществляет чтение и запись соответствующих данных аккаунтов. По завершении выполнения транзакции stateDB отправляет новое состояние в нижележащую базу данных для постоянного хранения.

В целом, EVM отвечает за интерпретацию и выполнение инструкций смарт-контрактов, изменяя состояние блокчейна в зависимости от результатов вычислений, в то время как stateDB служит глобальным хранилищем состояния, управляя изменениями состояния всех учетных записей и контрактов. Оба элемента сотрудничают для создания среды выполнения транзакций Ethereum.

Конкретный процесс последовательного выполнения

Транзакции в Ethereum делятся на два типа: переводы EOA и контрактные транзакции. Переводы EOA - это самый простой тип транзакции, то есть переводы ETH между обычными счетами, не вовлекающие вызовы контрактов, с высокой скоростью обработки и низкими затратами на газ.

Контрактная торговля включает в себя вызов и выполнение смарт-контрактов. Когда EVM обрабатывает контрактные сделки, необходимо интерпретировать и выполнять инструкции байт-кода в смарт-контракте по одной. Чем более сложна логика контракта, тем больше инструкций она включает, тем больше ресурсов она потребляет.

Например, время обработки транзакций ERC-20 примерно в два раза больше, чем у EOA-транзакций, а более сложные смарт-контракты, такие как операции обмена на Uniswap, могут занимать в десятки раз больше времени, чем EOA-транзакции. Это связано с тем, что DeFi-протоколы при совершении транзакций требуют обработки ликвидных пулов, вычисления цен, обмена токенов и другой сложной логики, что требует больших вычислительных ресурсов.

В режиме последовательного выполнения процесс взаимодействия EVM с stateDB выглядит следующим образом:

1. Транзакции внутри блока обрабатываются по порядку, одна за другой, каждая транзакция имеет независимый экземпляр для выполнения конкретных операций.
2. Все транзакции используют одну и ту же базу данных состояния stateDB.
3. В процессе выполнения транзакции EVM постоянно взаимодействует с stateDB, считывая соответствующие данные и записывая измененные данные обратно в stateDB.
4. После выполнения всех транзакций в блоке данные в stateDB отправляются в глобальное состояние дерева, создавая новый корень состояния.

Явно выраженная узкая горловина этого режима последовательного выполнения: сделки должны выполняться в порядке очереди, и если встречается длительная транзакция смарт-контракта, другие транзакции могут только ждать, не имея возможности в полной мере использовать аппаратные ресурсы, что значительно ограничивает эффективность.

Оптимизация многопоточности EVM

Параллельный режим выполнения позволяет запускать несколько потоков для одновременной обработки множества транзакций, что может увеличить эффективность в несколько раз, но сталкивается с проблемой конфликтов состояния. Когда несколько транзакций одновременно пытаются изменить данные определенного аккаунта, возникают конфликты, которые требуют согласования.

Принципы параллельной оптимизации

В качестве примера параллельной оптимизации проекта ZKRollup Reddio его основные характеристики включают в себя:

1. Параллельное выполнение сделок с использованием многопоточности: настройте несколько потоков для одновременной обработки различных сделок, при этом потоки не мешают друг другу, что может многократно увеличить скорость обработки сделок.

2. Назначить временную базу данных состояния для каждого потока: каждый поток имеет независимую временную базу данных состояния (pending-stateDB). Во время выполнения транзакции результаты изменения состояния временно записываются в pending-stateDB и не изменяют глобальную stateDB напрямую.

3. Синхронизация изменений состояния: После завершения выполнения всех транзакций в блоке, результаты изменений состояния, записанные в каждом pending-stateDB, последовательно синхронизируются с глобальным stateDB.

Reddio оптимизировал обработку операций чтения и записи:

• Операция чтения: сначала проверьте ReadSet в состоянии ожидания. Если необходимые данные существуют, читайте их напрямую из pending-stateDB; в противном случае читайте исторические данные состояния из глобального stateDB, соответствующего предыдущему блоку.

• Операции записи: все операции записи сначала записываются в WriteSet состояния ожидания, после завершения выполнения транзакции, через проверку конфликтов, снова пытаются объединить результаты изменения состояния в глобальную stateDB.

Для решения проблемы конфликтов статусов Reddio ввел механизм обнаружения конфликтов:

• Обнаружение конфликтов: мониторинг ReadSet и WriteSet различных транзакций; если обнаружено, что несколько транзакций пытаются читать и записывать один и тот же элемент состояния, это считается конфликтом.

• Обработка конфликтов: Конфликтные сделки помечаются как нуждающиеся в повторном выполнении.

После завершения всех операций по сделкам, записи об изменениях в нескольких pending-stateDB объединяются в глобальную stateDB. После успешного объединения окончательное состояние отправляется в глобальное дерево состояний, создавая новый корень состояния.

Многопоточная параллельная оптимизация значительно повысила производительность, особенно при обработке сложных транзакций смарт-контрактов. Исследования показывают, что в условиях низкой конфликтности производительность TPS в бенчмарках увеличилась в 3-5 раз по сравнению с традиционным последовательным выполнением. В условиях высокой конфликтности теоретически, если использовать все методы оптимизации, можно достичь увеличения в 60 раз.

Резюме

Оптимизированное решение Reddio по многопоточному параллельному выполнению EVM значительно увеличивает способность обработки транзакций EVM, выделяя временные библиотеки состояния для каждой транзакции и выполняя транзакции параллельно в разных потоках. Оптимизируя операции чтения и записи и вводя механизмы обнаружения конфликтов, публичная цепочка EVM может достигать массовой параллелизации транзакций при гарантии согласованности состояния, решая проблемы производительности традиционной последовательной модели выполнения. Это закладывает важную основу для будущего развития Rollup Ethereum.

В дальнейшем можно будет подробнее обсудить детали реализации Reddio, включая способы дальнейшей оптимизации эффективности хранения, варианты оптимизации в условиях высоких конфликтов, а также использование GPU для оптимизации и другие аспекты.