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

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

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

Рішення щодо масштабування блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модулі DA, модульну структуру, систему Actor, стиснення zk-доказів, безстатеву архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, що є "повною системою масштабування "багатошарового співробітництва та модульних комбінацій". У цій статті основна увага приділяється масштабуванню, яке ґрунтується на паралельних обчисленнях.

Паралельні обчислення в ланцюзі, зосереджені на паралельному виконанні транзакцій/інструкцій всередині блоку. За механізмом паралелізму, способи масштабування можна поділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію. Паралельність поступово стає дедалі тоншою, інтенсивність паралелізму зростає, а складність планування також зростає, ускладнюючи програмування та реалізацію.

• Паралельність на рівні облікового запису (Account-level): представляє проект Solana
• Об'єктний рівень паралелізму (Object-level): представляє проект Sui
• Рівень транзакцій (Transaction-level): представляє проєкт Monad, Aptos
• Виклик рівня/Мікро ВМ паралельно (Call-level / MicroVM): представляє проект MegaETH
• Паралелізм на рівні інструкцій (Instruction-level): представляє проект GatlingX

Позамережна асинхронна паралельна модель, що представлена системою агентів Actor, належить до іншої парадигми паралельних обчислень. Як міжланцюгова / асинхронна система обміну повідомленнями, кожен Агент є незалежно працюючим «агентським процесом», що використовує асинхронні повідомлення в паралельному режимі, керуючись подіями, без потреби в синхронізації та плануванні. Представлені проекти: AO, ICP, Cartesi та ін.

А відомі нам Rollup або рішення для масштабування за допомогою шардінгу є механізмами системного рівня, які не належать до паралельних обчислень всередині ланцюга. Вони реалізують масштабування шляхом «паралельного виконання кількох ланцюгів/виконавчих доменів», а не підвищення паралельності всередині одного блоку/віртуальної машини. Такі рішення для масштабування не є основною темою цієї статті, але ми все ж будемо використовувати їх для порівняння відмінностей у архітектурних концепціях.

Два, EVM-сумісний посилений ланцюг: прорив меж продуктивності в сумісності

Розвиток серійної обробної архітектури Ethereum досягнув стадії, на якій було проведено кілька спроб розширення, включаючи шардінг, Rollup, модульну архітектуру тощо, але вузькі місця в пропускній спроможності виконавчого рівня все ще не були принципово подолані. Проте, EVM та Solidity залишаються найпотужнішими платформами смарт-контрактів з найбільшою базою розробників та екосистемними потенціалами на сьогодні. Таким чином, EVM-системи паралельного підвищення ланцюга, які забезпечують баланс між екосистемною сумісністю та підвищенням виконавчої продуктивності, стають важливим напрямком у новому етапі розширення. Monad та MegaETH є найяскравішими проектами в цьому напрямку, які, починаючи з відкладеного виконання та розподілу стану, створюють архітектуру паралельної обробки EVM, спрямовану на сценарії з високою конкуренцією та високою пропускною здатністю.

Аналіз механізму паралельних обчислень Monad

Monad — це високопродуктивна Layer1 блокчейн, переосмислена для віртуальної машини Ethereum, яка базується на основній парадигмі паралельної обробки (Pipelining), з асинхронним виконанням на рівні консенсусу (Asynchronous Execution) та оптимістичним паралельним виконанням (Optimistic Parallel Execution) на рівні виконання. Крім того, на рівні консенсусу та зберігання Monad відповідно впроваджує високопродуктивний BFT протокол (MonadBFT) та спеціалізовану систему бази даних (MonadDB), забезпечуючи оптимізацію від початку до кінця.

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

Pipelining є основною концепцією паралельного виконання Monad. Її ключова ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів та паралельній обробці цих етапів, що формує тривимірну конвейерну архітектуру. Кожен етап виконується в незалежних потоках або ядрах, що реалізує паралельну обробку між блоками, зрештою досягаючи підвищення пропускної здатності та зменшення затримок. Ці етапи включають: пропозицію транзакцій (Propose), досягнення консенсусу (Consensus), виконання транзакцій (Execution) та подання блоків (Commit).

Асинхронне виконання: консенсус - асинхронне декомпонування виконання

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

Основний дизайн:

• Процес консенсусу відповідає лише за впорядкування транзакцій, не виконує логіку контракту.
• Процес виконання асинхронно запускається після завершення консенсусу.
• Після завершення консенсусу негайно переходьте до процесу консенсусу наступного блоку, не чекаючи на виконання.

Оптимістичне паралельне виконання：乐观并行执行

Традиційний Ethereum використовує строгий послідовний модель для виконання транзакцій, щоб уникнути конфліктів станів. А Monad застосовує стратегію «оптимістичного паралельного виконання», що значно підвищує швидкість обробки транзакцій.

Механізм виконання:

• Monad буде оптимістично паралельно виконувати всі транзакції, припускаючи, що більшість транзакцій не мають конфліктів стану.
• Одночасно працює "детектор конфліктів", щоб контролювати, чи доступали транзакції до одного й того ж стану.
• Якщо виявлено конфлікт, конфліктні транзакції будуть серійно повторно виконані для забезпечення коректності стану.

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

Аналіз механізму паралельних обчислень MegaETH

На відміну від позиціонування Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може бути як незалежним L1 публічним блокчейном, так і посиленням виконання на Ethereum або модульним компонентом. Його основна мета проєкту полягає в тому, щоб ізолювати логіку облікових записів, виконавче середовище та стан, розклавши їх на найменші одиниці, які можуть бути незалежно заплановані, щоб досягти високої пропускної здатності виконання в ланцюзі та низької затримки відповіді. Ключова інновація MegaETH полягає в: архітектурі Micro-VM + State Dependency DAG (орієнтований ациклічний граф залежностей стану) та модульному механізмі синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "потокову обробку в ланцюзі".

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

MegaETH впроваджує модель виконання «один мікро-віртуальний комп'ютер на кожен обліковий запис», «потоковий» виконувальний контекст, що забезпечує найменший ізольований елемент для паралельного планування. Ці ВМ спілкуються між собою через асинхронні повідомлення, а не через синхронні виклики, що дозволяє великій кількості ВМ виконуватись незалежно та зберігатись окремо, природно забезпечуючи паралелізм.

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

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

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

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

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

MegaETH обрала шлях реконструкції: повністю абстрагувати рахунки та контракти в незалежну VM, звільняючи надзвичайний потенціал паралелізму через асинхронне виконання та планування. Теоретично, паралельний ліміт MegaETH вищий, але контролювати складність важче, більше схоже на суперрозподілену операційну систему в рамках ідеї Ethereum.

Дизайнерські концепції Monad та MegaETH значно відрізняються від шардінгу (Sharding): шардінг розбиває блокчейн на кілька незалежних підланцюгів, кожен з яких відповідає за частину транзакцій та стану, руйнуючи обмеження однорангового ланцюга у розширенні на рівні мережі; в той же час Monad та MegaETH зберігають цілісність однорангового ланцюга, лише горизонтально розширюючись на рівні виконання, досягаючи оптимізації паралельного виконання всередині однорангового ланцюга для покращення продуктивності. Обидва вони представляють два напрямки в розширенні блокчейн-інфраструктури: вертикальне посилення та горизонтальне розширення.

Проекти паралельних обчислень, такі як Monad і MegaETH, головним чином зосереджуються на оптимізації пропускної спроможності, ставлячи за мету підвищення TPS у межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів за допомогою відкладеного виконання та мікровіртуальної архітектури. Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як «Rollup Mesh». Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), забезпечуючи багато віртуальних машин (EVM та Wasm) та інтегруючи передові технології, такі як нульові знання (ZK) та середовище довіреного виконання (TEE).

Аналіз паралельного обчислювального механізму Rollup Mesh:

1. Обробка асинхронного конвеєра в повному життєвому циклі: Pharos декомпонує різні етапи угоди та використовує асинхронний спосіб обробки, що дозволяє кожному етапу виконуватись незалежно та паралельно, тим самим підвищуючи загальну ефективність обробки.
2. Паралельне виконання двох віртуальних машин: Pharos підтримує дві віртуальні машинні середовища - EVM та WASM, що дозволяє розробникам обирати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й підвищує обробну здатність транзакцій завдяки паралельному виконанню.
3. Спеціалізовані мережі (SPN): SPN є ключовим компонентом архітектури Pharos, подібно до модульних підмереж, спеціально призначених для обробки конкретних типів завдань або застосувань. Завдяки SPN, Pharos може реалізувати динамічний розподіл ресурсів та паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
4. Модульна консенсусна система та механізм повторного стейкінгу: Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу, і реалізує безпечний обмін та інтеграцію ресурсів між основною мережею та SPNs через протокол повторного стейкінгу.

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