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

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

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

State Dependency 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), та реалізує основну мережу з SPNs через протокол повторного стейкінгу.