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

I. Вступ

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

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

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

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

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

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) та через повторне