Панорамна карта паралельних обчислень 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 або рішення з фрагментації для масштабування належать до механізму системного рівня для паралелізму, а не до паралельних обчислень у межах блокчейну. Вони реалізують масштабування через «паралельне виконання кількох ланцюгів / виконавчих доменів», а не підвищення паралелізму всередині одного блоку / віртуальної машини. Ці рішення для масштабування не є основною темою цієї статті, але ми все ж будемо використовувати їх для порівняння відмінностей у архітектурних концепціях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) та через протокол повторної застави (