Панорамна карта паралельних обчислень 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
Модель асинхронної конкурентності поза ланцюгом, яка представлена системою агентів (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 публічна блокчейн-мережа або як шар підвищення виконання (Execution Layer) на Ethereum чи модульний компонент. Основною метою його проектування є розділення логіки облікового запису, середовища виконання та стану на незалежно плановані мінімальні одиниці, щоб забезпечити високу пропускну здатність виконання в ланцюзі та низьку затримку відповіді. Ключовою інновацією, запропонованою MegaETH, є: архітектура Micro-VM + State Dependency DAG (орієнтований ациклічний граф залежності стану) та модульний механізм синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "потоковість в ланцюзі".
Архітектура Micro-VM (мікровіртуальної машини): обліковий запис як потік
MegaETH запроваджує модель виконання «мікровіртуальних машин (Micro-VM) для кожного облікового запису», яка «потоково» організує середовище виконання, забезпечуючи мінімальну одиницю ізоляції для паралельного планування. Ці ВМ спілкуються між собою через асинхронне повідомлення, а не через синхронні виклики, що дозволяє великій кількості ВМ виконуватися незалежно та зберігатися окремо, що природно веде до паралелізму.
Залежність стану 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:
Повний життєвий цикл асинхронної конвеєрної обробки (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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Панорама паралельних обчислень Web3: 5 великих механізмів паралелізації від акаунту до рівня інструкцій
Панорамна карта паралельних обчислень Web3: найкраще рішення для нативного масштабування?
«Неможливий трикутник» блокчейну (Blockchain Trilemma) «безпека», «децентралізація», «масштабованість» вказує на суттєві компроміси в дизайні блокчейн-систем, а саме на те, що блокчейн-проекти важко реалізувати одночасно з «максимальною безпекою, доступністю для всіх, швидкою обробкою». Щодо «масштабованості», цієї вічної теми, нині основні рішення для розширення блокчейну на ринку розрізняються згідно з парадигмами, зокрема:
Рішення для розширення блокчейну включають: паралельні обчислення в ланцюзі, Rollup, шардінг, DA модулі, модульну структуру, систему Actor, стиснення zk-доказів, безстанну архітектуру тощо, охоплюючи виконання, стан, дані та структуру на кількох рівнях, є «повною системою розширення з багаторівневою співпрацею та модульним поєднанням». У цій статті основну увагу приділено розширенню, що базується на паралельних обчисленнях.
Внутрішня паралельна обробка (intra-chain parallelism), що зосереджується на паралельному виконанні транзакцій / інструкцій всередині блокчейну. Згідно з механізмом паралелізму, його способи масштабування можна розділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію. Згодом паралельна градація стає дедалі тоншою, інтенсивність паралелізму зростає, складність планування також зростає, а програмна складність і складність реалізації стають дедалі вищими.
Модель асинхронної конкурентності поза ланцюгом, яка представлена системою агентів (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 обрала сумісний шлях: мінімально змінюючи правила EVM, під час виконання реалізує паралельність за рахунок відкладеного запису стану та динамічного виявлення конфліктів, більше схожий на версію Ethereum з підвищеною продуктивністю, має високу зрілість, що полегшує міграцію екосистеми EVM, є паралельним прискорювачем світу EVM.
Аналіз механізму паралельних обчислень MegaETH
На відміну від позиціонування Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може використовуватися як незалежна L1 публічна блокчейн-мережа або як шар підвищення виконання (Execution Layer) на Ethereum чи модульний компонент. Основною метою його проектування є розділення логіки облікового запису, середовища виконання та стану на незалежно плановані мінімальні одиниці, щоб забезпечити високу пропускну здатність виконання в ланцюзі та низьку затримку відповіді. Ключовою інновацією, запропонованою MegaETH, є: архітектура Micro-VM + State Dependency DAG (орієнтований ациклічний граф залежності стану) та модульний механізм синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "потоковість в ланцюзі".
Архітектура Micro-VM (мікровіртуальної машини): обліковий запис як потік
MegaETH запроваджує модель виконання «мікровіртуальних машин (Micro-VM) для кожного облікового запису», яка «потоково» організує середовище виконання, забезпечуючи мінімальну одиницю ізоляції для паралельного планування. Ці ВМ спілкуються між собою через асинхронне повідомлення, а не через синхронні виклики, що дозволяє великій кількості ВМ виконуватися незалежно та зберігатися окремо, що природно веде до паралелізму.
Залежність стану 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: