Оптимізація EVM: підвищення продуктивності обробки транзакцій

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

Смарт-контракти, коли вони розгортаються в ланцюзі, спочатку компілюються в байт-код EVM. Коли EVM виконує контракт, вона послідовно читає цей байт-код, кожна інструкція має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання інструкцій, а обсяг споживання залежить від складності операцій.

Традиційний EVM обробляє транзакції послідовно, всі транзакції виконуються в єдиній черзі. Цей дизайн простий у підтримці, але з ростом кількості користувачів, зростають вимоги до TPS і пропускної здатності, і обмеження продуктивності послідовного виконання стають все більш очевидними, особливо на Layer 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 разів.

Ця паралельна оптимізація реалізує масштабну паралелізацію транзакцій за рахунок тимчасової бібліотеки станів та виявлення конфліктів, забезпечуючи при цьому узгодженість станів, що закладає важливу основу для розвитку Ethereum Rollup. У майбутньому можна ще більше покращити продуктивність за рахунок оптимізації зберігання, обробки високих конфліктних сценаріїв, прискорення за допомогою GPU та інших аспектів.