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

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

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

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

Внутрішньо-ланкова паралельна обробка (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: Механізм паралельного виконання з багатоступеневими конвеєрами

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

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

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

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

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

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

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

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

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

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

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

На відміну від позиціонування L1 Monada, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може функціонувати як незалежний L1 публічний ланцюг, а також як підвищувальний рівень виконання (Execution Layer) або модульний компонент на Ethereum. Основною метою його проектування є ізоляція та декомпозиція логіки облікових записів, середовища виконання та стану в незалежно плановані мінімальні одиниці для досягнення високої паралельності виконання та низької затримки відповідей. Ключова інновація 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.

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

Проекти паралельних обчислень, такі як Monad і MegaETH, в основному зосереджені на оптимізації пропускної здатності, з основною метою підвищення TPS в мережі, реалізуючи паралельну обробку на рівні транзакцій або облікових записів за допомогою відкладеного виконання (Deferred Execution) та архітектури мікровіртуальних машин (Micro-VM). Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як «Rollup Mesh». Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPN), забезпечуючи мульти-віртуальне середовище (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. Модульна консенсус та