Пейзаж паралельних обчислень у 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

Зовнішня асинхронна конкурентна модель, що представляється системою агентів Actor (Agent / Actor Model), яка належить до іншої парадигми паралельних обчислень, як міжланкова/асинхронна система повідомлень (несинхронна модель блокчейну), кожен агент виступає в ролі незалежно працюючого "агентського процесу", асинхронні повідомлення в паралельному режимі, подієво-орієнтовані, без необхідності синхронізації, представлені проекти включають AO, ICP, Cartesi та ін.

А відомі нам Rollup або рішення для розширення через шардінг належать до механізмів системної рівноваги і не є внутрішнім паралельним обчисленням. Вони реалізують розширення через "паралельний запуск кількох ланцюгів/виконавчих доменів", а не через підвищення паралелізму всередині одного блоку/віртуальної машини. Ці рішення для розширення не є основною темою даної статті, але ми все ж будемо використовувати їх для порівняння архітектурних концепцій.

Два, EVM-система паралельного посилення ланцюга: прорив меж продуктивності в рамках сумісності

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

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

Monad є високопродуктивною Layer1 блокчейном, переосмисленим для Ethereum Virtual Machine (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 публічна блокчейн-мережа, так і як рівень підвищення виконання на 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 впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу(, такі як PBFT, PoS, PoA), і реалізує безпечний обмін та інтеграцію ресурсів між основною мережею та SPNs через протокол повторної ставлення(Restaking).

Крім того, Pharos за допомогою багатовершинних дерев Меркле, диференційного кодування (Delta Encoding), адресації версій (Versioned Addressing) та технології ADS Pushdown (ADS Pushdown), реконструює модель виконання знизу зберігаючого двигуна, представляє рідний блокчейн високопродуктивний зберігаючий двигун Pharos Store, досягаючи високої пропускної здатності, низької затримки та сильної перевірки.