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

Один. Застосування паралельних обчислень у блокчейні

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

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

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

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

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

Модель асинхронної конкурентності поза ланцюгом, представлена системою акторів (Agent / Actor Model), належить до іншого парадигми паралельних обчислень. Як крос-ланцюгова/асинхронна система повідомлень (не модель синхронізації блоків), кожен агент є незалежно працюючим "інтелектуальним процесом", який працює асинхронно в паралельному режимі, обробляючи повідомлення та події без необхідності синхронізації. Представлені проекти: 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 публічна блокчейн-мережа або як шар підвищення виконання на Ethereum (Execution Layer) або модульний компонент. Його основною метою є ізоляція та декомпозиція логіки облікового запису, середовища виконання та стану на незалежні одиниці для досягнення високої паралельної обробки та низької затримки відповіді в межах мережі. Ключовою інновацією MegaETH є: архітектура Micro-VM + DAG залежностей стану (орієнтований ациклічний граф залежностей стану) та модульний механізм синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "потоковість у межах мережі".

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

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

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

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

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

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

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

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

Дизайнерські концепції Monad і MegaETH суттєво відрізняються від шардінгу (Sharding): шардінг розбиває блокчейн на кілька незалежних субланок (шардів), кожен з яких відповідає за частину транзакцій і стану, долаючи обмеження одно链 на рівні мережі; тоді як 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), і через протокол повторного стейкінгу (