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

Одне. Вічна тема розширення блокчейну

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

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

Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модулі DA, модульну структуру, систему акторів, стиснення 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, реалізуючи мікровіртуальну машину в упаковці на основі рахунків, здійснюючи розподіл транзакцій через граф залежностей стану та замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це платформа паралельних обчислень, яка була повністю пер redesignована з "структури рахунків → архітектури розподілу → процесу виконання", що забезпечує нові парадигми для побудови системи наступного покоління високої продуктивності на ланцюгу.

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

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