Паралельна оптимізація EVM: ключ до підвищення продуктивності Блокчейн

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

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

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

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

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

Недоліки цього режиму послідовного виконання очевидні: транзакції повинні стояти в черзі на виконання, і якщо виникає складна транзакція, що займає багато часу, наступні транзакції змушені чекати, не можуть в повній мірі використовувати апаратні ресурси, що серйозно обмежує ефективність обробки.

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

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

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

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

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

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

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

• Запис не записується безпосередньо в глобальну stateDB, а спочатку фіксується в WriteSet стану в очікуванні. Після завершення виконання транзакції спочатку проводиться перевірка на конфлікти, а потім намагаються об'єднати в глобальну stateDB.

Щоб вирішити проблему конфлікту станів, цей проект впровадив механізм виявлення конфліктів:

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

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

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

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

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

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