Оптимізація паралелізації EVM: ключ до подолання вузьких місць у продуктивності

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

EVM може працювати з розумними контрактами однаковим чином на різних операційних системах і пристроях, ця кросплатформна сумісність забезпечує отримання однакових результатів після виконання контрактів кожним вузлом. Це подібно до принципу роботи Java Virtual Machine (JVM).

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

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

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

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

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

Далі ми глибше розглянемо обмеження традиційного EVM та переваги паралельного EVM.

Два основні компоненти виконання транзакцій в Ethereum

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

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

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

конкретний процес послідовного виконання

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

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

Наприклад, час обробки переказів ERC-20 приблизно в 2 рази більший, ніж у переказів EOA, а більш складні смарт-контракти (, такі як операції торгівлі на деяких DEX, ) займають ще більше часу, можливо, в десятки разів повільніше, ніж перекази EOA. Це пов'язано з тим, що DeFi протоколи під час транзакцій повинні обробляти ліквідні пулі, розрахунок цін, обмін токенів та іншу складну логіку, що вимагає значних обчислень.

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

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

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

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

1. processBlock() функція викликає Process() для обробки транзакцій у блоці.

2. Процес() функція визначає цикл for, в якому угоди виконуються поетапно.

3. Після завершення всіх транзакцій, функція processBlock() викликає функцію writeBlockWithState(), а потім викликає функцію statedb.Commit() для подання результатів зміни стану.

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

Явно виявляється вузьке місце в послідовному режимі виконання EVM: транзакції повинні виконуватись у черзі, і якщо виникає тривала транзакція смарт-контракту, інші транзакції можуть лише чекати, що не дозволяє повністю використовувати апаратні ресурси, такі як ЦП, і значно обмежує ефективність.

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

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

Якщо кілька транзакцій оголосили про необхідність змінити дані певного рахунку, одночасна обробка призведе до конфлікту. Наприклад, певний NFT можна випустити лише один раз, а транзакції 1 і 2 обидві прагнуть випустити цей NFT. Якщо обидва запити будуть задоволені, очевидно, що це призведе до помилки. У реальному використанні конфлікти стану трапляються ще частіше, тому паралельна обробка транзакцій повинна мати заходи для вирішення конфліктів стану.

Принцип паралельної оптимізації EVM для певного проекту

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

1. Паралельне виконання операцій з використанням кількох потоків: налаштування кількох потоків для одночасної обробки різних операцій, при цьому потоки не заважають один одному, що може в кілька разів підвищити швидкість обробки операцій.

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

3. Синхронізація змін стану: після виконання всіх транзакцій у блоці EVM по черзі синхронізує результати змін стану, зафіксовані в кожній pending-stateDB, до глобальної stateDB. Якщо під час виконання різних транзакцій немає конфліктів стану, записи з pending-stateDB можуть бути успішно об'єднані в глобальну stateDB.

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

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

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

Ключовим питанням паралельного виконання є конфлікт стану, який особливо яскраво проявляється, коли кілька транзакцій намагаються читати та записувати один і той же стан облікового запису. Для цього була введена механізм виявлення конфліктів:

Виявлення конфліктів: під час виконання транзакцій EVM контролює ReadSet і WriteSet різних транзакцій. Якщо виявляється, що кілька транзакцій намагаються читати та записувати одні й ті ж елементи стану, це вважається конфліктом.

Обробка конфліктів: при виявленні конфлікту, конфліктна транзакція позначається як така, що потребує повторного виконання.

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

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

Підсумок

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

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