Панорама паралельних обчислень у Web3: найкраще рішення для рідного масштабування?
Трикутник «неможливості» блокчейну (Blockchain Trilemma) «безпека», «децентралізація», «масштабованість» вказує на суттєві компроміси при проектуванні блокчейн-систем, а саме - блокчейн-проекти важко досягти одночасно «максимальної безпеки, участі всіх та швидкої обробки». Щодо вічної теми «масштабованості», на сьогоднішній день основні рішення для масштабування блокчейну на ринку поділяються за парадигмами, включаючи:
Виконання розширеної масштабованості: підвищення виконавчих можливостей на місці, наприклад, паралельне виконання, GPU, багатоядерність
Ізольоване розширення статусу: горизонтальне розділення статусу / Shard, наприклад, шардінг, UTXO, багатопідмережі
Зовнішнє масштабування за допомогою аутсорсингу: виконання відбувається поза ланцюгом, наприклад, Rollup, Coprocessor, 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：механізм паралельного виконання з багатоступеневим конвеєром
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) для кожного облікового запису», «потоковою» середовищем виконання, що забезпечує мінімальну одиницю ізоляції для паралельного планування. Ці віртуальні комп'ютери спілкуються між собою через асинхронне повідомлення (Asynchronous Messaging), а не через синхронні виклики, що дозволяє великій кількості віртуальних комп'ютерів працювати незалежно один від одного, незалежно зберігати дані та природно паралельно.
State Dependency DAG：механізм планування на основі графа залежностей
MegaETH побудував систему планування DAG, що базується на відносинах доступу до стану рахунків, яка в реальному часі підтримує глобальну залежність (Dependency Graph). Кожна транзакція модифікує певні рахунки, читає певні рахунки, все це моделюється як залежності. Транзакції без конфліктів можуть виконуватись паралельно, а транзакції з залежностями будуть заплановані на серійну або відкладену обробку відповідно до топологічного порядку. Залежність граф гарантує узгодженість стану та уникнення повторних записів під час паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними (нерекурсивним виконанням), і при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
Отже, MegaETH руйнує традиційну модель однониткової машини стану EVM, реалізуючи мікровіртуальну машину в упаковці на основі облікових записів, за допомогою графа залежностей стану для планування транзакцій і замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це паралельна обчислювальна платформа, яка була переосмислена з усіх вимірів: «структура облікового запису → архітектура планування → процес виконання», що пропонує нові парадигми для побудови системи наступного покоління з високою продуктивністю на блокчейні.
MegaETH обрала шлях реконструкції: повністю абстрагуючи облікові записи та контракти в незалежну VM, через асинхронне виконання та планування, щоб вивільнити максимальний потенціал паралельності. Теоретично, паралельний ліміт MegaETH вищий, але також складніше контролювати складність, більше нагадуючи супердистрибутивну операційну систему на основі концепції Ethereum.
Monad та MegaETH мають значно різні концепції дизайну в порівнянні з шардінгом: шардінг горизонтально розділяє блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій та стану, що дозволяє обійти обмеження одноланкової архітектури на рівні мережі; тоді як 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, подібно до модульних підмереж, спеціально призначених для обробки певних типів завдань або додатків. Через SPN
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Панорама паралельних обчислень Web3: від сумісності з EVM до інновацій в розширенні Rollup Mesh
Панорама паралельних обчислень у Web3: найкраще рішення для рідного масштабування?
Трикутник «неможливості» блокчейну (Blockchain Trilemma) «безпека», «децентралізація», «масштабованість» вказує на суттєві компроміси при проектуванні блокчейн-систем, а саме - блокчейн-проекти важко досягти одночасно «максимальної безпеки, участі всіх та швидкої обробки». Щодо вічної теми «масштабованості», на сьогоднішній день основні рішення для масштабування блокчейну на ринку поділяються за парадигмами, включаючи:
Рішення з розширення блокчейну включають: паралельні обчислення в ланцюгу, Rollup, шардінг, модулі DA, модульну структуру, систему Actor, стиснення zk-доказів, Stateless архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, що є «багаторівневою координацією, модульною комбінацією» повною системою розширення. У цій статті особливу увагу приділено основному методу розширення на основі паралельних обчислень.
Внутрішня паралельна обробка (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：механізм паралельного виконання з багатоступеневим конвеєром
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) для кожного облікового запису», «потоковою» середовищем виконання, що забезпечує мінімальну одиницю ізоляції для паралельного планування. Ці віртуальні комп'ютери спілкуються між собою через асинхронне повідомлення (Asynchronous Messaging), а не через синхронні виклики, що дозволяє великій кількості віртуальних комп'ютерів працювати незалежно один від одного, незалежно зберігати дані та природно паралельно.
State Dependency DAG：механізм планування на основі графа залежностей
MegaETH побудував систему планування DAG, що базується на відносинах доступу до стану рахунків, яка в реальному часі підтримує глобальну залежність (Dependency Graph). Кожна транзакція модифікує певні рахунки, читає певні рахунки, все це моделюється як залежності. Транзакції без конфліктів можуть виконуватись паралельно, а транзакції з залежностями будуть заплановані на серійну або відкладену обробку відповідно до топологічного порядку. Залежність граф гарантує узгодженість стану та уникнення повторних записів під час паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними (нерекурсивним виконанням), і при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
Отже, MegaETH руйнує традиційну модель однониткової машини стану EVM, реалізуючи мікровіртуальну машину в упаковці на основі облікових записів, за допомогою графа залежностей стану для планування транзакцій і замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це паралельна обчислювальна платформа, яка була переосмислена з усіх вимірів: «структура облікового запису → архітектура планування → процес виконання», що пропонує нові парадигми для побудови системи наступного покоління з високою продуктивністю на блокчейні.
MegaETH обрала шлях реконструкції: повністю абстрагуючи облікові записи та контракти в незалежну VM, через асинхронне виконання та планування, щоб вивільнити максимальний потенціал паралельності. Теоретично, паралельний ліміт MegaETH вищий, але також складніше контролювати складність, більше нагадуючи супердистрибутивну операційну систему на основі концепції Ethereum.
Monad та MegaETH мають значно різні концепції дизайну в порівнянні з шардінгом: шардінг горизонтально розділяє блокчейн на кілька незалежних підланок (шарди), кожна з яких відповідає за частину транзакцій та стану, що дозволяє обійти обмеження одноланкової архітектури на рівні мережі; тоді як Monad та MegaETH зберігають цілісність одноланкової архітектури, лише горизонтально розширюючи виконання, і в межах одноланкової архітектури досягають максимального паралельного виконання для покращення продуктивності. Обидва представляють два напрямки в шляху розширення блокчейну: вертикальне зміцнення та горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad і MegaETH, переважно зосереджені на оптимізації пропускної спроможності з основною метою підвищення TPS в межах блокчейну, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через відкладене виконання (Deferred Execution) та мікровіртуальні машини (Micro-VM). Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як «Rollup Mesh». Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), забезпечує середовище з кількома віртуальними машинами (EVM та Wasm) та інтегрує передові технології, такі як нульові знання (ZK) та довірені середовища виконання (TEE).
Аналіз механізму паралельних обчислень Rollup Mesh: