Web3 паралельні обчислення: нова парадигма, що долає межі продуктивності EVM

Пейзаж паралельних обчислень Web3: найкраще рішення для нативного розширення?

"Неможливий трикутник" блокчейну (Blockchain Trilemma) – "безпека", "децентралізація", "масштабованість" – вказує на суттєві компроміси в дизайні блокчейн-систем, тобто проекти блокчейну важко досягти одночасно "максимальної безпеки, участі всіх та швидкої обробки". Щодо "масштабованості" цієї вічної теми, наразі основні рішення для розширення блокчейну на ринку класифікуються за парадигмами, включаючи:

  • Виконання вдосконаленого масштабування: підвищення виконавчої здатності на місці, наприклад, паралельно, за допомогою GPU, багатоядерних процесорів.
  • Ізоляція стану для масштабування: горизонтальне розділення стану / Shard, наприклад, шардінг, UTXO, багато підмереж
  • Зовнішнє розширення типу аутсорсингу: виконання відбувається поза ланцюгом, наприклад, Rollup, Coprocessor, DA
  • Декуплююча розширювальна структура: модульна архітектура, спільна робота, наприклад, модульний ланцюг, спільний сортувальник, Rollup Mesh
  • Асинхронне масштабування з конкурентністю: модель актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопотокове асинхронне з'єднання

Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модулі DA, модульну структуру, систему Actor, стиснення zk-доказів, архітектуру без стану тощо, охоплюють виконання, стан, дані, структуру на кількох рівнях, є "повною системою розширення з багаторівневою координацією та модульним поєднанням". У цій статті основна увага приділяється основному способу розширення на основі паралельних обчислень.

Внутрішня паралельна обробка (intra-chain parallelism), зосереджується на паралельному виконанні транзакцій / інструкцій всередині блоку. Згідно з механізмами паралелізму, способи масштабування можна поділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію, поступово зменшуючи розмір паралельних одиниць, підвищуючи інтенсивність паралелізму, а також ускладнюючи планування, складність програмування та труднощі реалізації.

  • Паралельність на рівні рахунку (Account-level): представляє проект Solana
  • Об'єктний рівень паралельності (Object-level): представляє проект Sui
  • Рівень транзакцій (Transaction-level): представляє проект Monad, Aptos
  • Виклик рівня / Мікро ВМ паралельно (Call-level / MicroVM): представляє проект MegaETH
  • Інструкційний рівень паралелізму (Instruction-level): представляє проект GatlingX

Зовнішня асинхронна конкурентна модель, представлена системою агентів (модель агентів/акторів), що належить до іншої парадигми паралельних обчислень, як міжланцюгова/асинхронна система повідомлень (модель без синхронізації блоків), кожен агент є незалежно працюючим "агентським процесом", асинхронно обробляючи повідомлення в паралельному режимі, орієнтуючись на події без необхідності синхронного планування, відомі проекти: AO, ICP, Cartesi тощо.

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

Web3 паралельні обчислення в контексті: найкраще рішення для рідної масштабованості?

Два, EVM-система паралельного посилення ланцюга: прорив меж продуктивності в сумісності

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

Аналіз механізму паралельних обчислень Monad

Monad є високопродуктивним Layer1 блокчейном, переробленим для віртуальної машини Ethereum (EVM), заснованим на базовій паралельній концепції конвеєрної обробки (Pipelining). У консенсусному шарі здійснюється асинхронне виконання (Asynchronous Execution), а в шарі виконання - оптимістичне паралельне виконання (Optimistic Parallel Execution). Крім того, в консенсусному та зберігання шарі Monad впроваджує високопродуктивний BFT протокол (MonadBFT) і спеціалізовану базу даних (MonadDB), що забезпечує оптимізацію від кінця до кінця.

Пайплайнинг: механізм паралельного виконання з багатоступеневим конвеєром

Пайплайнинг є основною концепцією паралельного виконання Монад, його основна ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів та паралельній обробці цих етапів, що формує тривимірну архітектуру конвеєра. Кожен етап виконується в незалежних потоках або ядрах, що дозволяє реалізувати паралельну обробку між блоками, в результаті чого досягається підвищення пропускної здатності та зниження затримки. Ці етапи включають: пропозицію транзакцій (Propose), досягнення консенсусу (Consensus), виконання транзакцій (Execution) та коміт блоків (Commit).

Асинхронне виконання: консенсус - виконання асинхронного декуплінгу

У традиційних блокчейнах консенсус і виконання транзакцій зазвичай є синхронним процесом, і ця послідовна модель суттєво обмежує розширення продуктивності. Monad реалізував асинхронне виконання на рівні консенсусу, асинхронне виконання на рівні виконання та асинхронне зберігання. Це суттєво зменшує час блоку (block time) і затримку підтвердження, роблячи систему більш стійкою, обробку процесів більш детальною, а використання ресурсів - вищим.

Основний дизайн:

  • Процес консенсусу (шар консенсусу) відповідає лише за впорядкування транзакцій, не виконуючи логіку контракту.
  • Процес виконання (виконавчий рівень) асинхронно запускається після завершення консенсусу.
  • Після завершення консенсусу відразу переходьте до процесу консенсусу наступного блоку, не чекаючи на виконання.

Оптимістичне паралельне виконання:乐观并行执行

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

Механізм виконання:

  • Monad оптимістично паралельно виконує всі транзакції, припускаючи, що більшість транзакцій не мають стану конфлікту.
  • Одночасно працює "Детектор конфліктів (Conflict Detector)", щоб контролювати, чи доступали транзакції до одного й того ж стану (наприклад, конфлікти читання/запису).
  • Якщо виявлено конфлікт, то конфліктні транзакції будуть серіалізовані та повторно виконані, щоб забезпечити правильність стану.

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

Web3 паралельних обчислень: найкраще рішення для нативного масштабування?

Аналіз механізму паралельних обчислень MegaETH

На відміну від L1 позиціонування Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може бути як незалежною L1 публічною блокчейн-мережею, так і підсилювальним шаром виконання на Ethereum (Execution Layer) або модульним компонентом. Основною метою його дизайну є ізоляція логіки облікових записів, середовища виконання та стану, розкладаючи їх на найменші одиниці, які можуть бути незалежно заплановані, щоб досягти високої конкурентоспроможності виконання та низької затримки реагування в межах мережі. Ключовою інновацією, запропонованою MegaETH, є: архітектура Micro-VM + State Dependency DAG (орієнтований ациклічний граф залежностей стану) та модульний механізм синхронізації, які спільно створюють паралельну виконавчу систему, орієнтовану на "потоковість у межах мережі".

Архітектура Micro-VM (мікровіртуальна машина): обліковий запис як потік

MegaETH впроваджує модель виконання "мікровіртуальної машини (Micro-VM) на кожен обліковий запис", "потокуючи" середовище виконання, щоб надати мінімальну одиницю ізоляції для паралельного планування. Ці VM спілкуються між собою через асинхронне повідомлення (Asynchronous Messaging), а не через синхронні виклики, що дозволяє великій кількості VM виконуватись незалежно, зберігатись незалежно, що забезпечує природну паралельність.

Залежність стану DAG: механізм планування на основі графа залежностей

MegaETH побудував систему розкладу DAG, засновану на відносинах доступу до стану облікових записів, яка в реальному часі підтримує глобальну залежність (Dependency Graph). Кожна транзакція модифікує певні облікові записи, читає певні облікові записи, що все моделюється як залежності. Транзакції без конфліктів можуть бути виконані паралельно, тоді як транзакції з залежностями будуть послідовно або відкладено розкладені за топологічним порядком. Залежність забезпечує узгодженість стану та не повторне записування під час паралельного виконання.

Асинхронне виконання та механізм зворотного виклику

MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними (нерекурсивним виконанням), і при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.

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

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

Web3 паралельні обчислення: найкраще рішення для рідного масштабування?

Monad та MegaETH мають значні відмінності в своїх дизайнерських концепціях щодо шардінгу: шардінг розділяє блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій та стану, що руйнує обмеження одноланковості для розширення на мережевому рівні; натомість Monad та MegaETH зберігають цілісність одноланки, лише горизонтально розширюючись на рівні виконання, досягаючи оптимізації паралельного виконання всередині одноланки для покращення продуктивності. Обидва представляють два напрямки в розширенні блокчейну: вертикальне зміцнення та горизонтальне розширення.

Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної здатності, що є основною метою підвищення TPS в ланцюзі. Це досягається через відкладене виконання (Deferred Execution) та архітектуру мікровіртуальної машини (Micro-VM), що забезпечує паралельну обробку на рівні транзакцій або рахунків. Pharos Network, як модульна, повноцінна паралельна мережа L1 блокчейнів, має основний механізм паралельних обчислень, відомий як "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), підтримує багатовіртуальне середовище (EVM та Wasm) та інтегрує передові технології, такі як нульові знання (ZK) та надійні середовища виконання (TEE).

Аналіз механізму паралельних обчислень Rollup Mesh:

  1. Повний життєвий цикл асинхронної обробки конвеєра (Full Lifecycle Asynchronous Pipelining): Pharos розділяє різні етапи транзакції (такі як консенсус, виконання, зберігання) і використовує асинхронний спосіб обробки, що дозволяє кожному етапу працювати незалежно та паралельно, тим самим підвищуючи загальну ефективність обробки.
  2. Паралельне виконання двох віртуальних машин (Dual VM Parallel Execution): Pharos підтримує два віртуальні середовища EVM і WASM, що дозволяє розробникам обирати відповідне середовище виконання в залежності від потреб. Ця архітектура з двома віртуальними машинами не лише підвищує гнучкість системи, але й покращує можливості обробки транзакцій завдяки паралельному виконанню.
  3. Спеціалізовані мережі (SPNs): SPNs є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, які спеціально призначені для обробки певних типів завдань або застосувань. Завдяки SPNs Pharos може реалізувати динамічний розподіл ресурсів і паралельну обробку завдань, що ще більше підвищує масштабованість і продуктивність системи.
  4. Модульний консенсус та повторне заставлення (Modular Consensus & Restaking): Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу (такі як PBFT, PoS, PoA), і через протокол повторного заставлення (Rest
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 8
  • Репост
  • Поділіться
Прокоментувати
0/400
AirdropBuffetvip
· 08-01 11:54
Білі витратили гроші на аірдроп.
Переглянути оригіналвідповісти на0
TeaTimeTradervip
· 08-01 05:18
Складні проблеми потрібно розв'язувати повільно.
Переглянути оригіналвідповісти на0
SatoshiSherpavip
· 07-31 06:56
Безпека все ще є пріоритетом
Переглянути оригіналвідповісти на0
CryptoDouble-O-Sevenvip
· 07-31 04:04
Безпека найважливіша
Переглянути оригіналвідповісти на0
BrokenDAOvip
· 07-31 03:59
Оптимізація більш потужного ланцюга
Переглянути оригіналвідповісти на0
MetaverseVagabondvip
· 07-31 03:58
Розширення - це правильне рішення.
Переглянути оригіналвідповісти на0
BearHuggervip
· 07-31 03:56
Виконавчий рівень є ключовим моментом
Переглянути оригіналвідповісти на0
LiquidationKingvip
· 07-31 03:54
Ключовим є ізоляція стану
Переглянути оригіналвідповісти на0
  • Закріпити