Панорама паралельних обчислень у Web3: найкраще рішення для рідного масштабування?
I. Огляд треку паралельних обчислень
"Неможливий трикутник" блокчейн-технологій (Blockchain Trilemma) "безпека", "децентралізація", "масштабованість" вказує на суттєві компроміси в проектуванні систем блокчейн, а саме, що проектам блокчейн важко досягти одночасно "максимальної безпеки, участі всіх і швидкої обробки". Щодо "масштабованості" - цієї вічної теми, на сьогоднішній день основні рішення для розширення блокчейн-технологій на ринку поділяються за парадигмами, зокрема:
Виконання посиленої масштабованості: підвищення виконавчих можливостей на місці, наприклад, паралельна обробка, GPU, багатоядерність
Ізоляція стану для масштабування: горизонтальне розділення стану/Shard, наприклад, шардінг, UTXO, багатопідмережі
Зовнішнє масштабування з делегуванням: перенесення виконання за межі ланцюга, наприклад, Rollup, Coprocessor, DA
Декуплюючий тип розширення: модульна архітектура, спільна робота, наприклад, модульний ланцюг, спільний сортувальник, Rollup Mesh
Асинхронне паралельне масштабування: модель актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопотокове асинхронне посилання
Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модулі DA, модульну структуру, систему Actor, стиснення zk-доказів, безстатеву архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, є "багаторівневою координацією, модульною комбінацією" повною системою розширення. Ця стаття зосереджена на основному способі розширення на основі паралельних обчислень.
Внутрішня паралельна обробка ( intra-chain parallelism ), зосереджується на паралельному виконанні транзакцій/інструкцій усередині блокчейну. За механізмами паралелізму, способи масштабування можна поділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію. Паралельна гранулярність стає дедалі тоншою, інтенсивність паралелізму зростає, складність планування також зростає, а складність програмування та труднощі реалізації також зростають.
Обліковий рівень паралельного(Обліковий рівень): представляє проект Solana
Об'єктний рівень ( Object-level ): представляє проект Sui
Торговий рівень (Transaction-level): представляє проєкт Monad, Aptos
Виклик рівня/МікроVM паралельно ( Виклик рівня / МікроVM ): представляє проект MegaETH
Інструкційний рівень ( Instruction-level ): представляє проект GatlingX
Модель асинхронної конкурентності поза ланцюгом, представлена системою агентів Actor (Agent / Actor Model), належить до іншої парадигми паралельних обчислень, як міжланцюгова/асинхронна система повідомлень ( ненормативна модель синхронізації блокчейнів ), кожен агент працює як незалежний "агентський процес", асинхронно обробляючи повідомлення в паралельному режимі, під керуванням подій, без необхідності в синхронізації, до таких проектів відносяться AO, ICP, Cartesi тощо.
А загальновідомі нам рішення Rollup або shards для розширення, є системними механізмами паралелізму, і не належать до паралельних обчислень всередині ланцюга. Вони реалізують розширення шляхом "паралельного виконання кількох ланцюгів/виконавчих доменів", а не шляхом підвищення паралельності всередині одного блоку/віртуальної машини. Такі рішення для розширення не є основною темою цього документа, але ми все ж використаємо їх для порівняння відмінностей в архітектурних концепціях.
Два, 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 Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може використовуватися як незалежна L1 публічна блокчейн-мережа або як рівень підвищення виконання на Ethereum (Execution Layer) або модульний компонент. Основна мета його дизайну полягає в розділенні логіки облікових записів, середовища виконання та стану на незалежно плановані мінімальні одиниці для досягнення високої конкурентоспроможності виконання в ланцюговій мережі та низької затримки реакції. Ключова інновація, запропонована 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 кожен виклик є асинхронним без блокування очікування; Стек дзвінків розгортається в асинхронний графік дзвінків (Call Graph); Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
У підсумку, MegaETH порушує традиційну модель однопотокового станового автомата EVM, реалізуючи мікровіртуальну машину на основі облікових записів, здійснюючи планування транзакцій через граф залежності станів та замінюючи синхронний викликовий стек асинхронним механізмом повідомлень. Це платформа паралельних обчислень, що була повністю переосмислена в вимірі "структура облікового запису → архітектура планування → процес виконання", що надає нові парадигми для розробки систем високої продуктивності наступного покоління в режимі онлайн.
MegaETH обрала шлях реконструкції: повністю абстрагувати облікові записи та контракти в незалежну VM, звільняючи надзвичайний потенціал паралельного виконання через асинхронне виконання. Теоретично, паралельний ліміт MegaETH вищий, але також важче контролювати складність, більше схоже на суперрозподілену операційну систему в рамках концепції Ethereum.
Дизайнерські концепції Monad і MegaETH суттєво відрізняються від шардінгу (Sharding): шардінг розділяє блокчейн на кілька незалежних дочірніх ланцюгів (шарди Shards), кожен з яких відповідає за частину транзакцій і стану, розриваючи обмеження однофункціонального ланцюга для масштабування на мережевому рівні; в той час як Monad і MegaETH зберігають цілісність однофункціонального ланцюга, лише розширюючи горизонтально на рівні виконання, оптимізуючи паралельне виконання всередині однофункціонального ланцюга для покращення продуктивності. Обидва представляють два напрямки в шляхах масштабування блокчейну: вертикальне зміцнення і горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної здатності з метою підвищення TPS в межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через затримане виконання (Deferred Execution) та мікровіртуальну машину (Micro-VM). Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, який називається "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), підтримуючи середовище з кількома віртуальними машинами (EVM та Wasm), а також інтегруючи передові технології, такі як нульові знання (ZK) та довірене середовище виконання (TEE).
Аналіз механізму паралельних обчислень Rollup Mesh:
Повний життєвий цикл асинхронної обробки конвеєра (Full Lifecycle Asynchronous Pipelining): Pharos декомпонує різні етапи транзакції (, такі як консенсус, виконання, зберігання ), і використовує асинхронний метод обробки, що дозволяє кожному етапу виконуватись незалежно та паралельно, що підвищує загальну ефективність обробки.
Двоїчне паралельне виконання віртуальних машин ( Dual VM Parallel Execution ): Pharos підтримує два середовища віртуальних машин – EVM та WASM, що дозволяє розробникам вибирати відповідне середовище виконання відповідно до їх потреб. Ця двовіртуальна архітектура не лише підвищує гнучкість системи, але й підвищує здатність обробки транзакцій через паралельне виконання.
Спеціальна обробка мережі ( SPNs ): SPNs є ключовими компонентами архітектури Pharos, подібними до модульних підмереж, спеціально призначеними для обробки специфічних типів завдань або застосунків. Через SPNs Pharos може реалізувати динамічне розподілення ресурсів і паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
Модульний консенсус і повторне ставлення(Modular Consensus & Restaking): Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу(, такі як PBFT, PoS, PoA), і забезпечує безпечне спільне використання та інтеграцію ресурсів між основною мережею та SPN через протокол повторного ставлення(Restaking).
Крім того, Pharos за допомогою багатоверсійного дерева Меркла, диференційного кодування (Delta Encoding), адресації версій (Versioned Addressing) та технології ADS-підсунути (ADS Pushdown), реконструює модель виконання на рівні сховища, запроваджуючи нативний блокчейн з високопродуктивним сховищем Pharos Store, що забезпечує високу пропускну спроможність, низьку затримку та сильну верифікацію можливостей обробки на ланцюгу.
В цілому, Rollup Mesh від Pharos
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
6
Поділіться
Прокоментувати
0/400
FloorPriceNightmare
· 22год тому
Купую відеокарту, якщо не куплю, рано чи пізно обдурюватимуть людей, як лохів.
Переглянути оригіналвідповісти на0
RooftopReserver
· 08-01 23:17
Розширення знову має нові трюки. Ще зранку, коли двері ліфта відкрилися, я побачив помилку.
Переглянути оригіналвідповісти на0
Fren_Not_Food
· 07-30 17:37
Яка користь від паралельних обчислень? Адже достатньо мати мільйон tx.
Переглянути оригіналвідповісти на0
just_another_wallet
· 07-30 17:29
Хто ще грає в повільне L1? L2 - перший у світі.
Переглянути оригіналвідповісти на0
LidoStakeAddict
· 07-30 17:29
Співучасник, основне питання все ще полягає в тому, що ефективність solidity занадто низька.
Web3 паралельні обчислення: п'ять парадигм для нових突破ів у масштабуванні Блокчейн
Панорама паралельних обчислень у Web3: найкраще рішення для рідного масштабування?
I. Огляд треку паралельних обчислень
"Неможливий трикутник" блокчейн-технологій (Blockchain Trilemma) "безпека", "децентралізація", "масштабованість" вказує на суттєві компроміси в проектуванні систем блокчейн, а саме, що проектам блокчейн важко досягти одночасно "максимальної безпеки, участі всіх і швидкої обробки". Щодо "масштабованості" - цієї вічної теми, на сьогоднішній день основні рішення для розширення блокчейн-технологій на ринку поділяються за парадигмами, зокрема:
Рішення для розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, модулі DA, модульну структуру, систему Actor, стиснення zk-доказів, безстатеву архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних, структури, є "багаторівневою координацією, модульною комбінацією" повною системою розширення. Ця стаття зосереджена на основному способі розширення на основі паралельних обчислень.
Внутрішня паралельна обробка ( intra-chain parallelism ), зосереджується на паралельному виконанні транзакцій/інструкцій усередині блокчейну. За механізмами паралелізму, способи масштабування можна поділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію. Паралельна гранулярність стає дедалі тоншою, інтенсивність паралелізму зростає, складність планування також зростає, а складність програмування та труднощі реалізації також зростають.
Модель асинхронної конкурентності поза ланцюгом, представлена системою агентів Actor (Agent / Actor Model), належить до іншої парадигми паралельних обчислень, як міжланцюгова/асинхронна система повідомлень ( ненормативна модель синхронізації блокчейнів ), кожен агент працює як незалежний "агентський процес", асинхронно обробляючи повідомлення в паралельному режимі, під керуванням подій, без необхідності в синхронізації, до таких проектів відносяться AO, ICP, Cartesi тощо.
А загальновідомі нам рішення Rollup або shards для розширення, є системними механізмами паралелізму, і не належать до паралельних обчислень всередині ланцюга. Вони реалізують розширення шляхом "паралельного виконання кількох ланцюгів/виконавчих доменів", а не шляхом підвищення паралельності всередині одного блоку/віртуальної машини. Такі рішення для розширення не є основною темою цього документа, але ми все ж використаємо їх для порівняння відмінностей в архітектурних концепціях.
Два, 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 Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може використовуватися як незалежна L1 публічна блокчейн-мережа або як рівень підвищення виконання на Ethereum (Execution Layer) або модульний компонент. Основна мета його дизайну полягає в розділенні логіки облікових записів, середовища виконання та стану на незалежно плановані мінімальні одиниці для досягнення високої конкурентоспроможності виконання в ланцюговій мережі та низької затримки реакції. Ключова інновація, запропонована 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 кожен виклик є асинхронним без блокування очікування; Стек дзвінків розгортається в асинхронний графік дзвінків (Call Graph); Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.
У підсумку, MegaETH порушує традиційну модель однопотокового станового автомата EVM, реалізуючи мікровіртуальну машину на основі облікових записів, здійснюючи планування транзакцій через граф залежності станів та замінюючи синхронний викликовий стек асинхронним механізмом повідомлень. Це платформа паралельних обчислень, що була повністю переосмислена в вимірі "структура облікового запису → архітектура планування → процес виконання", що надає нові парадигми для розробки систем високої продуктивності наступного покоління в режимі онлайн.
MegaETH обрала шлях реконструкції: повністю абстрагувати облікові записи та контракти в незалежну VM, звільняючи надзвичайний потенціал паралельного виконання через асинхронне виконання. Теоретично, паралельний ліміт MegaETH вищий, але також важче контролювати складність, більше схоже на суперрозподілену операційну систему в рамках концепції Ethereum.
Дизайнерські концепції Monad і MegaETH суттєво відрізняються від шардінгу (Sharding): шардінг розділяє блокчейн на кілька незалежних дочірніх ланцюгів (шарди Shards), кожен з яких відповідає за частину транзакцій і стану, розриваючи обмеження однофункціонального ланцюга для масштабування на мережевому рівні; в той час як Monad і MegaETH зберігають цілісність однофункціонального ланцюга, лише розширюючи горизонтально на рівні виконання, оптимізуючи паралельне виконання всередині однофункціонального ланцюга для покращення продуктивності. Обидва представляють два напрямки в шляхах масштабування блокчейну: вертикальне зміцнення і горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної здатності з метою підвищення TPS в межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через затримане виконання (Deferred Execution) та мікровіртуальну машину (Micro-VM). Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, який називається "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованими обробними мережами (SPNs), підтримуючи середовище з кількома віртуальними машинами (EVM та Wasm), а також інтегруючи передові технології, такі як нульові знання (ZK) та довірене середовище виконання (TEE).
Аналіз механізму паралельних обчислень Rollup Mesh:
Крім того, Pharos за допомогою багатоверсійного дерева Меркла, диференційного кодування (Delta Encoding), адресації версій (Versioned Addressing) та технології ADS-підсунути (ADS Pushdown), реконструює модель виконання на рівні сховища, запроваджуючи нативний блокчейн з високопродуктивним сховищем Pharos Store, що забезпечує високу пропускну спроможність, низьку затримку та сильну верифікацію можливостей обробки на ланцюгу.
В цілому, Rollup Mesh від Pharos