Панорама паралельних обчислень у 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
• Виклик рівня / Мікро VM паралельно (Call-level / MicroVM): представляє проект MegaETH
• Інструкційний рівень паралельності (Instruction-level): представляє проект GatlingX

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

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

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

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

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

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

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

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

Проекти паралельних обчислень, такі як 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), та через протокол повторного заставлення (