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

Один. Вступ: Вічна тема масштабування блокчейн

"Неможливий трикутник" блокчейну (Blockchain Trilemma) "безпека", "децентралізація", "масштабованість" виявляє суттєвий компроміс у дизайні блокчейн-систем, а саме, що блокчейн-проекти важко одночасно реалізувати "максимальну безпеку, участь всіх, високу швидкість обробки". Щодо "масштабованості" цього вічного питання, на сьогоднішній день основні рішення для розширення блокчейну на ринку можна розділити за парадигмами, включаючи:

• Виконання покращеного масштабування: підвищення виконавчих можливостей на місці, наприклад, паралельна обробка, GPU, багатоядерність
• Ізоляція стану типу масштабування: горизонтальне розділення стану/Shard, наприклад, шардінг, UTXO, багатопідмережі
• Позапідрядне розширення: виконання відбувається поза ланцюгом, наприклад, Rollup, Coprocessor, DA
• Розширення з декомпозицією структури: модульна архітектура, спільна робота, наприклад, модульний ланцюг, спільний сортувальник, Rollup Mesh
• Асинхронне паралельне масштабування: модель Актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопотокове асинхронне з'єднання

Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, DA-модулі, модульну структуру, систему Actor, стиснення zk-доказів, Stateless-архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, є повною системою розширення "багаторівневої координації та модульного поєднання". У цій статті основна увага приділяється способу розширення, що ґрунтується на паралельних обчисленнях.

Внутрішня паралельна обробка ( 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: Механізм паралельного виконання з багатоступеневим конвеєром

Pipelining є основною концепцією паралельного виконання Monad, основна ідея якої полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів та паралельній обробці цих етапів, формуючи об'ємну архітектуру конвеєра, де кожен етап працює на незалежних потоках або ядрах, забезпечуючи паралельну обробку між блоками, в результаті чого досягається підвищення пропускної здатності та зниження затримки. Ці етапи включають: пропозицію транзакції (Propose), досягнення консенсусу (Consensus), виконання транзакції (Execution) та подачу блоку (Commit).

Асинхронне виконання: консенсус - асинхронне декомпонування виконання

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

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

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

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

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

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

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

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

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

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

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

MegaETH впроваджує модель виконання "мікровіртуальної машини (Micro-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), і досягає безпечного обміну та інтеграції ресурсів між основною мережею та SPNs через протокол повторної застави (Restaking).

Крім того, Pharos використовує багатоверсійне дерево Меркла, дельта-кодування (Delta Encoding), версії