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

Один. Вічна тема розширення блокчейну

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

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

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

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

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

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

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

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

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

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

На відміну від позиціонування L1 Monada, 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 мають значно відмінні концепції дизайну від шардінгу (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, PoS, PoA), та через повторний стейкінг