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

Один. Паралельні обчислення: новий напрямок масштабування блокчейну

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

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

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