Паралельні обчислення в 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

На відміну від позиціонування Monad, MegaETH позиціонується як сумісний з EVM модульний високопродуктивний паралельний виконавчий рівень, який може функціонувати як незалежна L1 публічна блокчейн-мережа, так і як рівень покращення виконання (Execution Layer) або модульний компонент на Ethereum. Основною метою його розробки є ізоляція та декомпозиція логіки облікових записів, середовища виконання та стану в незалежно керовані мінімальні одиниці для досягнення високої конкурентоспроможності виконання в межах ланцюга та низької затримки відповіді. Ключовою інновацією MegaETH є: архітектура Micro-VM + State Dependency DAG (орієнтований ациклічний граф залежностей стану) та модульний механізм синхронізації, які разом формують паралельну виконавчу систему, орієнтовану на "потокову" обробку в межах ланцюга.

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

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

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

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,