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

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

"Неможливий трикутник" блокчейну (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

Зовнішня асинхронна конкурентна модель, представленна системою агентів (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 Monada, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може використовуватися як незалежна L1 публічна блокчейн, так і як рівень підвищення виконання (Execution Layer) або модульний компонент в Ethereum. Його основною метою є розділення логіки облікового запису, середовища виконання та стану на незалежно плановані мінімальні одиниці, щоб досягти високої паралельності виконання в ланцюгу та низької затримки реагування. Ключова інновація MegaETH полягає у: архітектурі Micro-VM + State Dependency 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". Ця архітектура підтримує співпрацю між основною мережею і спеціальними обробними мережами (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. Модульна консенсусна система та механізм повторного стейкінгу (Modular Consensus & Restaking): Pharos вводить гнучку консенсусну механіку, яка підтримує різноманітні моделі консенсусу (такі як PBFT, PoS, PoA) та реалізує безпечний обмін і інтеграцію ресурсів між основною мережею та SPN за допомогою протоколу повторного стейкінгу (Restaking).

Крім того, Pharos через багатоверсійне дерево Меркла, дельта-кодування (Delta Encoding), адресацію версій (Versioned Addressing) та технологію ADS Pushdown реконструював модель виконання на рівні бази даних, запустивши рідний блокчейн з високопродуктивним сховищем Pharos Store, що забезпечує високу пропускну спроможність, низьку затримку та високу надійність.