Оптимизация параллелизма EVM: ключ к преодолению瓶颈 производительности

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

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

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

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

Команда основателей Ethereum в 2014-2015 годах из-за нехватки времени выбрала простой и легкий в обслуживании последовательный способ выполнения. Однако с развитием технологий блокчейна и увеличением числа пользователей требования к TPS и пропускной способности становятся все более высокими. После того как технология Rollup достигла зрелости, узкие места производительности, вызванные последовательным выполнением EVM, уже явно проявились в сетях второго уровня Ethereum.

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

Некоторые команды путем экстремальной оптимизации уровня DA и модуля чтения-записи данных добились того, что Sequencer может выполнять до 2000 и более транзакций ERC-20 в секунду. Эта цифра кажется высокой, но если обрабатываемые транзакции намного сложнее, чем переводы ERC-20, значение TPS обязательно значительно снизится. Таким образом, параллелизация обработки транзакций станет неотъемлемой тенденцией будущего.

В следующем мы подробно рассмотрим ограничения традиционного EVM и преимущества параллельного EVM.

Две ключевые компоненты выполнения транзакций Ethereum

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

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

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

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

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

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

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

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

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

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

С точки зрения кода, общий процесс выполнения транзакций с сотрудничеством EVM и stateDB выглядит следующим образом:

1. функция processBlock() вызывает функцию Process() для обработки транзакций в блоке.

2. В функции Process() определён цикл for, сделки выполняются поочерёдно.

3. После завершения всех транзакций функция processBlock() вызывает функцию writeBlockWithState(), затем вызывает функцию statedb.Commit() для подтверждения результата изменения состояния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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