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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимізація багатопоточної паралельної роботи EVM

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

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

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

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

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

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

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

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

• Операція читання: коли транзакція потребує читання стану, EVM спочатку перевіряє ReadSet у Pending-state. Якщо потрібні дані є в 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 для оптимізації тощо.