Шлях паралелізації EVM: від серійного до багатопотокового виконання

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

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

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

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

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

1. Транзакції в блокові обробляються по черзі.
2. Кожна транзакція використовує незалежний EVM екземпляр, але спільно використовує одну й ту ж stateDB
3. Під час виконання EVM безперервно взаємодіє з stateDB, читаючи та записуючи дані.
4. Після завершення всіх угод зміни в stateDB будуть надіслані до глобального стану дерева.

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

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

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

Цей план містить спеціальну обробку для операцій читання та запису:

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

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

• Моніторинг наявності перетворення між наборами читання та запису різних транзакцій
• Позначте відповідні транзакції, які потрібно виконати повторно, коли виявлено конфлікт.

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

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

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