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

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

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

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

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