Паралелізація EVM: ключ до вирішення проблеми продуктивності Ethereum
EVM як виконавчий механізм Ethereum та середовище виконання смарт-контрактів є одним із найосновніших компонентів. Щоб забезпечити однакові результати смарт-контрактів на різних вузлах і задовольнити вимоги до узгодженості, технологія віртуальної машини стала найкращим вибором. EVM може виконувати смарт-контракти однаково на різних операційних системах і пристроях, гарантуючи крос-платформену сумісність.
Смарт-контракти перед додаванням в блокчейн компілюються в байт-код EVM. Коли EVM виконує контракт, вона послідовно читає цей байт-код, кожна інструкція має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання кожної інструкції, а обсяг споживання залежить від складності операції.
Як основний виконавчий механізм, EVM обробляє транзакції в серійному режимі, всі транзакції чергуються в єдиній черзі та виконуються в певному порядку. Цей дизайн простий у підтримці, але з розширенням користувацької бази та розвитком технологій його продуктивнісні обмеження стають дедалі помітнішими, особливо в Layer2.
Для ключового компонента Layer2 Sequencer, якщо ефективність супутніх модулів буде достатньо високою, кінцеве вузьке місце залежатиме від ефективності самого Sequencer. Деякі команди шляхом екстремальної оптимізації змогли досягти виконання близько 2000 ERC-20 переказів за секунду. Але для більш складних транзакцій TPS неодмінно значно знизиться. Тому паралелізація обробки транзакцій стає неминучою тенденцією майбутнього.
Ядро компонентів виконання транзакцій Ethereum
Окрім EVM, ще одним ключовим компонентом, тісно пов'язаним з виконанням транзакцій, є stateDB, що використовується для управління станом облікових записів та зберігання даних Ethereum. Ethereum використовує структуру дерева Merkle Patricia Trie в якості індексу бази даних. Кожного разу, коли транзакція виконується, деякі дані в stateDB змінюються, ці зміни в кінцевому підсумку відображаються в глобальному стані дерева.
stateDB відповідає за підтримку стану всіх Ethereum-акаунтів, включаючи EOA-акаунти та контракти, зберігаючи баланс акаунтів, код смарт-контрактів та інші дані. Під час виконання транзакції stateDB читає та записує відповідні дані акаунтів. Після завершення виконання транзакції stateDB подає новий стан до бази даних для постійного зберігання.
В цілому, EVM відповідає за інтерпретацію та виконання інструкцій смарт-контрактів, змінюючи стан блокчейну відповідно до обчислених результатів, тоді як stateDB слугує глобальним сховищем стану, керуючи змінами стану всіх рахунків та контрактів. Обидва елементи співпрацюють для створення середовища виконання транзакцій Ethereum.
Обмеження послідовного виконання
Транзакції в Ethereum поділяються на два типи: перекази EOA та контрактні транзакції. Перекази EOA є найпростішим типом транзакцій, швидкість обробки висока, а плата за газ низька. Контрактні транзакції включають виклик і виконання смарт-контрактів, EVM потребує покрокового розбору та виконання байт-код інструкцій контракту, що потребує більше ресурсів та є більш складним.
У режимі послідовного виконання транзакції в блоці обробляються одна за одною. Кожна транзакція має незалежний екземпляр EVM, але всі транзакції використовують одну й ту ж stateDB. Під час виконання EVM постійно взаємодіє з stateDB, читаючи дані та записуючи змінені результати.
Ця модель послідовного виконання має очевидні обмеження: транзакції повинні виконуватись у черзі, і якщо з'являється тривала транзакція з розумним контрактом, інші транзакції можуть лише чекати, не використовуючи повною мірою апаратні ресурси, що суттєво обмежує ефективність.
Оптимізація багатопотокового паралелізму EVM
Щоб подолати обмеження серійного виконання, в галузі було запропоновано рішення з багатопотокової паралельної оптимізації EVM. Це рішення подібне до банку, в якому кілька кас обслуговують клієнтів одночасно, що дозволяє обробляти багато транзакцій одночасно і суттєво підвищує ефективність. Але основним викликом паралельного виконання є проблема конфлікту стану, для вирішення якої необхідно вживати спеціальних заходів.
Думка про паралельну оптимізацію EVM для певного проєкту така:
Налаштування кількох потоків для одночасної обробки різних угод, при цьому потоки не заважають один одному.
Виділити окрему тимчасову базу даних стану (pending-stateDB) для кожного потоку. Коли потоки виконують транзакції, зміни стану тимчасово записуються в pending-stateDB, а не безпосередньо змінюють глобальну stateDB.
Після завершення виконання всіх транзакцій у блоці, зміни стану в кожному pending-stateDB послідовно синхронізуються з глобальним stateDB. Якщо немає конфліктів, записи можуть бути успішно об'єднані.
Цей план оптимізував операції читання та запису:
Операція читання: спочатку перевіряється ReadSet у стані Pending; якщо потрібні дані є, їх читають безпосередньо; в іншому випадку історичний стан читається з глобальної stateDB попереднього блоку.
Запис операцій: всі зміни спочатку записуються до WriteSet у стані очікування (Pending-state), а після завершення виконання транзакції намагаються об’єднатися з глобальною stateDB.
Для вирішення проблеми конфлікту станів було впроваджено механізм виявлення конфліктів:
Моніторинг ReadSet і WriteSet різних транзакцій, виявлення конфлікту, коли кілька транзакцій намагаються читати та записувати однакові елементи стану.
Позначити конфліктні транзакції як такі, що потребують повторного виконання.
Після виконання всіх угод зміни з кількох pending-stateDB об'єднуються в глобальний stateDB. Після успішного об'єднання остаточний стан подається в глобальне дерево станів, що призводить до створення нового кореня стану.
Дослідження показують, що в умовах низького конфлікту навантаження, паралельне виконання TPS порівняно з традиційним послідовним виконанням підвищує продуктивність у 3-5 разів. У випадку високого конфлікту навантаження, теоретично, після повної оптимізації, продуктивність може зрости навіть до 60 разів.
Підсумок
Оптимізаційне рішення багатопотокового паралельного виконання EVM значно підвищило потужність обробки транзакцій, призначивши тимчасову бібліотеку станів для кожної транзакції та паралельно виконуючи транзакції в різних потоках. Оптимізуючи операції читання та запису та впроваджуючи механізм виявлення конфліктів, було досягнуто масової паралелізації транзакцій при забезпеченні узгодженості стану, що вирішує проблеми продуктивності традиційної послідовної моделі виконання. Це заклало важливу основу для майбутнього розвитку Ethereum Rollup.
У майбутньому також можна буде далі досліджувати, як оптимізувати ефективність зберігання, реагувати на ситуації з високими конфліктами, а також використовувати GPU для оптимізації, щоб далі підвищити продуктивність EVM.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 лайків
Нагородити
6
6
Поділіться
Прокоментувати
0/400
down_only_larry
· 7год тому
зростання Віталік Бутерін нарешті зрозумів
Переглянути оригіналвідповісти на0
BlockTalk
· 7год тому
Кому цікаво, кому ні, в будь-якому випадку tps піднялося.
Переглянути оригіналвідповісти на0
LiquidityOracle
· 7год тому
Знову роздули на небо
Переглянути оригіналвідповісти на0
All-InQueen
· 7год тому
Тобто переказ став швидшим?
Переглянути оригіналвідповісти на0
ProveMyZK
· 7год тому
Ця оптимізація продуктивності належить до топових гравців.
Переглянути оригіналвідповісти на0
SmartContractPlumber
· 8год тому
Прямо дивіться на ризики масштабованості, механізм блокування спроектований занадто наївно.
Паралелізація EVM: прорив у покращенні продуктивності Ethereum
Паралелізація EVM: ключ до вирішення проблеми продуктивності Ethereum
EVM як виконавчий механізм Ethereum та середовище виконання смарт-контрактів є одним із найосновніших компонентів. Щоб забезпечити однакові результати смарт-контрактів на різних вузлах і задовольнити вимоги до узгодженості, технологія віртуальної машини стала найкращим вибором. EVM може виконувати смарт-контракти однаково на різних операційних системах і пристроях, гарантуючи крос-платформену сумісність.
Смарт-контракти перед додаванням в блокчейн компілюються в байт-код EVM. Коли EVM виконує контракт, вона послідовно читає цей байт-код, кожна інструкція має відповідну вартість Gas. EVM відстежує споживання Gas під час виконання кожної інструкції, а обсяг споживання залежить від складності операції.
Як основний виконавчий механізм, EVM обробляє транзакції в серійному режимі, всі транзакції чергуються в єдиній черзі та виконуються в певному порядку. Цей дизайн простий у підтримці, але з розширенням користувацької бази та розвитком технологій його продуктивнісні обмеження стають дедалі помітнішими, особливо в Layer2.
Для ключового компонента Layer2 Sequencer, якщо ефективність супутніх модулів буде достатньо високою, кінцеве вузьке місце залежатиме від ефективності самого Sequencer. Деякі команди шляхом екстремальної оптимізації змогли досягти виконання близько 2000 ERC-20 переказів за секунду. Але для більш складних транзакцій TPS неодмінно значно знизиться. Тому паралелізація обробки транзакцій стає неминучою тенденцією майбутнього.
Ядро компонентів виконання транзакцій Ethereum
Окрім EVM, ще одним ключовим компонентом, тісно пов'язаним з виконанням транзакцій, є stateDB, що використовується для управління станом облікових записів та зберігання даних Ethereum. Ethereum використовує структуру дерева Merkle Patricia Trie в якості індексу бази даних. Кожного разу, коли транзакція виконується, деякі дані в stateDB змінюються, ці зміни в кінцевому підсумку відображаються в глобальному стані дерева.
stateDB відповідає за підтримку стану всіх Ethereum-акаунтів, включаючи EOA-акаунти та контракти, зберігаючи баланс акаунтів, код смарт-контрактів та інші дані. Під час виконання транзакції stateDB читає та записує відповідні дані акаунтів. Після завершення виконання транзакції stateDB подає новий стан до бази даних для постійного зберігання.
В цілому, EVM відповідає за інтерпретацію та виконання інструкцій смарт-контрактів, змінюючи стан блокчейну відповідно до обчислених результатів, тоді як stateDB слугує глобальним сховищем стану, керуючи змінами стану всіх рахунків та контрактів. Обидва елементи співпрацюють для створення середовища виконання транзакцій Ethereum.
Обмеження послідовного виконання
Транзакції в Ethereum поділяються на два типи: перекази EOA та контрактні транзакції. Перекази EOA є найпростішим типом транзакцій, швидкість обробки висока, а плата за газ низька. Контрактні транзакції включають виклик і виконання смарт-контрактів, EVM потребує покрокового розбору та виконання байт-код інструкцій контракту, що потребує більше ресурсів та є більш складним.
У режимі послідовного виконання транзакції в блоці обробляються одна за одною. Кожна транзакція має незалежний екземпляр EVM, але всі транзакції використовують одну й ту ж stateDB. Під час виконання EVM постійно взаємодіє з stateDB, читаючи дані та записуючи змінені результати.
Ця модель послідовного виконання має очевидні обмеження: транзакції повинні виконуватись у черзі, і якщо з'являється тривала транзакція з розумним контрактом, інші транзакції можуть лише чекати, не використовуючи повною мірою апаратні ресурси, що суттєво обмежує ефективність.
Оптимізація багатопотокового паралелізму EVM
Щоб подолати обмеження серійного виконання, в галузі було запропоновано рішення з багатопотокової паралельної оптимізації EVM. Це рішення подібне до банку, в якому кілька кас обслуговують клієнтів одночасно, що дозволяє обробляти багато транзакцій одночасно і суттєво підвищує ефективність. Але основним викликом паралельного виконання є проблема конфлікту стану, для вирішення якої необхідно вживати спеціальних заходів.
Думка про паралельну оптимізацію EVM для певного проєкту така:
Налаштування кількох потоків для одночасної обробки різних угод, при цьому потоки не заважають один одному.
Виділити окрему тимчасову базу даних стану (pending-stateDB) для кожного потоку. Коли потоки виконують транзакції, зміни стану тимчасово записуються в pending-stateDB, а не безпосередньо змінюють глобальну stateDB.
Після завершення виконання всіх транзакцій у блоці, зміни стану в кожному pending-stateDB послідовно синхронізуються з глобальним stateDB. Якщо немає конфліктів, записи можуть бути успішно об'єднані.
Цей план оптимізував операції читання та запису:
Операція читання: спочатку перевіряється ReadSet у стані Pending; якщо потрібні дані є, їх читають безпосередньо; в іншому випадку історичний стан читається з глобальної stateDB попереднього блоку.
Запис операцій: всі зміни спочатку записуються до WriteSet у стані очікування (Pending-state), а після завершення виконання транзакції намагаються об’єднатися з глобальною stateDB.
Для вирішення проблеми конфлікту станів було впроваджено механізм виявлення конфліктів:
Після виконання всіх угод зміни з кількох pending-stateDB об'єднуються в глобальний stateDB. Після успішного об'єднання остаточний стан подається в глобальне дерево станів, що призводить до створення нового кореня стану.
Дослідження показують, що в умовах низького конфлікту навантаження, паралельне виконання TPS порівняно з традиційним послідовним виконанням підвищує продуктивність у 3-5 разів. У випадку високого конфлікту навантаження, теоретично, після повної оптимізації, продуктивність може зрости навіть до 60 разів.
Підсумок
Оптимізаційне рішення багатопотокового паралельного виконання EVM значно підвищило потужність обробки транзакцій, призначивши тимчасову бібліотеку станів для кожної транзакції та паралельно виконуючи транзакції в різних потоках. Оптимізуючи операції читання та запису та впроваджуючи механізм виявлення конфліктів, було досягнуто масової паралелізації транзакцій при забезпеченні узгодженості стану, що вирішує проблеми продуктивності традиційної послідовної моделі виконання. Це заклало важливу основу для майбутнього розвитку Ethereum Rollup.
У майбутньому також можна буде далі досліджувати, як оптимізувати ефективність зберігання, реагувати на ситуації з високими конфліктами, а також використовувати GPU для оптимізації, щоб далі підвищити продуктивність EVM.