Панорама Web3 паралельних обчислень: найкраще рішення для рідного масштабування?
Один, фон: Вічна тема розширення блокчейну
"Трикутник неможливості" блокчейну (Blockchain Trilemma) "безпека", "децентралізація", "масштабованість" вказує на сутнісні компроміси у проектуванні системи блокчейн, а саме, що блокчейн-проєкти важко реалізувати одночасно з "максимальною безпекою, доступом для всіх, швидкою обробкою". Щодо "масштабованості", цієї вічної теми, на сьогоднішній день існуючі основні рішення для розширення блокчейнів можна класифікувати за парадигмами, включаючи:
Виконання покращеного масштабування: підвищення виконувальної здатності на місці, наприклад, паралельна обробка, GPU, багатоядерність.
Ізоляція стану для масштабування: горизонтальне розділення стану / Шард, наприклад, шардінг, 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: механізм паралельного виконання в багатоступеневому конвеєрі
Пайплайнинг — це основна концепція паралельного виконання монади. Основна ідея полягає в розділенні процесу виконання в блокчейні на кілька незалежних етапів та їх паралельній обробці, що формує тривимірну архітектуру конвеєра. Кожен етап працює на незалежному потоці або ядрі, що забезпечує паралельну обробку через блоки, в результаті чого досягається підвищення пропускної здатності та зниження затримок. Ці етапи включають: пропозицію транзакцій (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), а не синхронні виклики, що дозволяє великій кількості ВМ незалежно виконуватись та зберігатись, природно паралельно.
State Dependency DAG: механізм планування на основі графів залежностей
MegaETH побудував систему планування DAG, що базується на відносинах доступу до стану облікових записів, система в реальному часі підтримує глобальний граф залежностей (Dependency Graph), кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється як залежності. Транзакції без конфліктів можуть виконуватися паралельно, а транзакції з залежностями будуть плануватися послідовно або відкладено за топологічним порядком. Граф залежностей забезпечує узгодженість стану та неповторне записування під час процесу паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними (нерекурсивним виконанням), і при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
Отже, MegaETH порушує традиційну модель однониткового стану EVM, реалізуючи мікровіртуальні машини в упаковці за одиницею рахунку, здійснюючи планування транзакцій за допомогою графа залежностей стану та замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це платформа паралельних обчислень, яка була перепроектована з "структури рахунку → архітектури планування → процесу виконання" в усіх вимірах, надаючи парадигмальний новий підхід для побудови систем наступного покоління з високою продуктивністю на ланцюгу.
MegaETH обрала шлях реконструкції: повністю абстрагує облікові записи та контракти в незалежну VM, звільняючи надзвичайний потенціал паралельного виконання за допомогою асинхронного виконання. Теоретично, паралельний ліміт MegaETH вищий, але також складніше контролювати складність, більше схоже на суперрозподілену операційну систему в концепції Ethereum.
Monad та MegaETH мають значні відмінності в своїх дизайнерських концепціях порівняно з шардінгом (Sharding): шардінг розділяє блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій та стану, ламаючи обмеження одноланкової архітектури для розширення на рівні мережі; тоді як Monad та MegaETH зберігають цілісність одноланкової архітектури, лише горизонтально розширюючи на рівні виконання та оптимізуючи паралельне виконання всередині одноланкової архітектури для покращення продуктивності. Обидва вони представляють дві різні напрямки у шляху розширення блокчейну: вертикальне зміцнення та горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної здатності з метою підвищення TPS в межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через відкладене виконання (Deferred Execution) та архітектуру мікровіртуальної машини (Micro-VM). Pharos Network, як модульна, повноцінна паралельна мережа L1 блокчейну, має основний механізм паралельних обчислень, що називається "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), підтримує багатоваріантне віртуальне середовище (EVM та Wasm) та інтегрує такі передові технології, як нульові знання (ZK) та довірене середовище виконання (TEE).
Повний життєвий цикл асинхронної конвеєрної обробки (Full Lifecycle Asynchronous Pipelining): Pharos розділяє різні етапи транзакції (такі як консенсус, виконання, зберігання) і використовує асинхронний спосіб обробки, що дозволяє кожному етапу працювати незалежно та паралельно, що підвищує загальну ефективність обробки.
Паралельне виконання двох віртуальних машин (Dual VM Parallel Execution): Pharos підтримує дві віртуальні середовища EVM та WASM, що дозволяє розробникам обирати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не лише підвищує гнучкість системи, але й покращує здатність обробки транзакцій завдяки паралельному виконанню.
Спеціалізовані мережі (SPNs): SPNs є ключовими компонентами архітектури Pharos, подібними до модульних підмереж, спеціально призначеними для обробки певних типів завдань або застосувань. Завдяки SPNs, Pharos може реалізувати динамічний розподіл ресурсів і паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
Модульний консенсус і повторне ставлення (Modular Consensus & Restaking): Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу (такі як PBFT, PoS, PoA) і через
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
15 лайків
Нагородити
15
3
Поділіться
Прокоментувати
0/400
AirdropHunterZhang
· 21год тому
Електрика занадто дорога, All in криптосвіт краще, ніж запустити кодовий майнінг.
Переглянути оригіналвідповісти на0
MidnightSeller
· 21год тому
Випив кілька пляшок пива, відчуваю, що rollup також може врятувати світ.
Паралельні обчислення Web3: аналіз п'яти основних технологічних напрямів та прориви в продуктивності
Панорама Web3 паралельних обчислень: найкраще рішення для рідного масштабування?
Один, фон: Вічна тема розширення блокчейну
"Трикутник неможливості" блокчейну (Blockchain Trilemma) "безпека", "децентралізація", "масштабованість" вказує на сутнісні компроміси у проектуванні системи блокчейн, а саме, що блокчейн-проєкти важко реалізувати одночасно з "максимальною безпекою, доступом для всіх, швидкою обробкою". Щодо "масштабованості", цієї вічної теми, на сьогоднішній день існуючі основні рішення для розширення блокчейнів можна класифікувати за парадигмами, включаючи:
Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модуль DA, модульну структуру, систему Actor, стиснення zk-доказів, безстанну архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, являючи собою "багаторівневу координацію, модульне поєднання" повну систему розширення. У цій статті особлива увага приділяється розширенню, що базується на паралельних обчисленнях.
Внутрішній паралелізм (intra-chain parallelism), зосереджений на паралельному виконанні транзакцій / інструкцій усередині блокчейна. За механізмами паралелізму, способи масштабування можна розділити на п’ять великих категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію, з поступовим зменшенням паралельних часток, зростанням інтенсивності паралелізму, а також зростанням складності планування, складності програмування та труднощів реалізації.
Зовнішня асинхронна модель паралелізму, представлена системою інтелектуальних агентів (модель агентів/акторів), яка належить до іншої парадигми паралельних обчислень. Як кросчейн/асинхронна система повідомлень (не синхронізована модель блокчейну), кожен агент виступає як незалежно працюючий "інтелектуальний процес", асинхронно обробляючи повідомлення в паралельному режимі, керуючи подіями без потреби в синхронізації. Представлені проекти: 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: механізм паралельного виконання в багатоступеневому конвеєрі
Пайплайнинг — це основна концепція паралельного виконання монади. Основна ідея полягає в розділенні процесу виконання в блокчейні на кілька незалежних етапів та їх паралельній обробці, що формує тривимірну архітектуру конвеєра. Кожен етап працює на незалежному потоці або ядрі, що забезпечує паралельну обробку через блоки, в результаті чого досягається підвищення пропускної здатності та зниження затримок. Ці етапи включають: пропозицію транзакцій (Propose), досягнення консенсусу (Consensus), виконання транзакцій (Execution) та подачу блоку (Commit).
Асинхронне виконання: консенсус - виконання асинхронного декуплінгу
У традиційних ланцюгах консенсус і виконання транзакцій зазвичай є синхронними процесами, і ця серійна модель суттєво обмежує можливості масштабування. Monad реалізує асинхронний консенсусний рівень, асинхронний рівень виконання та асинхронне зберігання через "асинхронне виконання". Це суттєво зменшує час блоку (block time) та затримку підтвердження, роблячи систему більш гнучкою, процеси обробки більш деталізованими, а використання ресурсів більш ефективним.
Основний дизайн:
Оптимістичне паралельне виконання
Традиційний Ethereum використовує сувору послідовну модель для виконання транзакцій, щоб уникнути конфліктів стану. Натомість Monad використовує стратегію "оптимістичного паралельного виконання", що значно підвищує швидкість обробки транзакцій.
Механізм виконання:
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), а не синхронні виклики, що дозволяє великій кількості ВМ незалежно виконуватись та зберігатись, природно паралельно.
State Dependency DAG: механізм планування на основі графів залежностей
MegaETH побудував систему планування DAG, що базується на відносинах доступу до стану облікових записів, система в реальному часі підтримує глобальний граф залежностей (Dependency Graph), кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється як залежності. Транзакції без конфліктів можуть виконуватися паралельно, а транзакції з залежностями будуть плануватися послідовно або відкладено за топологічним порядком. Граф залежностей забезпечує узгодженість стану та неповторне записування під час процесу паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними (нерекурсивним виконанням), і при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
Отже, MegaETH порушує традиційну модель однониткового стану EVM, реалізуючи мікровіртуальні машини в упаковці за одиницею рахунку, здійснюючи планування транзакцій за допомогою графа залежностей стану та замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це платформа паралельних обчислень, яка була перепроектована з "структури рахунку → архітектури планування → процесу виконання" в усіх вимірах, надаючи парадигмальний новий підхід для побудови систем наступного покоління з високою продуктивністю на ланцюгу.
MegaETH обрала шлях реконструкції: повністю абстрагує облікові записи та контракти в незалежну VM, звільняючи надзвичайний потенціал паралельного виконання за допомогою асинхронного виконання. Теоретично, паралельний ліміт MegaETH вищий, але також складніше контролювати складність, більше схоже на суперрозподілену операційну систему в концепції Ethereum.
Monad та MegaETH мають значні відмінності в своїх дизайнерських концепціях порівняно з шардінгом (Sharding): шардінг розділяє блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій та стану, ламаючи обмеження одноланкової архітектури для розширення на рівні мережі; тоді як Monad та MegaETH зберігають цілісність одноланкової архітектури, лише горизонтально розширюючи на рівні виконання та оптимізуючи паралельне виконання всередині одноланкової архітектури для покращення продуктивності. Обидва вони представляють дві різні напрямки у шляху розширення блокчейну: вертикальне зміцнення та горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної здатності з метою підвищення TPS в межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через відкладене виконання (Deferred Execution) та архітектуру мікровіртуальної машини (Micro-VM). Pharos Network, як модульна, повноцінна паралельна мережа L1 блокчейну, має основний механізм паралельних обчислень, що називається "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), підтримує багатоваріантне віртуальне середовище (EVM та Wasm) та інтегрує такі передові технології, як нульові знання (ZK) та довірене середовище виконання (TEE).
Розбір механізму паралельних обчислень Rollup Mesh: