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

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

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

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

У архітектурі Rollup Sequencer, як ключовий компонент Layer2, виконує всі обчислювальні завдання. Якщо інші зовнішні модулі мають достатньо високу ефективність, серійне виконання Sequencer стане найбільшим вузьким місцем. Деякі команди досягли екстремальної оптимізації, що дозволяє Sequencer виконувати до 2000 і більше трансакцій ERC-20 за секунду, але для складніших угод TPS все ще суттєво знижується. Тому паралелізація обробки угод стає тенденцією майбутнього.

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

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

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

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

Після виконання всіх транзакцій у блоці, дані в stateDB будуть підтверджені в глобальному дереві станів, що створить новий корінь стану. Основна проблема цього послідовного режиму полягає в тому, що транзакції повинні виконуватися в черзі, що не дозволяє повністю використовувати апаратні ресурси, особливо коли мова йде про складні транзакції зі смарт-контрактами, що призводить до низької ефективності.

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

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

1. Паралельне виконання транзакцій у багатопоточному режимі, без взаємного впливу.

2. Кожен потік має незалежну pending-stateDB, зміни стану під час виконання транзакції спочатку фіксуються тут.

3. Після завершення всіх транзакцій зміни з pending-stateDB синхронізуються з глобальним stateDB.

Ця схема оптимізувала операції читання та запису:

• Під час операції читання спочатку перевірте ReadSet у pending-stateDB; якщо необхідні дані вже є, читайте їх безпосередньо, інакше отримуйте історичний стан з глобального stateDB.

• Операції запису не записуються безпосередньо в глобальний stateDB, а спочатку фіксуються в WriteSet pending-stateDB.

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

• Моніторинг ReadSet та WriteSet різних транзакцій, виявлення конфлікту, коли кілька транзакцій читають і записують однакові елементи стану.

• Конфліктні транзакції будуть помічені як такі, що потребують повторного виконання.

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

Дослідження показують, що в умовах низької конфліктності навантаження, TPS паралельного EVM в порівнянні з традиційним послідовним виконанням підвищилось у 3-5 разів. В умовах високої конфліктності навантаження теоретично може досягати підвищення до 60 разів.

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