Пейзаж 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 є основною ідеєю паралельного виконання Monad, її основна ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує тривимірну архітектуру конвеєра, де кожен етап працює в незалежних потоках або ядрах, реалізуючи паралельну обробку через блоки, в кінцевому підсумку досягаючи підвищення пропускної здатності та зменшення затримки. Ці етапи включають: пропозиція транзакцій (Propose), досягнення консенсусу (Consensus), виконання транзакцій (Execution) та подачу блоку (Commit).
Асинхронне виконання: консенсус - асинхронне декорування виконання
У традиційних блокчейнах консенсус і виконання транзакцій зазвичай є синхронними процесами, і така серійна модель серйозно обмежує продуктивність. Monad реалізував асинхронний консенсус, асинхронне виконання та асинхронне зберігання через "асинхронне виконання". Це суттєво зменшує час блоку (block time) і затримку підтвердження, роблячи систему більш гнучкою, процеси обробки більш деталізованими та використання ресурсів більш ефективним.
Основний дизайн:
Процес консенсусу (шар консенсусу) відповідальний лише за впорядкування транзакцій, а не за виконання логіки контракту.
Процес виконання (виконавчий рівень) запускається асинхронно після завершення консенсусу.
Після завершення консенсусу відразу переходьте до процесу консенсусу наступного блоку, не чекаючи завершення виконання.
Оптимістичне паралельне виконання
Традиційний Ethereum використовує строгій послідовній моделі для виконання транзакцій, щоб уникнути конфліктів стану. Натомість Monad застосовує стратегію "оптимістичного паралельного виконання", що значно підвищує швидкість обробки транзакцій.
Механізм виконання:
Monad оптимістично виконує всі транзакції паралельно, припускаючи, що більшість транзакцій не мають стану конфлікту.
Одночасно запустіть "Детектор конфліктів (Conflict Detector))" для моніторингу того, чи доступали транзакції один і той же стан (наприклад, конфлікти читання/запису).
Якщо виявлено конфлікт, конфліктні транзакції будуть серіалізовані та повторно виконані, щоб забезпечити правильність стану.
Monad обрав сумісний шлях: якомога менше змінюючи правила EVM, під час виконання реалізуючи паралелізм за рахунок затримки запису стану та динамічного виявлення конфліктів, більше схожий на продуктивну версію Ethereum, з хорошою зрілістю і легкістю реалізації міграції екосистеми EVM, виступаючи як паралельний прискорювач світу EVM.
Аналіз механізму паралельних обчислень MegaETH
На відміну від позиціонування L1 Monada, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може виступати як незалежна L1 публічна ланцюг або як рівень посилення виконання (Execution Layer) на Ethereum чи модульний компонент. Його основна мета проектування полягає в тому, щоб ізолювати логіку облікових записів, середовище виконання та стан, розкладаючи їх на незалежно плановані мінімальні одиниці для досягнення високої конкурентоспроможності виконання в межах ланцюга та низької затримки відповіді. Ключова інновація, запропонована MegaETH, полягає в архітектурі Micro-VM + 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, подібно до модульних підмереж, які спеціально призначені для обробки певних типів завдань або застосувань. Завдяки SPNs Pharos може реалізувати динамічний розподіл ресурсів і паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
Модульний консенсус і повторне ставлення (Modular Consensus & Restaking): Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу (такі як PBFT, PoS, PoA), і через протокол повторного ставлення (Restaking) забезпечує безпечне спільне використання та інтеграцію ресурсів між основною мережею та SPNs.
Крім того, Pharos за допомогою технологій багатоверсійного дерева Меркла, диференційного кодування (Delta Encoding), адресації версій (Versioned Addressing) та виштовхування ADS (ADS Pushdown) реконструював модель виконання на основі зберігання, запустивши рідний блокчейн високопродуктивного зберігання Pharos Store, що забезпечує високу пропускну спроможність, низьку затримку та сильну перевіряємість обробки на ланцюгу.
В цілому, Phar
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
7
Поділіться
Прокоментувати
0/400
TrustlessMaximalist
· 13год тому
Знову говорять про розширення. Що тут обговорювати?
Переглянути оригіналвідповісти на0
SolidityStruggler
· 13год тому
Знову йдеться про розширення, усі L1 використовують паралельне вирішення.
Переглянути оригіналвідповісти на0
SchrodingerProfit
· 13год тому
Блокчейн насправді хоче бути таким швидким? Чотири варіанти заплутали...
Переглянути оригіналвідповісти на0
DisillusiionOracle
· 13год тому
Не маємо грошей, не маємо масштабів.
Переглянути оригіналвідповісти на0
TokenomicsTherapist
· 13год тому
Знову тут грають у теорію
Переглянути оригіналвідповісти на0
HalfIsEmpty
· 13год тому
Чия родина вирішила тріангульовану неможливість, я відразу all in
Паралельні обчислення в Web3: порівняння п'яти парадигм масштабування та високопродуктивних ланцюгів на основі EVM
Пейзаж 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 є основною ідеєю паралельного виконання Monad, її основна ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує тривимірну архітектуру конвеєра, де кожен етап працює в незалежних потоках або ядрах, реалізуючи паралельну обробку через блоки, в кінцевому підсумку досягаючи підвищення пропускної здатності та зменшення затримки. Ці етапи включають: пропозиція транзакцій (Propose), досягнення консенсусу (Consensus), виконання транзакцій (Execution) та подачу блоку (Commit).
Асинхронне виконання: консенсус - асинхронне декорування виконання
У традиційних блокчейнах консенсус і виконання транзакцій зазвичай є синхронними процесами, і така серійна модель серйозно обмежує продуктивність. Monad реалізував асинхронний консенсус, асинхронне виконання та асинхронне зберігання через "асинхронне виконання". Це суттєво зменшує час блоку (block time) і затримку підтвердження, роблячи систему більш гнучкою, процеси обробки більш деталізованими та використання ресурсів більш ефективним.
Основний дизайн:
Оптимістичне паралельне виконання
Традиційний Ethereum використовує строгій послідовній моделі для виконання транзакцій, щоб уникнути конфліктів стану. Натомість Monad застосовує стратегію "оптимістичного паралельного виконання", що значно підвищує швидкість обробки транзакцій.
Механізм виконання:
Monad обрав сумісний шлях: якомога менше змінюючи правила EVM, під час виконання реалізуючи паралелізм за рахунок затримки запису стану та динамічного виявлення конфліктів, більше схожий на продуктивну версію Ethereum, з хорошою зрілістю і легкістю реалізації міграції екосистеми EVM, виступаючи як паралельний прискорювач світу EVM.
Аналіз механізму паралельних обчислень MegaETH
На відміну від позиціонування L1 Monada, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може виступати як незалежна L1 публічна ланцюг або як рівень посилення виконання (Execution Layer) на Ethereum чи модульний компонент. Його основна мета проектування полягає в тому, щоб ізолювати логіку облікових записів, середовище виконання та стан, розкладаючи їх на незалежно плановані мінімальні одиниці для досягнення високої конкурентоспроможності виконання в межах ланцюга та низької затримки відповіді. Ключова інновація, запропонована MegaETH, полягає в архітектурі Micro-VM + 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:
Крім того, Pharos за допомогою технологій багатоверсійного дерева Меркла, диференційного кодування (Delta Encoding), адресації версій (Versioned Addressing) та виштовхування ADS (ADS Pushdown) реконструював модель виконання на основі зберігання, запустивши рідний блокчейн високопродуктивного зберігання Pharos Store, що забезпечує високу пропускну спроможність, низьку затримку та сильну перевіряємість обробки на ланцюгу.
В цілому, Phar