Оптимізація паралелізації EVM: обговорення шляхів підвищення продуктивності на прикладі Reddio
Відомо, що EVM є одним з найважливіших компонентів Ethereum, виконуючи важливі ролі "виконавчого механізму" та "середовища виконання смарт-контрактів". У блокчейні, що складається з тисяч вузлів в відкритій мережі, апаратна конфігурація різних вузлів може значно відрізнятися. Щоб забезпечити однозначні результати виконання смарт-контрактів на всіх вузлах, технологія віртуальної машини стала ідеальним рішенням.
EVM може працювати з розумними контрактами однаково на різних операційних системах і пристроях, ця кросплатформна сумісність гарантує, що кожен вузол отримує однакові результати після виконання контракту. Це схоже на принцип роботи Java віртуальної машини (JVM).
Смарт-контракти, які ми бачимо в блокчейн-браузері, спочатку компілюються в байт-код EVM, а потім зберігаються в ланцюзі. Коли EVM виконує контракт, він послідовно читає цей байт-код, і кожна інструкція має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання кожної інструкції, і обсяг споживання залежить від складності операції.
Як основний виконавчий механізм Ethereum, EVM обробляє транзакції послідовно, всі транзакції знаходяться в єдиній черзі та виконуються в порядку їх підтвердження. Причина, чому не використовується паралельна обробка, полягає в тому, що блокчейн має суворо забезпечувати узгодженість, однакова група транзакцій повинна оброблятися в усіх вузлах в однаковому порядку. Якщо обробка транзакцій буде паралелізована, буде важко точно передбачити порядок транзакцій, якщо не ввести складні алгоритми планування.
У 2014-2015 роках команда засновників Ethereum, через брак часу, обрала простий у проектуванні та легкий у супроводженні послідовний спосіб виконання. Однак, з розвитком технології блокчейн та розширенням користувацької бази, вимоги до TPS та пропускної спроможності зростають. Після появи та зрілості технології Rollup, продуктивнісні обмеження, які виникають через послідовне виконання EVM, вже явно виявилися в другому рівні мережі Ethereum.
Секвенсор як ключовий компонент Layer2 виконує всі обчислювальні завдання у формі одного сервера. Якщо зовнішні модулі, що взаємодіють із секвенсором, мають достатньо високу ефективність, остаточне вузьке місце буде залежати від ефективності самого секвенсора, у цьому випадку послідовне виконання стане великою перешкодою.
Деяка команда через надзвичайну оптимізацію рівня DA та модуля читання/запису даних змогла досягти виконання до 2000+ трансакцій ERC-20 на секунду за допомогою Sequencer. Це число здається дуже високим, але якщо оброблювані трансакції набагато складніші за трансакції ERC-20, то значення TPS, безумовно, значно знизиться. Тому паралелізація обробки транзакцій стане невідворотним трендом у майбутньому.
Дві основні складові виконання транзакцій Ethereum
Окрім EVM, ще одним ключовим компонентом у go-ethereum, що стосується виконання транзакцій, є stateDB, який використовується для управління станом облікових записів і зберігання даних в Ethereum. Ethereum використовує структуру дерева, звану Merkle Patricia Trie, в якості індексу бази даних. Кожен раз, коли EVM виконує транзакцію, він змінює певні дані, що зберігаються в stateDB, ці зміни в кінцевому підсумку відображаються в глобальному дереві станів.
stateDB відповідає за підтримку стану всіх облікових записів Ethereum, включаючи EOA-акаунти та контракти, зберігаючи дані, що включають баланс облікового запису, код смарт-контракту тощо. Під час виконання транзакції stateDB здійснює читання та запис даних відповідних облікових записів. Після завершення виконання транзакції stateDB потрібно подати новий стан до бази даних нижнього рівня для тривалої обробки.
В цілому, EVM відповідає за інтерпретацію та виконання інструкцій смарт-контрактів, змінюючи стан на блокчейні відповідно до результатів обчислень, в той час як stateDB виконує роль глобального сховища стану, керуючи змінами стану всіх облікових записів і контрактів. Обидва елементи співпрацюють для створення середовища виконання транзакцій Ethereum.
Конкретний процес послідовного виконання
Торгові операції на Ethereum діляться на перекази EOA та контрактні угоди. Перекази EOA є найпростішим типом транзакцій, тобто переказами ETH між звичайними рахунками, не залучаючи викликів контрактів, обробка яких проходить дуже швидко, а плата за газ є низькою.
Торговля контрактами передбачає виклик та виконання смарт-контрактів. Kоли EVM обробляє контракти, йому потрібно поетапно інтерпретувати та виконувати байт-код інструкцій у смарт-контракті; чим складніша логіка контракту, тим більше інструкцій залучено, і тим більше ресурсів буде витрачено.
Наприклад, час обробки трансакцій ERC-20 приблизно в 2 рази більший, ніж у трансакцій EOA, а більш складні смарт-контракти, такі як торгові операції на певному DEX, можуть займати в десятки разів більше часу, ніж трансакції EOA. Це пов'язано з тим, що DeFi-протоколи під час торгівлі повинні обробляти складну логіку, таку як ліквідні пулі, розрахунок цін, обмін токенами тощо, що вимагає великої кількості обчислень.
У режимі послідовного виконання процес обробки транзакцій між компонентами EVM та stateDB виглядає наступним чином:
У дизайні Ethereum транзакції в одному блоці обробляються по черзі, кожна транзакція має окремий екземпляр для виконання конкретних операцій. Незважаючи на те, що кожна транзакція використовує різні екземпляри EVM, всі транзакції спільно використовують одну й ту ж базу даних стану stateDB.
Під час виконання транзакції EVM постійно взаємодіє з stateDB, читаючи відповідні дані з stateDB і записуючи змінені дані назад у stateDB.
Коли всі транзакції в блоці завершено, дані в stateDB будуть передані до глобального стану дерева і згенерують новий корінь стану. Корінь стану є важливим параметром кожного блоку, що фіксує "стислі результати" нового глобального стану після виконання блоку.
Явні обмеження серійної моделі виконання EVM: транзакції повинні виконуватись у черзі за порядком, і якщо виникає тривала транзакція зі смарт-контрактом, інші транзакції можуть лише чекати, поки вона не буде завершена. Це явно не дозволяє повністю використовувати апаратні ресурси, такі як процесори, і суттєво обмежує ефективність.
Оптимізаційне рішення для багатопоточності EVM
Послідовне виконання та паралельне виконання можна порівняти з банком, де є лише одна каса, та банком, де є кілька кас. У паралельному режимі можна відкривати кілька потоків для одночасної обробки кількох транзакцій, що може суттєво підвищити ефективність, але складним є питання конфлікту станів.
Якщо кілька транзакцій декларують зміну даних певного облікового запису, під час їх одночасної обробки виникають конфлікти. Наприклад, певний NFT може бути випущений лише один раз, а транзакція 1 і транзакція 2 обидві декларують намір випустити цей NFT. Якщо обидва запити будуть задоволені, очевидно, що виникне помилка. У реальних умовах конфлікти стану виникають набагато частіше, тому паралельна обробка транзакцій повинна мати заходи для вирішення конфліктів стану.
Принцип паралельної оптимізації Reddio для EVM
Деякий проект ZKRollup оптимізує EVM, розподіляючи одну транзакцію на кожен потік, і надає кожному потоку тимчасову базу даних стану, яка називається pending-stateDB. Конкретні деталі наведені нижче:
Паралельне виконання транзакцій за допомогою багатопоточності: налаштуйте кілька потоків для одночасної обробки різних транзакцій, при цьому потоки не заважають один одному. Це може в кілька разів підвищити швидкість обробки транзакцій.
Виділити тимчасову базу даних стану для кожного потоку: для кожного потоку виділити незалежну тимчасову базу даних стану (pending-stateDB). Кожен потік, виконуючи транзакції, не змінює безпосередньо глобальну stateDB, а тимчасово записує результати зміни стану в pending-stateDB.
Синхронізація змін стану: Після виконання всіх транзакцій у блоці EVM по черзі синхронізує результати змін стану, записані в кожній pending-stateDB, до глобальної stateDB. Якщо різні транзакції під час виконання не призвели до конфлікту станів, записи з pending-stateDB можуть бути успішно об'єднані в глобальну stateDB.
Проект оптимізував обробку операцій читання та запису, щоб забезпечити правильний доступ до стану даних під час транзакцій і уникнути конфліктів:
Операція читання: коли транзакція потребує читання стану, EVM спочатку перевіряє ReadSet очікувального стану. Якщо ReadSet містить необхідні дані, вони читаються безпосередньо з pending-stateDB. Якщо відповідні пари ключ-значення не знайдені в ReadSet, дані історичного стану читаються з глобальної stateDB відповідного попереднього блоку.
Запис операцій: всі запис операцій (, тобто зміни стану ), не будуть безпосередньо записуватись у глобальну stateDB, а спочатку записуються у WriteSet Pending-state. Після завершення виконання транзакції спочатку проводиться перевірка на конфлікти, а потім намагаються об'єднати результати зміни стану в глобальну stateDB.
Ключовим питанням паралельного виконання є конфлікт стану, коли кілька транзакцій намагаються читати та записувати стан одного й того ж рахунку, це питання стає особливо помітним. Для цього було введено механізм виявлення конфліктів:
Виявлення конфліктів: під час виконання транзакцій EVM буде моніторити ReadSet і WriteSet різних транзакцій. Якщо буде виявлено, що кілька транзакцій намагаються читати і записувати однакові елементи стану, це вважається конфліктом.
Обробка конфліктів: коли виявляється конфлікт, конфліктна транзакція позначається як така, що потребує повторного виконання.
Після завершення всіх угод записи змін з кількох pending-stateDB будуть об'єднані в глобальний stateDB. Якщо об'єднання пройде успішно, EVM надішле кінцевий стан в глобальне дерево станів і згенерує новий корінь стану.
Покращення продуктивності за рахунок оптимізації паралельного багатопоточного виконання є значним, особливо при обробці складних угод із смарт-контрактами. Дослідження показують, що в умовах низької конфліктності у робочих навантаженнях у торгових пулах з ( угодами, які мають менше суперечностей або займають ті ж ресурси, продуктивність TPS за результатами бенчмаркінгу зросла приблизно в 3-5 разів у порівнянні з традиційним послідовним виконанням. У випадках високої конфліктності в робочих навантаженнях, теоретично, застосувавши всі оптимізаційні заходи, можна досягти навіть 60-кратного підвищення.
![На прикладі Reddio, описується шлях оптимізації паралельного EVM])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
Підсумок
Оптимізаційна схема багатопоточності EVM цього проєкту, шляхом виділення тимчасових бібліотек стану для кожної транзакції та паралельного виконання транзакцій у різних потоках, суттєво підвищила здатність EVM обробляти транзакції. Завдяки оптимізації операцій читання та запису та впровадженню механізму виявлення конфліктів, EVM-мережа може досягати масової паралелізації транзакцій, гарантуючи узгодженість стану, вирішуючи проблеми продуктивності, пов'язані з традиційними послідовними моделями виконання. Це закладає важливу основу для майбутнього розвитку Ethereum Rollup.
![Приклад Reddio, описуючи шлях оптимізації паралельного EVM])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
20 лайків
Нагородити
20
5
Репост
Поділіться
Прокоментувати
0/400
SocialFiQueen
· 08-05 12:02
Це вже може змагатися з Гонконгом.
Переглянути оригіналвідповісти на0
SerumSquirter
· 08-05 00:36
швидко увійдіть на reddio, давайте працювати
Переглянути оригіналвідповісти на0
SocialAnxietyStaker
· 08-03 20:27
Багатопотоковий дивовижний!
Переглянути оригіналвідповісти на0
GamefiEscapeArtist
· 08-03 20:25
Працюючи так довго, v1 все ще не оптимізований.
Переглянути оригіналвідповісти на0
AllInDaddy
· 08-03 20:00
reddio хто розуміє, це так само, як і з刀哥, виходити на берег.
Оптимізація EVM з багатопоточністю: розблокування вузьких місць продуктивності Rollup
Оптимізація паралелізації EVM: обговорення шляхів підвищення продуктивності на прикладі Reddio
Відомо, що EVM є одним з найважливіших компонентів Ethereum, виконуючи важливі ролі "виконавчого механізму" та "середовища виконання смарт-контрактів". У блокчейні, що складається з тисяч вузлів в відкритій мережі, апаратна конфігурація різних вузлів може значно відрізнятися. Щоб забезпечити однозначні результати виконання смарт-контрактів на всіх вузлах, технологія віртуальної машини стала ідеальним рішенням.
EVM може працювати з розумними контрактами однаково на різних операційних системах і пристроях, ця кросплатформна сумісність гарантує, що кожен вузол отримує однакові результати після виконання контракту. Це схоже на принцип роботи Java віртуальної машини (JVM).
Смарт-контракти, які ми бачимо в блокчейн-браузері, спочатку компілюються в байт-код EVM, а потім зберігаються в ланцюзі. Коли EVM виконує контракт, він послідовно читає цей байт-код, і кожна інструкція має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання кожної інструкції, і обсяг споживання залежить від складності операції.
Як основний виконавчий механізм Ethereum, EVM обробляє транзакції послідовно, всі транзакції знаходяться в єдиній черзі та виконуються в порядку їх підтвердження. Причина, чому не використовується паралельна обробка, полягає в тому, що блокчейн має суворо забезпечувати узгодженість, однакова група транзакцій повинна оброблятися в усіх вузлах в однаковому порядку. Якщо обробка транзакцій буде паралелізована, буде важко точно передбачити порядок транзакцій, якщо не ввести складні алгоритми планування.
У 2014-2015 роках команда засновників Ethereum, через брак часу, обрала простий у проектуванні та легкий у супроводженні послідовний спосіб виконання. Однак, з розвитком технології блокчейн та розширенням користувацької бази, вимоги до TPS та пропускної спроможності зростають. Після появи та зрілості технології Rollup, продуктивнісні обмеження, які виникають через послідовне виконання EVM, вже явно виявилися в другому рівні мережі Ethereum.
Секвенсор як ключовий компонент Layer2 виконує всі обчислювальні завдання у формі одного сервера. Якщо зовнішні модулі, що взаємодіють із секвенсором, мають достатньо високу ефективність, остаточне вузьке місце буде залежати від ефективності самого секвенсора, у цьому випадку послідовне виконання стане великою перешкодою.
Деяка команда через надзвичайну оптимізацію рівня DA та модуля читання/запису даних змогла досягти виконання до 2000+ трансакцій ERC-20 на секунду за допомогою Sequencer. Це число здається дуже високим, але якщо оброблювані трансакції набагато складніші за трансакції ERC-20, то значення TPS, безумовно, значно знизиться. Тому паралелізація обробки транзакцій стане невідворотним трендом у майбутньому.
Дві основні складові виконання транзакцій Ethereum
Окрім EVM, ще одним ключовим компонентом у go-ethereum, що стосується виконання транзакцій, є stateDB, який використовується для управління станом облікових записів і зберігання даних в Ethereum. Ethereum використовує структуру дерева, звану Merkle Patricia Trie, в якості індексу бази даних. Кожен раз, коли EVM виконує транзакцію, він змінює певні дані, що зберігаються в stateDB, ці зміни в кінцевому підсумку відображаються в глобальному дереві станів.
stateDB відповідає за підтримку стану всіх облікових записів Ethereum, включаючи EOA-акаунти та контракти, зберігаючи дані, що включають баланс облікового запису, код смарт-контракту тощо. Під час виконання транзакції stateDB здійснює читання та запис даних відповідних облікових записів. Після завершення виконання транзакції stateDB потрібно подати новий стан до бази даних нижнього рівня для тривалої обробки.
В цілому, EVM відповідає за інтерпретацію та виконання інструкцій смарт-контрактів, змінюючи стан на блокчейні відповідно до результатів обчислень, в той час як stateDB виконує роль глобального сховища стану, керуючи змінами стану всіх облікових записів і контрактів. Обидва елементи співпрацюють для створення середовища виконання транзакцій Ethereum.
Конкретний процес послідовного виконання
Торгові операції на Ethereum діляться на перекази EOA та контрактні угоди. Перекази EOA є найпростішим типом транзакцій, тобто переказами ETH між звичайними рахунками, не залучаючи викликів контрактів, обробка яких проходить дуже швидко, а плата за газ є низькою.
Торговля контрактами передбачає виклик та виконання смарт-контрактів. Kоли EVM обробляє контракти, йому потрібно поетапно інтерпретувати та виконувати байт-код інструкцій у смарт-контракті; чим складніша логіка контракту, тим більше інструкцій залучено, і тим більше ресурсів буде витрачено.
Наприклад, час обробки трансакцій ERC-20 приблизно в 2 рази більший, ніж у трансакцій EOA, а більш складні смарт-контракти, такі як торгові операції на певному DEX, можуть займати в десятки разів більше часу, ніж трансакції EOA. Це пов'язано з тим, що DeFi-протоколи під час торгівлі повинні обробляти складну логіку, таку як ліквідні пулі, розрахунок цін, обмін токенами тощо, що вимагає великої кількості обчислень.
У режимі послідовного виконання процес обробки транзакцій між компонентами EVM та stateDB виглядає наступним чином:
У дизайні Ethereum транзакції в одному блоці обробляються по черзі, кожна транзакція має окремий екземпляр для виконання конкретних операцій. Незважаючи на те, що кожна транзакція використовує різні екземпляри EVM, всі транзакції спільно використовують одну й ту ж базу даних стану stateDB.
Під час виконання транзакції EVM постійно взаємодіє з stateDB, читаючи відповідні дані з stateDB і записуючи змінені дані назад у stateDB.
Коли всі транзакції в блоці завершено, дані в stateDB будуть передані до глобального стану дерева і згенерують новий корінь стану. Корінь стану є важливим параметром кожного блоку, що фіксує "стислі результати" нового глобального стану після виконання блоку.
Явні обмеження серійної моделі виконання EVM: транзакції повинні виконуватись у черзі за порядком, і якщо виникає тривала транзакція зі смарт-контрактом, інші транзакції можуть лише чекати, поки вона не буде завершена. Це явно не дозволяє повністю використовувати апаратні ресурси, такі як процесори, і суттєво обмежує ефективність.
Оптимізаційне рішення для багатопоточності EVM
Послідовне виконання та паралельне виконання можна порівняти з банком, де є лише одна каса, та банком, де є кілька кас. У паралельному режимі можна відкривати кілька потоків для одночасної обробки кількох транзакцій, що може суттєво підвищити ефективність, але складним є питання конфлікту станів.
Якщо кілька транзакцій декларують зміну даних певного облікового запису, під час їх одночасної обробки виникають конфлікти. Наприклад, певний NFT може бути випущений лише один раз, а транзакція 1 і транзакція 2 обидві декларують намір випустити цей NFT. Якщо обидва запити будуть задоволені, очевидно, що виникне помилка. У реальних умовах конфлікти стану виникають набагато частіше, тому паралельна обробка транзакцій повинна мати заходи для вирішення конфліктів стану.
Принцип паралельної оптимізації Reddio для EVM
Деякий проект ZKRollup оптимізує EVM, розподіляючи одну транзакцію на кожен потік, і надає кожному потоку тимчасову базу даних стану, яка називається pending-stateDB. Конкретні деталі наведені нижче:
Паралельне виконання транзакцій за допомогою багатопоточності: налаштуйте кілька потоків для одночасної обробки різних транзакцій, при цьому потоки не заважають один одному. Це може в кілька разів підвищити швидкість обробки транзакцій.
Виділити тимчасову базу даних стану для кожного потоку: для кожного потоку виділити незалежну тимчасову базу даних стану (pending-stateDB). Кожен потік, виконуючи транзакції, не змінює безпосередньо глобальну stateDB, а тимчасово записує результати зміни стану в pending-stateDB.
Синхронізація змін стану: Після виконання всіх транзакцій у блоці EVM по черзі синхронізує результати змін стану, записані в кожній pending-stateDB, до глобальної stateDB. Якщо різні транзакції під час виконання не призвели до конфлікту станів, записи з pending-stateDB можуть бути успішно об'єднані в глобальну stateDB.
Проект оптимізував обробку операцій читання та запису, щоб забезпечити правильний доступ до стану даних під час транзакцій і уникнути конфліктів:
Операція читання: коли транзакція потребує читання стану, EVM спочатку перевіряє ReadSet очікувального стану. Якщо ReadSet містить необхідні дані, вони читаються безпосередньо з pending-stateDB. Якщо відповідні пари ключ-значення не знайдені в ReadSet, дані історичного стану читаються з глобальної stateDB відповідного попереднього блоку.
Запис операцій: всі запис операцій (, тобто зміни стану ), не будуть безпосередньо записуватись у глобальну stateDB, а спочатку записуються у WriteSet Pending-state. Після завершення виконання транзакції спочатку проводиться перевірка на конфлікти, а потім намагаються об'єднати результати зміни стану в глобальну stateDB.
Ключовим питанням паралельного виконання є конфлікт стану, коли кілька транзакцій намагаються читати та записувати стан одного й того ж рахунку, це питання стає особливо помітним. Для цього було введено механізм виявлення конфліктів:
Виявлення конфліктів: під час виконання транзакцій EVM буде моніторити ReadSet і WriteSet різних транзакцій. Якщо буде виявлено, що кілька транзакцій намагаються читати і записувати однакові елементи стану, це вважається конфліктом.
Обробка конфліктів: коли виявляється конфлікт, конфліктна транзакція позначається як така, що потребує повторного виконання.
Після завершення всіх угод записи змін з кількох pending-stateDB будуть об'єднані в глобальний stateDB. Якщо об'єднання пройде успішно, EVM надішле кінцевий стан в глобальне дерево станів і згенерує новий корінь стану.
Покращення продуктивності за рахунок оптимізації паралельного багатопоточного виконання є значним, особливо при обробці складних угод із смарт-контрактами. Дослідження показують, що в умовах низької конфліктності у робочих навантаженнях у торгових пулах з ( угодами, які мають менше суперечностей або займають ті ж ресурси, продуктивність TPS за результатами бенчмаркінгу зросла приблизно в 3-5 разів у порівнянні з традиційним послідовним виконанням. У випадках високої конфліктності в робочих навантаженнях, теоретично, застосувавши всі оптимізаційні заходи, можна досягти навіть 60-кратного підвищення.
![На прикладі Reddio, описується шлях оптимізації паралельного EVM])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
Підсумок
Оптимізаційна схема багатопоточності EVM цього проєкту, шляхом виділення тимчасових бібліотек стану для кожної транзакції та паралельного виконання транзакцій у різних потоках, суттєво підвищила здатність EVM обробляти транзакції. Завдяки оптимізації операцій читання та запису та впровадженню механізму виявлення конфліктів, EVM-мережа може досягати масової паралелізації транзакцій, гарантуючи узгодженість стану, вирішуючи проблеми продуктивності, пов'язані з традиційними послідовними моделями виконання. Це закладає важливу основу для майбутнього розвитку Ethereum Rollup.
![Приклад Reddio, описуючи шлях оптимізації паралельного EVM])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(