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

I. Вступ: «Неможливий трикутник» блокчейну та рішення щодо масштабування

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

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

Зовнішня асинхронна паралельна модель, представлена системою агентів (модель агентів/акторів), належить до ще одного паралельного обчислювального парадигми. Як система міжланцюгових/асинхронних повідомлень (не блокчейн-синхронна модель), кожен агент працює як незалежний «процес агента», асинхронно передає повідомлення та події в паралельному режимі, не потребуючи синхронного планування. Представлені проекти: 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 + DAG залежностей стану (орієнтований ациклічний граф залежностей стану) та модульному механізмі синхронізації, які разом створюють паралельну систему виконання, орієнтовану на "потокове виконання в межах ланцюга".

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

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

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

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

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

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

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

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

Крім того, Pharos за допомогою багаторівневих дерев Меркла, диференціального кодування (Delta Encoding), адресації версій (Versioned Addressing) та технології ADS Pushdown реконструює модель виконання з нижнього рівня сховищ, запустивши рідний блокчейн з високопродуктивним сховищем Pharos Store, що забезпечує високу пропускну спроможність і низьку затримку.