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

I. Технологічний фон та мотивація розвитку паралельних обчислень

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

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

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

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

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

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

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

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