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

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

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

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

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

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

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

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

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

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