Пейзаж паралельних обчислень 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 в Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може функціонувати як незалежний L1 публічний ланцюг або як підсилювальний шар виконання (Execution Layer) на Ethereum чи модульний компонент. Його основна мета дизайну полягає в розмежуванні логіки облікових записів, середовища виконання та стану на незалежно плановані мінімальні одиниці для досягнення високої паралельної обробки виконання та низької затримки відповіді в межах ланцюга. Ключова інновація, запропонована 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 суттєво відрізняються від шардінгу: шардінг розрізає блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій і стану, руйнуючи обмеження однорангової мережі на рівні розширення; тоді як 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 через протокол повторного ставлення (Restaking).

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