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

I. Огляд паралельних обчислень Web3

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

• Виконання посиленої масштабованості: підвищення виконавчих можливостей на місці, наприклад, паралельна обробка, GPU, багато ядер.
• Ізоляція стану для масштабування: горизонтальне розділення стану / Shard, наприклад, шардінг, UTXO, багатопідмережі
• Внешня масштабованість з обробкою: виконання поза ланцюгом, наприклад, Rollup, Копрогресор, 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

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

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

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

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) та через протокол повторного стейкінгу (