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

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

• Виконання розширеної масштабованості: підвищення виконавчої здатності на місці, наприклад, паралельна обробка, GPU, багатоядерність
• Ізоляція стану розширення: горизонтальне розділення стану/Shard, наприклад, шардінг, UTXO, багатопідмережі
• Офлайн аутсорсинг масштабування: виконання поза ланцюгом, наприклад, Rollup, Копродуктор, 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

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

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

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

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

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

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

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

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

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

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

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

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

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