Відомо, що EVM є одним із найважливіших основних компонентів Ethereum, виконуючи ключову роль як "виконавчий механізм" і "середовище виконання смарт-контрактів". У мережі публічних ланцюгів, що складається з тисяч вузлів, наявність віртуальної машини дозволяє смарт-контрактам виконуватися однаково на вузлах з різними апаратними конфігураціями, що забезпечує узгодженість результатів. Ця кросплатформна сумісність подібна до Java Virtual Machine (JVM).
Смарт-контракти перед додаванням в блокчейн компілюються в байт-код EVM. Під час виконання контракту EVM послідовно читає цей байт-код, кожна команда має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання команд, а обсяг витрат залежить від складності операцій.
Як основний виконавчий механізм Ethereum, EVM використовує послідовний спосіб виконання для обробки транзакцій. Усі транзакції чергуються в єдиній черзі та виконуються в порядку їх підтвердження. Цей дизайн простий у підтримці, але з розширенням користувацької бази та ітерацією технологій його продуктивнісні обмеження стають все більш очевидними, особливо після того, як технологія Rollup стала зрілою, що особливо помітно в мережі другого рівня Ethereum.
Секвенсер як ключовий компонент Layer2 виконує всі обчислювальні завдання в єдиному серверному форматі. Якщо супутні зовнішні модулі мають достатньо високу ефективність, остаточне вузьке місце залежатиме від ефективності самого Секвенсера, і в цей момент послідовне виконання стане величезною перешкодою.
Одна команда шляхом максимальної оптимізації рівня DA та модуля читання/запису даних змогла забезпечити виконання Sequencer приблизно 2000 і більше трансакцій 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 між звичайними рахунками, який не передбачає викликів контрактів, обробка відбувається дуже швидко, а плата за газ дуже низька.
Торговля контрактами передбачає виклик та виконання смарт-контрактів. EVM при обробці контрактних угод потребує покрокового тлумачення та виконання байт-коду інструкцій смарт-контракту. Чим складніша логіка контракту, тим більше інструкцій залучено, і тим більше ресурсів витрачається.
Наприклад, час обробки переказу ERC-20 приблизно вдвічі більший, ніж час обробки переказу EOA, а більш складні смарт-контракти, такі як операції торгівлі на певному DEX, можуть займати в десятки разів більше часу, ніж перекази EOA. Це пов'язано з тим, що DeFi-протоколи під час торгівлі потребують обробки ліквіднісних пулів, розрахунку цін, обміну токенів та інших складних логік, що вимагає виконання дуже складних обчислень.
У режимі послідовного виконання процес співпраці EVM та stateDB виглядає наступним чином:
Транзакції в блоці обробляються по черзі, кожна транзакція має окремий екземпляр для виконання конкретної операції.
Хоча кожна транзакція використовує різні екземпляри EVM, всі транзакції використовують одну й ту ж базу даних стану stateDB.
Під час виконання транзакції EVM постійно взаємодіє з stateDB, читаючи відповідні дані та записуючи змінені дані назад у stateDB.
Після завершення всіх операцій дані з stateDB будуть надіслані до глобального стану дерева та згенерують новий корінь стану.
Явно видно, що у моделі послідовного виконання EVM є вузькі місця: транзакції повинні виконуватися у порядку черги, і якщо трапляється смарт-контрактна транзакція, яка триває дуже довго, інші транзакції можуть лише чекати, що не дозволяє повністю використовувати апаратні ресурси, що суттєво обмежує ефективність.
Оптимізація багатопотокового паралелізму EVM
Паралельний EVM нагадує банк з кількома касами, де можна відкрити кілька потоків для одночасної обробки кількох транзакцій, що дозволяє підвищити ефективність у кілька разів. Але складність полягає в проблемі конфлікту станів, яка потребує координації.
Думка про паралельну оптимізацію EVM у певному проекті ZKRollup така:
Паралельне виконання угод за допомогою кількох потоків: налаштування декількох потоків для одночасної обробки різних угод, при цьому потоки не заважають один одному, що може збільшити швидкість обробки угод у декілька разів.
Виділити тимчасову базу даних стану для кожного потоку: кожному потоку виділяється незалежна тимчасова база даних стану (pending-stateDB). Коли потоки виконують транзакції, вони не змінюють глобальну stateDB безпосередньо, а тимчасово фіксують результати змін стану в pending-stateDB.
Синхронізація змін стану: після завершення виконання всіх транзакцій у блоці EVM послідовно синхронізує результати змін стану, зафіксовані в кожній pending-stateDB, до глобальної stateDB. Якщо під час виконання різних транзакцій не виникало конфліктів стану, записи з pending-stateDB можуть бути успішно об'єднані в глобальну stateDB.
Цей проект оптимізував обробку операцій читання та запису, щоб забезпечити правильний доступ транзакцій до стану даних і уникнути конфліктів:
Операція читання: коли транзакція потребує читання стану, EVM спочатку перевіряє ReadSet у Pending-state. Якщо необхідні дані присутні, їх безпосередньо читають з pending-stateDB. Якщо в ReadSet не знайдено відповідної пари ключ-значення, тоді читають історичні дані стану з глобального stateDB відповідного попереднього блоку.
Запис операцій: всі операції запису не записуються безпосередньо в глобальну stateDB, а спочатку записуються в WriteSet очікувального стану. Після завершення виконання транзакції, через перевірку конфліктів, знову намагаються об'єднати результати зміни стану в глобальну stateDB.
Для вирішення проблеми конфлікту станів було введено механізм виявлення конфліктів:
Виявлення конфліктів: EVM моніторить ReadSet і WriteSet різних транзакцій. Якщо виявлено, що кілька транзакцій намагаються читати та записувати один і той же елемент стану, то це вважається конфліктом.
Обробка конфліктів: У разі виявлення конфлікту конфліктна транзакція буде помічена як така, що потребує повторного виконання.
Після виконання всіх угод записи змін у кількох pending-stateDB будуть об'єднані в глобальний stateDB. Якщо об'єднання буде успішним, EVM надішле фінальний стан до глобального дерева станів і згенерує новий корінь стану.
Паралельна оптимізація з використанням багатопоточності суттєво підвищує продуктивність, особливо при обробці складних транзакцій смарт-контрактів. Дослідження показують, що в умовах низької конфліктності завантаження, TPS у бенчмарках підвищується в 3-5 разів у порівнянні з традиційним послідовним виконанням. У випадках високої конфліктності завантаження, теоретично, якщо використовувати всі можливі оптимізації, можна досягти навіть 60-кратного підвищення.
Підсумок
Оптимізаційне рішення EVM для багатопотокового паралельного виконання значно підвищило здатність EVM обробляти транзакції шляхом призначення тимчасової бібліотеки станів для кожної транзакції та паралельного виконання транзакцій у різних потоках. Завдяки оптимізації операцій читання та запису та впровадженню механізму виявлення конфліктів, публічна ланцюгова система EVM здатна досягти масштабної паралелізації транзакцій за умови забезпечення узгодженості станів, вирішуючи проблеми продуктивності, що виникають з традиційної моделі послідовного виконання. Це закладає важливу основу для майбутнього розвитку Ethereum Rollup.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
15 лайків
Нагородити
15
6
Репост
Поділіться
Прокоментувати
0/400
TokenVelocityTrauma
· 08-02 02:05
Проблеми з продуктивністю потрібно покращити.
Переглянути оригіналвідповісти на0
ForkPrince
· 07-30 22:41
Оптимізація підвищення дуже очікується
Переглянути оригіналвідповісти на0
MEVVictimAlliance
· 07-30 14:54
Ефективність значно зросла
Переглянути оригіналвідповісти на0
FalseProfitProphet
· 07-30 10:43
Паралелізація прискорює чудово
Переглянути оригіналвідповісти на0
ShitcoinConnoisseur
· 07-30 10:42
Великий вузол продуктивності послідовного виконання
Оптимізація EVM: Паралельна обробка за допомогою багатопоточності для підвищення ефективності обробки транзакцій
Шлях оптимізації паралелізації EVM
Відомо, що EVM є одним із найважливіших основних компонентів Ethereum, виконуючи ключову роль як "виконавчий механізм" і "середовище виконання смарт-контрактів". У мережі публічних ланцюгів, що складається з тисяч вузлів, наявність віртуальної машини дозволяє смарт-контрактам виконуватися однаково на вузлах з різними апаратними конфігураціями, що забезпечує узгодженість результатів. Ця кросплатформна сумісність подібна до Java Virtual Machine (JVM).
Смарт-контракти перед додаванням в блокчейн компілюються в байт-код EVM. Під час виконання контракту EVM послідовно читає цей байт-код, кожна команда має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання команд, а обсяг витрат залежить від складності операцій.
Як основний виконавчий механізм Ethereum, EVM використовує послідовний спосіб виконання для обробки транзакцій. Усі транзакції чергуються в єдиній черзі та виконуються в порядку їх підтвердження. Цей дизайн простий у підтримці, але з розширенням користувацької бази та ітерацією технологій його продуктивнісні обмеження стають все більш очевидними, особливо після того, як технологія Rollup стала зрілою, що особливо помітно в мережі другого рівня Ethereum.
Секвенсер як ключовий компонент Layer2 виконує всі обчислювальні завдання в єдиному серверному форматі. Якщо супутні зовнішні модулі мають достатньо високу ефективність, остаточне вузьке місце залежатиме від ефективності самого Секвенсера, і в цей момент послідовне виконання стане величезною перешкодою.
Одна команда шляхом максимальної оптимізації рівня DA та модуля читання/запису даних змогла забезпечити виконання Sequencer приблизно 2000 і більше трансакцій 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 між звичайними рахунками, який не передбачає викликів контрактів, обробка відбувається дуже швидко, а плата за газ дуже низька.
Торговля контрактами передбачає виклик та виконання смарт-контрактів. EVM при обробці контрактних угод потребує покрокового тлумачення та виконання байт-коду інструкцій смарт-контракту. Чим складніша логіка контракту, тим більше інструкцій залучено, і тим більше ресурсів витрачається.
Наприклад, час обробки переказу ERC-20 приблизно вдвічі більший, ніж час обробки переказу EOA, а більш складні смарт-контракти, такі як операції торгівлі на певному DEX, можуть займати в десятки разів більше часу, ніж перекази EOA. Це пов'язано з тим, що DeFi-протоколи під час торгівлі потребують обробки ліквіднісних пулів, розрахунку цін, обміну токенів та інших складних логік, що вимагає виконання дуже складних обчислень.
У режимі послідовного виконання процес співпраці EVM та stateDB виглядає наступним чином:
Явно видно, що у моделі послідовного виконання EVM є вузькі місця: транзакції повинні виконуватися у порядку черги, і якщо трапляється смарт-контрактна транзакція, яка триває дуже довго, інші транзакції можуть лише чекати, що не дозволяє повністю використовувати апаратні ресурси, що суттєво обмежує ефективність.
Оптимізація багатопотокового паралелізму EVM
Паралельний EVM нагадує банк з кількома касами, де можна відкрити кілька потоків для одночасної обробки кількох транзакцій, що дозволяє підвищити ефективність у кілька разів. Але складність полягає в проблемі конфлікту станів, яка потребує координації.
Думка про паралельну оптимізацію EVM у певному проекті ZKRollup така:
Паралельне виконання угод за допомогою кількох потоків: налаштування декількох потоків для одночасної обробки різних угод, при цьому потоки не заважають один одному, що може збільшити швидкість обробки угод у декілька разів.
Виділити тимчасову базу даних стану для кожного потоку: кожному потоку виділяється незалежна тимчасова база даних стану (pending-stateDB). Коли потоки виконують транзакції, вони не змінюють глобальну stateDB безпосередньо, а тимчасово фіксують результати змін стану в pending-stateDB.
Синхронізація змін стану: після завершення виконання всіх транзакцій у блоці EVM послідовно синхронізує результати змін стану, зафіксовані в кожній pending-stateDB, до глобальної stateDB. Якщо під час виконання різних транзакцій не виникало конфліктів стану, записи з pending-stateDB можуть бути успішно об'єднані в глобальну stateDB.
Цей проект оптимізував обробку операцій читання та запису, щоб забезпечити правильний доступ транзакцій до стану даних і уникнути конфліктів:
Операція читання: коли транзакція потребує читання стану, EVM спочатку перевіряє ReadSet у Pending-state. Якщо необхідні дані присутні, їх безпосередньо читають з pending-stateDB. Якщо в ReadSet не знайдено відповідної пари ключ-значення, тоді читають історичні дані стану з глобального stateDB відповідного попереднього блоку.
Запис операцій: всі операції запису не записуються безпосередньо в глобальну stateDB, а спочатку записуються в WriteSet очікувального стану. Після завершення виконання транзакції, через перевірку конфліктів, знову намагаються об'єднати результати зміни стану в глобальну stateDB.
Для вирішення проблеми конфлікту станів було введено механізм виявлення конфліктів:
Після виконання всіх угод записи змін у кількох pending-stateDB будуть об'єднані в глобальний stateDB. Якщо об'єднання буде успішним, EVM надішле фінальний стан до глобального дерева станів і згенерує новий корінь стану.
Паралельна оптимізація з використанням багатопоточності суттєво підвищує продуктивність, особливо при обробці складних транзакцій смарт-контрактів. Дослідження показують, що в умовах низької конфліктності завантаження, TPS у бенчмарках підвищується в 3-5 разів у порівнянні з традиційним послідовним виконанням. У випадках високої конфліктності завантаження, теоретично, якщо використовувати всі можливі оптимізації, можна досягти навіть 60-кратного підвищення.
Підсумок
Оптимізаційне рішення EVM для багатопотокового паралельного виконання значно підвищило здатність EVM обробляти транзакції шляхом призначення тимчасової бібліотеки станів для кожної транзакції та паралельного виконання транзакцій у різних потоках. Завдяки оптимізації операцій читання та запису та впровадженню механізму виявлення конфліктів, публічна ланцюгова система EVM здатна досягти масштабної паралелізації транзакцій за умови забезпечення узгодженості станів, вирішуючи проблеми продуктивності, що виникають з традиційної моделі послідовного виконання. Це закладає важливу основу для майбутнього розвитку Ethereum Rollup.