Исследование оптимизации параллельного EVM: ключевой путь к повышению эффективности обработки транзакций

EVM как основной исполнительный движок Ethereum, его производительность напрямую влияет на пропускную способность всей сети. С увеличением числа пользователей и разнообразием сценариев применения ограничения традиционной последовательной модели исполнения становятся все более очевидными. Особенно в решениях Layer 2, узкие места производительности EVM становятся более заметными. Поэтому исследование параллельных схем исполнения становится важным направлением для повышения эффективности EVM.

Основные компоненты EVM и последовательный процесс выполнения

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

Конкретный процесс выполнения следующий:

1. Вызов функции processBlock() для обработки транзакций внутри блока с помощью функции Process()
2. Функция Process() выполняет сделки поэтапно с помощью цикла for.
3. После завершения всех транзакций вызвать statedb.Commit() для отправки изменений состояния

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

Оптимизация параллельного EVM

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

Некоторая команда в отрасли предложила оптимизационное решение для параллельного EVM, основными характеристиками которого являются:

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

Данное решение оптимизировало операции чтения и записи:

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

Чтобы решить проблему конфликтов состояний, в方案 был введен механизм обнаружения конфликтов:

• Мониторинг ReadSet и WriteSet различных сделок
• Пометить связанные транзакции для повторного выполнения при обнаружении конфликта
• После завершения всех сделок объедините pending-stateDB с глобальным stateDB

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

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

• При низком конфликтном рабочем нагрузке, TPS увеличивается в 3-5 раз
• При высоких конфликтных рабочих нагрузках теоретически возможно увеличение до 60 раз

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