Панорама паралельних обчислень у 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
• Рівень виклику / Паралельний MicroVM (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

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