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

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

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

Зовнішня асинхронна конкурентна модель, представлена системою агентів (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) та затримку підтвердження, роблячи систему більш гнучкою, обробку процесів більш детальною та використання ресурсів більш ефективним.

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

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

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

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

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

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

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

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

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

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

В цілому, архітектура Rollup Mesh від Pharos забезпечує високу продуктивність паралельних обчислень завдяки модульному дизайну та асинхронному механізму обробки, Pharos робить