Шлях паралельної оптимізації EVM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принципи паралельної оптимізації

Як приклад паралельної оптимізації проекту ZKRollup Reddio, його основні характеристики включають:

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

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

3. Синхронізація змін стану: після виконання всіх транзакцій у блоці, результати змін стану, зафіксовані в кожному pending-stateDB, послідовно синхронізуються в глобальний stateDB.

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

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

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

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

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

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

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

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

Резюме

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

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