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

1. Позиція та цінність технології паралельних обчислень у розширенні блокчейну

"Неможливий трикутник" блокчейну (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), що забезпечує оптимізацію від кінця до кінця.

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

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

Крім того, Pharos за допомогою технологій багатоверсійного дерева Меркла, диференціального кодування, адресації версій та підсування ADS реконструює модель виконання з нижнього рівня сховища, запроваджуючи рідний блокчейн високопродуктивний сховищний двигун Phar.