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

I. Фон та огляд

"Неможливий трикутник" блокчейну (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 є основним поняттям паралельного виконання Monad, його основна ідея полягає в розділенні процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує тривимірну архітектуру конвеєра, де кожен етап виконується на незалежному потоці або ядрі, досягаючи паралельної обробки через блоки і, в кінцевому підсумку, підвищуючи пропускну здатність і знижуючи затримки. Ці етапи включають: пропозицію транзакції (Propose), досягнення консенсусу (Consensus), виконання транзакції (Execution) та подачу блоку (Commit).

Асинхронне виконання: консенсус - асинхронне роз'єднання виконання

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

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

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

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

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

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

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

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

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

На відміну від позиціонування Monad на L1, 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 суттєво відрізняється від шардінгу: шардінг розрізає блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій і стану, руйнуючи обмеження однорангового блокчейну на рівні мережі; тоді як 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), та