Панорама паралельних обчислень Web3: Найкраще рішення для рідного масштабування?
Блокчейн «неможливого трикутника» «безпека», «децентралізація», «масштабованість» виявляє сутнісні компроміси в дизайні блокчейн-систем, а саме, що блокчейн-проєкти важко одночасно реалізувати «максимальну безпеку, участь усіх, швидку обробку». Щодо «масштабованості» — цієї вічної теми, на сьогоднішній день основні рішення для розширення блокчейну на ринку поділяються за парадигмою, зокрема:
Виконання покращеного масштабування: підвищення виконавчих можливостей на місці, наприклад, паралелізм, GPU, багатоядерність
Ізоляція стану: горизонтальне розділення стану / Shard, наприклад, шардінг, UTXO, багато підмереж
Зовнішнє розширення типу аутсорсингу: виконання поза ланцюгом, наприклад, Rollup, Копрогресор, DA
Розширення з декомпозицією структури: модульна архітектура, спільна робота, наприклад, модульні ланцюги, спільні сортувальники, Rollup Mesh
Асинхронне масштабування з паралельною обробкою: модель актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопотокове асинхронне з'єднання
Рішення щодо розширення блокчейну включають: паралельні обчислення на ланцюзі, Rollup, шардінг, DA модулі, модульну структуру, систему Actor, компресію zk-доказів, безстанну архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних і структури, є «багаторівневою координацією, модульною комбінацією» повною системою розширення. У цій статті основна увага приділяється методам розширення, що базуються на паралельних обчисленнях.
Внутрішня паралельна обробка (intra-chain parallelism), зосереджена на паралельному виконанні транзакцій / інструкцій всередині блокчейну. Згідно з механізмами паралелізму, способи масштабування можна розділити на п'ять великих категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію, поступово зменшуючи масштаб паралелізму, збільшуючи інтенсивність паралелізму, ускладнюючи планування, а також підвищуючи складність програмування та труднощі реалізації.
Обліковий рівень паралельності: представляє проект Solana
Об'єктне паралельне виконання: представляє проект Sui
Торговельний рівень паралельності: представляє проекти Monad, Aptos
Виклики рівня / мікро-VM паралельно: представляє проект MegaETH
Інструкційний рівень паралелізму: представляє проект GatlingX
Зовнішня асинхронна паралельна модель, представлена системою агентів Actor, є ще одним парадигмою паралельних обчислень. Як міжланцюгова / асинхронна система повідомлень, кожен агент виступає як незалежно працюючий «агентський процес», асинхронно обробляючи повідомлення в паралельному режимі, керуючи подіями без необхідності синхронізації. Представлені проекти: AO, ICP, Cartesi та ін.
А популярні нам Rollup або рішення для розширення через шардінг є механізмами системного рівня паралелізму, які не належать до паралельних обчислень всередині ланцюга. Вони реалізують розширення за рахунок «паралельного запуску кількох ланцюгів / виконавчих доменів», а не підвищення паралелізму всередині одного блоку / віртуальної машини. Подібні рішення для розширення не є основною темою цього документа, але ми все ж будемо використовувати їх для порівняння концепцій архітектури.
Два, EVM системна паралельна вдосконалена ланка: прорив меж продуктивності в рамках сумісності
Архітектура послідовної обробки Ethereum розвивалася до сьогодні, пройшовши через кілька спроб масштабування, такі як шардінг, Rollup, модульна архітектура тощо, але вузьке місце в пропускній здатності виконавчого рівня досі не було радикально подолано. Тим не менш, EVM та Solidity залишаються найпопулярнішими платформами для смарт-контрактів з найбільшою базою розробників та екосистемною потенцією. Отже, паралельна посилена ланцюгова архітектура EVM, яка поєднує екосистемну сумісність та підвищення продуктивності виконання, стає важливим напрямком у новому етапі еволюції масштабування. Monad та MegaETH є найбільш представницькими проектами в цьому напрямку, які, відповідно, будують архітектуру паралельної обробки EVM для сценаріїв з високою конкуренцією та великою пропускною здатністю, виходячи з затримки виконання та розподілу стану.
Аналіз механізму паралельних обчислень Monad
Monad - це високопродуктивна Layer1 блокчейн, перероблена для віртуальної машини Ethereum, що базується на основній паралельній концепції конвеєрної обробки, з асинхронним виконанням на рівні консенсусу та оптимістичноюConcurrency на рівні виконання. Крім того, на рівнях консенсусу та зберігання Monad впроваджує високопродуктивний BFT протокол та спеціалізовану систему бази даних, що забезпечує оптимізацію від початку до кінця.
Пайплайнинг: механізм паралельного виконання з багатоступеневим конвеєром
Pipelining є основною концепцією паралельного виконання Monad, її основна ідея полягає в розділенні процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує багатовимірну конвеєрну архітектуру, де кожен етап виконується на незалежних потоках або ядрах, реалізуючи паралельну обробку через блоки, в результаті чого досягається підвищення пропускної здатності та зниження затримок. Ці етапи включають: пропозиція транзакцій, досягнення консенсусу, виконання транзакцій та подання блоків.
Асинхронне виконання: консенсус - виконання асинхронного розв'язання
У традиційних блокчейнах консенсус і виконання транзакцій зазвичай є синхронними процесами, і ця послідовна модель суттєво обмежує масштабованість продуктивності. Monad реалізує асинхронність на рівні консенсусу, асинхронність на рівні виконання та асинхронність у зберіганні через «асинхронне виконання». Це значно знижує час блокування та затримку підтвердження, роблячи систему більш гнучкою, обробку процесів більш деталізованою та підвищує ефективність використання ресурсів.
Основний дизайн:
Процес консенсусу відповідає лише за впорядкування транзакцій, а не за виконання логіки контрактів.
Процес виконання асинхронно запускається після завершення консенсусу.
Після завершення консенсусу відразу переходьте до процесу консенсусу наступного блоку, не чекаючи завершення виконання.
Оптимістичне паралельне виконання:乐观并行执行
Традиційний Ethereum використовує сувору послідовну модель для виконання транзакцій, щоб уникнути конфліктів стану. Натомість Monad використовує стратегію «оптимістичного паралельного виконання», що значно підвищує швидкість обробки транзакцій.
Механізм виконання:
Monad оптимістично виконує всі транзакції паралельно, вважаючи, що більшість транзакцій не має конфліктів зі станом.
Одночасно працювати з «дослідником конфліктів», щоб контролювати, чи доступали транзакції до одного й того ж стану.
Якщо виявлено конфлікт, то конфліктні транзакції будуть серіалізовані та повторно виконані, щоб забезпечити правильність стану.
Monad обрав сумісний шлях: мінімізувати зміни в правилах EVM, реалізувати паралельність шляхом відстрочки запису стану та динамічного виявлення конфліктів в процесі виконання, більше схоже на продуктивну версію Ethereum, з хорошою зрілістю і легкістю реалізації міграції EVM-екосистеми, є паралельним прискорювачем світу EVM.
Аналіз механізму паралельних обчислень MegaETH
На відміну від позиціонування Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може діяти як незалежна L1 публічна блокчейн-мережа, так і як посилювальний рівень виконання або модульний компонент на Ethereum. Основною метою його дизайну є розділення логіки облікового запису, виконавчого середовища та стану на незалежно плановані мінімальні одиниці для досягнення високої паралельної виконуваності всередині ланцюга і низької затримки відповіді. Ключова інновація, запропонована MegaETH, полягає в архітектурі Micro-VM + DAG залежності стану та модульному механізмі синхронізації, які спільно створюють паралельну виконавчу систему, орієнтовану на "ланцюгову потоковість".
Micro-VM архітектура: обліковий запис як потік
MegaETH запровадив модель виконання «один мікровіртуальний машин на кожен обліковий запис», що «потоковує» виконавче середовище, забезпечуючи найменшу одиницю ізоляції для паралельного планування. Ці ВМ спілкуються між собою через асинхронне повідомлення, а не синхронні виклики, що дозволяє великій кількості ВМ незалежно виконуватись та зберігатись, природно паралельно.
State Dependency DAG: механізм планування на основі графів залежності
MegaETH побудував систему планування DAG, засновану на відношеннях доступу до стану облікових записів, система в реальному часі підтримує глобальну залежну графіку, кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється в залежностях. Безконфліктні транзакції можуть виконуватись паралельно, транзакції з залежностями будуть плануватись послідовно або відкладено за топологічним порядком. Залежний граф забезпечує узгодженість стану та недублювання записів під час паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH будується на основі асинхронної програмної парадигми, подібно до асинхронної передачі повідомлень моделі акторів, вирішуючи проблему послідовних викликів традиційного EVM. Виклики контрактів є асинхронними, коли викликається контракт A -\u003e B -\u003e C, кожен виклик асинхронізується, не потрібно блокуватися в очікуванні; стек викликів розгортається в асинхронний граф викликів; обробка транзакцій = обходження асинхронного графа + розпізнавання залежностей + паралельне планування.
В цілому, MegaETH руйнує традиційну модель однопоточного стану EVM, реалізуючи мікровіртуальні машини в упаковці на базі облікових записів, використовуючи графік залежностей стану для планування транзакцій і замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це паралельна обчислювальна платформа, яка була переосмислена в усіх вимірах – від "структури облікових записів → архітектури планування → виконавчих процесів", що пропонує нові ідеї парадигми для створення наступного покоління високопродуктивних систем на ланцюгу.
MegaETH обрав шлях реконструкції: повністю абстрагувати рахунки та контракти в незалежну VM, звільняючи надзвичайний потенціал паралелізму через асинхронне виконання розкладання. Теоретично, паралельний ліміт MegaETH вищий, але також важче контролювати складність, більше схоже на супер розподілену операційну систему в концепції Ethereum.
Дизайн концепції Monad і MegaETH значно відрізняється від шардінгу: шардінг розділяє блокчейн на кілька незалежних підланок, кожна з яких відповідає за частину транзакцій та стану, руйнуючи обмеження одноланкового підходу в розширенні на мережевому рівні; тоді як Monad і MegaETH зберігають цілісність одноланкового підходу, лише горизонтально розширюючись на рівні виконання, досягаючи оптимізації паралельного виконання всередині одноланки для підвищення продуктивності. Обидва представляють два напрямки у шляху розширення блокчейну: вертикальне посилення та горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, зосереджені на оптимізації пропускної спроможності, щоб підвищити TPS в мережі як основну мету, реалізуючи паралельну обробку на рівні транзакцій або рахунків через відкладене виконання та мікровіртуальні архітектури. Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованою обробною мережею, підтримує середовище з кількома віртуальними машинами та інтегрує передові технології, такі як нульове знання та довірене середовище виконання.
Аналіз механізму паралельних обчислень Rollup Mesh:
Обробка асинхронного конвеєра на всіх етапах життєвого циклу: Pharos розділяє різні етапи транзакції та використовує асинхронний спосіб обробки, що дозволяє кожному етапу виконуватися незалежно та паралельно, тим самим підвищуючи загальну ефективність обробки.
Паралельне виконання двох віртуальних машин: Pharos підтримує два середовища віртуальних машин EVM і WASM, дозволяючи розробникам вибрати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й підвищує здатність обробки транзакцій завдяки паралельному виконанню.
Спеціалізовані мережі: SPNs є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, спеціально призначених для обробки певних типів завдань або додатків. Завдяки SPNs Pharos може реалізувати динамічний розподіл ресурсів і паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
Модульна консенсусна система та механізм повторного стейкінгу: Pharos впроваджує гнучку консенсусну систему, що підтримує декілька моделей консенсусу, та реалізує безпечний обмін і інтеграцію ресурсів між основною мережею та SPN за допомогою протоколу повторного стейкінгу.
Крім того, Pharos за допомогою багатовершинного дерева Меркла, диференційного кодування, адресації версій та технології занурення ADS, реконструював модель виконання з нижнього рівня сховища, запустивши рідний блокчейн високопродуктивний сховищний двигун Pharos Store, що забезпечує високу пропускну здатність, низьку затримку та сильну перевіряємість обробки в ланцюзі.
В цілому, архітектура Rollup Mesh від Pharos реалізує високопродуктивні паралельні обчислювальні можливості завдяки модульному дизайну та асинхронному механізму обробки. Pharos, як координатор розподілу між Rollup, не є оптимізатором виконання «в межах ланцюга», а виконує завдання різноманітного налаштування через SPN.
 і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
20 лайків
Нагородити
20
9
Репост
Поділіться
Прокоментувати
0/400
GateUser-a606bf0c
· 08-14 19:27
Ай, це навіть гірше, ніж просто викинути сервер і сильно порахувати.
Переглянути оригіналвідповісти на0
HashRatePhilosopher
· 08-14 00:10
старий і добре відомий питання розширення
Переглянути оригіналвідповісти на0
WalletDoomsDay
· 08-13 15:34
Шардинг вже обговорюється кілька років, а ми все ще на місці.
Переглянути оригіналвідповісти на0
LayerZeroHero
· 08-12 12:13
Справжній аромат, нарешті хтось глибоко досліджує вузькі місця EVM.
Переглянути оригіналвідповісти на0
SchrodingerPrivateKey
· 08-12 01:17
Швидкість можна пожертвувати, безпека основного блокчейну повинна бути на максимумі.
Переглянути оригіналвідповісти на0
PumpingCroissant
· 08-12 01:14
Рекомендується продовжити памп пастку.
Переглянути оригіналвідповісти на0
FlatTax
· 08-12 01:13
у блокчейні обчислення ще потрібно покладатися на жорстку силу!
Переглянути оригіналвідповісти на0
SerumSqueezer
· 08-12 01:09
Блокчейн трикутник хто зможе зламати? Шар за шаром правда сліпить око～
Веб3 паралельні обчислення: панорамний аналіз від сумісності EVM до прориву продуктивності в гетерогенних архітектурах
Панорама паралельних обчислень Web3: Найкраще рішення для рідного масштабування?
Блокчейн «неможливого трикутника» «безпека», «децентралізація», «масштабованість» виявляє сутнісні компроміси в дизайні блокчейн-систем, а саме, що блокчейн-проєкти важко одночасно реалізувати «максимальну безпеку, участь усіх, швидку обробку». Щодо «масштабованості» — цієї вічної теми, на сьогоднішній день основні рішення для розширення блокчейну на ринку поділяються за парадигмою, зокрема:
Рішення щодо розширення блокчейну включають: паралельні обчислення на ланцюзі, Rollup, шардінг, DA модулі, модульну структуру, систему Actor, компресію zk-доказів, безстанну архітектуру тощо, охоплюючи кілька рівнів виконання, стану, даних і структури, є «багаторівневою координацією, модульною комбінацією» повною системою розширення. У цій статті основна увага приділяється методам розширення, що базуються на паралельних обчисленнях.
Внутрішня паралельна обробка (intra-chain parallelism), зосереджена на паралельному виконанні транзакцій / інструкцій всередині блокчейну. Згідно з механізмами паралелізму, способи масштабування можна розділити на п'ять великих категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію, поступово зменшуючи масштаб паралелізму, збільшуючи інтенсивність паралелізму, ускладнюючи планування, а також підвищуючи складність програмування та труднощі реалізації.
Зовнішня асинхронна паралельна модель, представлена системою агентів Actor, є ще одним парадигмою паралельних обчислень. Як міжланцюгова / асинхронна система повідомлень, кожен агент виступає як незалежно працюючий «агентський процес», асинхронно обробляючи повідомлення в паралельному режимі, керуючи подіями без необхідності синхронізації. Представлені проекти: AO, ICP, Cartesi та ін.
А популярні нам Rollup або рішення для розширення через шардінг є механізмами системного рівня паралелізму, які не належать до паралельних обчислень всередині ланцюга. Вони реалізують розширення за рахунок «паралельного запуску кількох ланцюгів / виконавчих доменів», а не підвищення паралелізму всередині одного блоку / віртуальної машини. Подібні рішення для розширення не є основною темою цього документа, але ми все ж будемо використовувати їх для порівняння концепцій архітектури.
Два, EVM системна паралельна вдосконалена ланка: прорив меж продуктивності в рамках сумісності
Архітектура послідовної обробки Ethereum розвивалася до сьогодні, пройшовши через кілька спроб масштабування, такі як шардінг, Rollup, модульна архітектура тощо, але вузьке місце в пропускній здатності виконавчого рівня досі не було радикально подолано. Тим не менш, EVM та Solidity залишаються найпопулярнішими платформами для смарт-контрактів з найбільшою базою розробників та екосистемною потенцією. Отже, паралельна посилена ланцюгова архітектура EVM, яка поєднує екосистемну сумісність та підвищення продуктивності виконання, стає важливим напрямком у новому етапі еволюції масштабування. Monad та MegaETH є найбільш представницькими проектами в цьому напрямку, які, відповідно, будують архітектуру паралельної обробки EVM для сценаріїв з високою конкуренцією та великою пропускною здатністю, виходячи з затримки виконання та розподілу стану.
Аналіз механізму паралельних обчислень Monad
Monad - це високопродуктивна Layer1 блокчейн, перероблена для віртуальної машини Ethereum, що базується на основній паралельній концепції конвеєрної обробки, з асинхронним виконанням на рівні консенсусу та оптимістичноюConcurrency на рівні виконання. Крім того, на рівнях консенсусу та зберігання Monad впроваджує високопродуктивний BFT протокол та спеціалізовану систему бази даних, що забезпечує оптимізацію від початку до кінця.
Пайплайнинг: механізм паралельного виконання з багатоступеневим конвеєром
Pipelining є основною концепцією паралельного виконання Monad, її основна ідея полягає в розділенні процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує багатовимірну конвеєрну архітектуру, де кожен етап виконується на незалежних потоках або ядрах, реалізуючи паралельну обробку через блоки, в результаті чого досягається підвищення пропускної здатності та зниження затримок. Ці етапи включають: пропозиція транзакцій, досягнення консенсусу, виконання транзакцій та подання блоків.
Асинхронне виконання: консенсус - виконання асинхронного розв'язання
У традиційних блокчейнах консенсус і виконання транзакцій зазвичай є синхронними процесами, і ця послідовна модель суттєво обмежує масштабованість продуктивності. Monad реалізує асинхронність на рівні консенсусу, асинхронність на рівні виконання та асинхронність у зберіганні через «асинхронне виконання». Це значно знижує час блокування та затримку підтвердження, роблячи систему більш гнучкою, обробку процесів більш деталізованою та підвищує ефективність використання ресурсів.
Основний дизайн:
Оптимістичне паралельне виконання:乐观并行执行
Традиційний Ethereum використовує сувору послідовну модель для виконання транзакцій, щоб уникнути конфліктів стану. Натомість Monad використовує стратегію «оптимістичного паралельного виконання», що значно підвищує швидкість обробки транзакцій.
Механізм виконання:
Monad обрав сумісний шлях: мінімізувати зміни в правилах EVM, реалізувати паралельність шляхом відстрочки запису стану та динамічного виявлення конфліктів в процесі виконання, більше схоже на продуктивну версію Ethereum, з хорошою зрілістю і легкістю реалізації міграції EVM-екосистеми, є паралельним прискорювачем світу EVM.
Аналіз механізму паралельних обчислень MegaETH
На відміну від позиціонування Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий рівень, сумісний з EVM, який може діяти як незалежна L1 публічна блокчейн-мережа, так і як посилювальний рівень виконання або модульний компонент на Ethereum. Основною метою його дизайну є розділення логіки облікового запису, виконавчого середовища та стану на незалежно плановані мінімальні одиниці для досягнення високої паралельної виконуваності всередині ланцюга і низької затримки відповіді. Ключова інновація, запропонована MegaETH, полягає в архітектурі Micro-VM + DAG залежності стану та модульному механізмі синхронізації, які спільно створюють паралельну виконавчу систему, орієнтовану на "ланцюгову потоковість".
Micro-VM архітектура: обліковий запис як потік
MegaETH запровадив модель виконання «один мікровіртуальний машин на кожен обліковий запис», що «потоковує» виконавче середовище, забезпечуючи найменшу одиницю ізоляції для паралельного планування. Ці ВМ спілкуються між собою через асинхронне повідомлення, а не синхронні виклики, що дозволяє великій кількості ВМ незалежно виконуватись та зберігатись, природно паралельно.
State Dependency DAG: механізм планування на основі графів залежності
MegaETH побудував систему планування DAG, засновану на відношеннях доступу до стану облікових записів, система в реальному часі підтримує глобальну залежну графіку, кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється в залежностях. Безконфліктні транзакції можуть виконуватись паралельно, транзакції з залежностями будуть плануватись послідовно або відкладено за топологічним порядком. Залежний граф забезпечує узгодженість стану та недублювання записів під час паралельного виконання.
Асинхронне виконання та механізм зворотного виклику
MegaETH будується на основі асинхронної програмної парадигми, подібно до асинхронної передачі повідомлень моделі акторів, вирішуючи проблему послідовних викликів традиційного EVM. Виклики контрактів є асинхронними, коли викликається контракт A -\u003e B -\u003e C, кожен виклик асинхронізується, не потрібно блокуватися в очікуванні; стек викликів розгортається в асинхронний граф викликів; обробка транзакцій = обходження асинхронного графа + розпізнавання залежностей + паралельне планування.
В цілому, MegaETH руйнує традиційну модель однопоточного стану EVM, реалізуючи мікровіртуальні машини в упаковці на базі облікових записів, використовуючи графік залежностей стану для планування транзакцій і замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це паралельна обчислювальна платформа, яка була переосмислена в усіх вимірах – від "структури облікових записів → архітектури планування → виконавчих процесів", що пропонує нові ідеї парадигми для створення наступного покоління високопродуктивних систем на ланцюгу.
MegaETH обрав шлях реконструкції: повністю абстрагувати рахунки та контракти в незалежну VM, звільняючи надзвичайний потенціал паралелізму через асинхронне виконання розкладання. Теоретично, паралельний ліміт MegaETH вищий, але також важче контролювати складність, більше схоже на супер розподілену операційну систему в концепції Ethereum.
Дизайн концепції Monad і MegaETH значно відрізняється від шардінгу: шардінг розділяє блокчейн на кілька незалежних підланок, кожна з яких відповідає за частину транзакцій та стану, руйнуючи обмеження одноланкового підходу в розширенні на мережевому рівні; тоді як Monad і MegaETH зберігають цілісність одноланкового підходу, лише горизонтально розширюючись на рівні виконання, досягаючи оптимізації паралельного виконання всередині одноланки для підвищення продуктивності. Обидва представляють два напрямки у шляху розширення блокчейну: вертикальне посилення та горизонтальне розширення.
Проекти паралельних обчислень, такі як Monad та MegaETH, зосереджені на оптимізації пропускної спроможності, щоб підвищити TPS в мережі як основну мету, реалізуючи паралельну обробку на рівні транзакцій або рахунків через відкладене виконання та мікровіртуальні архітектури. Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як "Rollup Mesh". Ця архітектура підтримує співпрацю між основною мережею та спеціалізованою обробною мережею, підтримує середовище з кількома віртуальними машинами та інтегрує передові технології, такі як нульове знання та довірене середовище виконання.
Аналіз механізму паралельних обчислень Rollup Mesh:
Обробка асинхронного конвеєра на всіх етапах життєвого циклу: Pharos розділяє різні етапи транзакції та використовує асинхронний спосіб обробки, що дозволяє кожному етапу виконуватися незалежно та паралельно, тим самим підвищуючи загальну ефективність обробки.
Паралельне виконання двох віртуальних машин: Pharos підтримує два середовища віртуальних машин EVM і WASM, дозволяючи розробникам вибрати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й підвищує здатність обробки транзакцій завдяки паралельному виконанню.
Спеціалізовані мережі: SPNs є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, спеціально призначених для обробки певних типів завдань або додатків. Завдяки SPNs Pharos може реалізувати динамічний розподіл ресурсів і паралельну обробку завдань, що додатково підвищує масштабованість і продуктивність системи.
Модульна консенсусна система та механізм повторного стейкінгу: Pharos впроваджує гнучку консенсусну систему, що підтримує декілька моделей консенсусу, та реалізує безпечний обмін і інтеграцію ресурсів між основною мережею та SPN за допомогою протоколу повторного стейкінгу.
Крім того, Pharos за допомогою багатовершинного дерева Меркла, диференційного кодування, адресації версій та технології занурення ADS, реконструював модель виконання з нижнього рівня сховища, запустивши рідний блокчейн високопродуктивний сховищний двигун Pharos Store, що забезпечує високу пропускну здатність, низьку затримку та сильну перевіряємість обробки в ланцюзі.
В цілому, архітектура Rollup Mesh від Pharos реалізує високопродуктивні паралельні обчислювальні можливості завдяки модульному дизайну та асинхронному механізму обробки. Pharos, як координатор розподілу між Rollup, не є оптимізатором виконання «в межах ланцюга», а виконує завдання різноманітного налаштування через SPN.
![Web3 паралельні обчислення: найкраще рішення для нативного масштабування?](