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

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

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

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

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

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

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

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

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

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

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

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