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

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

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

• Виконання вдосконаленого масштабування: підвищення виконувальних можливостей на місці, наприклад, паралельна обробка, 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 паралельно ( Виклик рівня / MicroVM ): представляє проект MegaETH
• Інструкційний рівень ( Instruction-level ): представляє проект GatlingX

Зовнішня асинхронна паралельна модель, представлена системою агентів Actor (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

Відрізняючись від定位 Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може діяти як незалежна L1 публічна блокчейн-мережа, так і як шар підвищення виконання на Ethereum (Execution Layer) або модульний компонент. Його основною метою є ізоляція логіки облікового запису, середовища виконання та стану в окремі одиниці, які можуть бути незалежно заплановані, щоб забезпечити високу паралельну виконуваність та низьку затримку відповіді в межах ланцюга. Ключова інновація, запропонована MegaETH, полягає в: архітектурі Micro-VM + State Dependency DAG(орієнтований ациклічний граф залежності стану) та модульному механізмі синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "внутрішню потоковість".

Micro-VM(мікровіртуальна машина)архітектура: аккаунт як потік

MegaETH впроваджує модель виконання "мікровіртуальної машини для кожного облікового запису (Micro-VM)", яка "потоково" організовує середовище виконання, забезпечуючи мінімальну одиницю ізоляції для паралельного планування. Ці віртуальні машини спілкуються між собою за допомогою асинхронного повідомлення (Asynchronous Messaging), а не синхронного виклику, що дозволяє великій кількості віртуальних машин незалежно виконуватися та зберігатися, природно паралельно.

DAG залежності стану: механізм планування, що базується на графі залежностей

MegaETH побудував систему планування на основі графа залежностей DAG, що базується на відносинах доступу до стану облікового запису. Система в реальному часі підтримує глобальний граф залежностей (Dependency Graph ), кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється як залежності. Безконфліктні транзакції можуть виконуватись паралельно, транзакції з залежностями будуть плануватись та сортуватись послідовно або відкладено відповідно до топологічного порядку. Граф залежностей забезпечує узгодженість стану та недопущення повторного запису під час процесу паралельного виконання.

Асинхронне виконання та механізм зворотного виклику

MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними ( ) нерекурсивного виконання, а при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек дзвінків розгортається в асинхронний графік дзвінків (Call Graph); Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.

У підсумку, 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 впроваджує гнучкі