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

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

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

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

Внутрішня паралельна обробка (intra-chain parallelism), зосереджуючись на паралельному виконанні транзакцій / інструкцій усередині блокчейну. За механізмом паралелізму, способи розширення можна розділити на п’ять основних категорій, кожна з яких представляє різні прагнення до продуктивності, моделі розробки та архітектурну філософію, з поступовим зменшенням розміру паралельних частин, зростанням інтенсивності паралелізму, а також зростанням складності планування, складності програмування та труднощів реалізації.

• Обліковий рівень паралельності (Рівень облікового запису ): представляє проект Solana
• Об'єктний рівень (Object-level): представляє проект Sui
• Торгівельний рівень (Transaction-level): представляє проект Monad, Aptos
• Виклик рівня / Мікро VM паралельно (Call-level / MicroVM): представляє проект MegaETH
• Інструкційний рівень ( Instruction-level ): представляє проект GatlingX

Модель асинхронної конкурентності поза блокчейном, представлена системою Actor (Agent / Actor Model), яка належить до іншої парадигми паралельних обчислень, як кросчейн / асинхронна система повідомлень ( неконсенсусна модель блокчейну), де кожен Agent є незалежно працюючим «інтелектуальним процесом», асинхронне повідомлення в паралельному режимі, події, що управляються подіями, без потреби в синхронізації, до представників проектів відносяться AO, ICP, Cartesi тощо.

А відомі нам Rollup або шардінг-розширювальні рішення належать до системних механізмів паралелізму, а не до внутрішньоланцюгових паралельних обчислень. Вони реалізують розширення шляхом «паралельного запуску кількох ланцюгів/виконавчих доменів», а не підвищення паралелізму всередині одного блоку/віртуальної машини. Ці розширювальні рішення не є основною темою цієї статті, але ми все ж будемо використовувати їх для порівняння аналогій архітектурних концепцій.

Два, EVM-сумісна паралельна посилена ланцюг: прорив меж продуктивності в сумісності

Архітектура серійної обробки Ethereum розвивалася до сьогодні, переживши кілька спроб масштабування, включаючи шардінг, Rollup, модульну архітектуру тощо, але вузьке місце в пропускній здатності виконавчого рівня досі не було принципово подолано. Водночас EVM і Solidity залишаються найсильнішими платформами смарт-контрактів з точки зору розробників та екосистеми. Таким чином, EVM-сумісні паралельні ланцюги, як ключовий шлях, що поєднує екосумісність і підвищення виконувальної продуктивності, стають важливим напрямком нової хвилі масштабування. Monad і MegaETH є найпредставницькішими проектами в цьому напрямку, які, відповідно, базуються на затриманому виконанні та розподілі стану, створюючи архітектуру паралельної обробки EVM для високої конкурентності та високої пропускної здатності.

Аналіз механізму паралельних обчислень Monad

Monad є високопродуктивним блокчейном Layer1, переосмисленим для віртуальної машини Ефіру (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 публічний блокчейн або як шар підвищення виконання на Ethereum (Execution Layer) або модульний компонент. Основною метою проектування є розділення логіки рахунку, середовища виконання та стану на незалежно керовані мінімальні одиниці, щоб забезпечити високу паралельність виконання та низьку затримку відповіді в межах ланцюга. Ключова інновація, запропонована MegaETH, полягає в архітектурі Micro-VM + State Dependency DAG(орієнтований ациклічний граф залежностей стану) та модульному механізмі синхронізації, які разом створюють паралельну виконавчу систему, орієнтуючись на «потокове виконання в межах ланцюга».

Micro-VM(мікровіртуальна машина)архітектура: рахунок як потік

MegaETH впроваджує модель виконання «один мікровіртуальний комп'ютер на кожен рахунок(Micro-VM)», яка «потоковує» середовище виконання, забезпечуючи мінімальну одиницю ізоляції для паралельного планування. Ці ВМ взаємодіють через асинхронний обмін повідомленнями(Asynchronous Messaging), а не синхронні виклики, що дозволяє великій кількості ВМ виконуватись незалежно й зберігатись окремо, природно паралельно.

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

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

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

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

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

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

Дизайнерські концепції Monad і MegaETH суттєво відрізняються від шардінгу (Sharding): шардінг розділяє блокчейн на кілька незалежних підланцюгів (Shard ), кожен з яких відповідає за частину транзакцій та стану, зламуючи обмеження одночейнності в розширенні на мережевому рівні; в той час як Monad і MegaETH зберігають цілісність одночейнності, лише горизонтально розширюючись на виконавчому рівні, досягаючи оптимізації паралельного виконання всередині одночейнності для покращення продуктивності. Обидва представляють два напрями у шляху розширення блокчейну: вертикальне зміцнення та горизонтальне розширення.

Проекти паралельних обчислень, такі як Monad і MegaETH, головним чином зосереджені на оптимізації пропускної здатності, з метою підвищення TPS на ланцюзі, реалізуючи паралельну обробку на рівні транзакцій або рахунків через затримане виконання (Deferred Execution) та мікровіртуальну машину (Micro-VM). Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, який називається «Rollup Mesh». Ця архітектура підтримує багатовіртуальне середовище (EVM та Wasm) через спільну роботу основної мережі та спеціалізованої обробної мережі (SPNs), а також інтегрує передові технології, такі як нульове знання (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 ): Phar