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

Модель асинхронної паралельності поза ланцюгами, представлена системою агентів (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), що забезпечує оптимізацію від кінця до кінця.

Пайплайнинг: механізм паралельного виконання з багатоступеневим конвеєром

Пайплайнинг є основною концепцією паралельного виконання монад, його основна ідея полягає в розділенні процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, формуючи об'ємну архітектуру конвеєра, де кожен етап виконується в незалежних потоках або ядрах, що забезпечує паралельну обробку між блоками та в кінцевому підсумку підвищує пропускну спроможність і знижує затримки. Ці етапи включають: пропозиція транзакцій (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), а не синхронні виклики, що дозволяє великій кількості ВМ виконуватись незалежно та зберігатись окремо, що природно забезпечує паралелізм.

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

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. Спеціалізовані мережі обробки (SPN): SPN є ключовими компонентами архітектури Pharos, схожими на модульні підмережі, спеціально призначені для обробки певних типів завдань або застосувань. Завдяки SPN, Pharos може реалізувати динамічне розподілення ресурсів та паралельну обробку завдань, що ще більше підвищує масштабованість і продуктивність системи.
4. Модульна консенсусна система та механізм повторного стейкінгу (Modular Consensus & Restaking): Pharos впроваджує гнучкий механізм консенсусу, що підтримує кілька моделей консенсусу (як-от PBFT, PoS, PoA), а також реалізує основну мережу з SPNs через протокол повторного стейкінгу.