Панорамна карта паралельних обчислень у Web3: найкраще рішення для рідного розширення?

Один. Паралельні обчислення: ключовий шлях до масштабування блокчейну

"Неможливий трикутник" блокчейну "("безпека", "децентралізація", "масштабованість") розкриває суттєві компроміси в проектуванні систем блокчейну, а саме, що проектам блокчейну важко одночасно досягти "максимальної безпеки, доступності для всіх, швидкої обробки". Щодо вічної теми "масштабованості", існуючі основні рішення щодо розширення блокчейну на ринку поділяються за парадигмами, включаючи:

• Виконання розширених можливостей: підвищення виконувальних можливостей на місці, наприклад, паралельне виконання, 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
• Інструкційний рівень (: представляє проект GatlingX

Модель асинхронної паралельної обробки поза ланцюгом, представлена системою агентів Actor )Agent / Actor Model(, належить до іншої парадигми паралельних обчислень, як міжланцюгова/асинхронна система повідомлень )незалежна модель блокчейну (, кожен агент виступає як незалежний "агент-процес", асинхронно обробляючи повідомлення в паралельному режимі, керуючи подіями без необхідності синхронізації, до представників проектів відносяться AO, ICP, Cartesi та ін.

А наші знайомі Rollup або рішення для масштабування через шардінг належать до системних механізмів паралелізму, а не до паралельних обчислень всередині ланцюга. Вони реалізують масштабування шляхом "паралельного запуску кількох ланцюгів/виконавчих доменів", а не підвищення паралельності всередині одного блоку/віртуальної машини. Це рішення для масштабування не є основною темою даної статті, але ми все ж використовуватимемо його для порівняння різних архітектурних концепцій.

![Веб3 паралельні обчислення: найкраще рішення для рідного масштабування?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

Два, 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.

![Web3 паралельні обчислення: найкраще рішення для рідної масштабованості?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

) Аналіз паралельного обчислювального механізму MegaETH

На відміну від позиціонування L1 в Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може бути як незалежною публічною ланцюгом L1, так і посиленням виконання на Ethereum ###Execution Layer( або модульним компонентом. Його основною метою дизайну є розділення логіки облікового запису, середовища виконання та стану на незалежно плановані мінімальні одиниці, щоб досягти високої паралельної виконуваності та низької затримки реагування в межах ланцюга. Ключова інновація, запропонована MegaETH, полягає в: архітектурі Micro-VM + State Dependency DAG)орієнтований ациклічний граф залежності стану( та модульному механізмі синхронізації, які разом створюють паралельну виконавчу систему, орієнтовану на "ланцюгову поточність".

Micro-VM) мікровіртуальна машина ( архітектура: обліковий запис як потік

MegaETH впроваджує модель виконання "один мікровіртуальний комп'ютер на кожен обліковий запис ) Micro-VM (", яка "потокізує" середовище виконання, забезпечуючи мінімальну одиницю ізоляції для паралельного планування. Ці ВМ спілкуються між собою через асинхронне повідомлення ) Asynchronous Messaging (, а не через синхронні виклики, що дозволяє великій кількості ВМ виконуватися незалежно та зберігатися незалежно, природно паралельно.

Даг залежності стану: механізм планування, що базується на графі залежностей

MegaETH побудувала систему DAG-диспетчеризації на основі відносин доступу до стану облікового запису, система в реальному часі підтримує глобальний граф залежностей )Dependency Graph(, кожна транзакція модифікує які облікові записи, читає які облікові записи, все моделюється у вигляді залежностей. Транзакції без конфліктів можуть виконуватись паралельно, транзакції з залежностями будуть плануватись у порядку топології або відкладені. Граф залежностей забезпечує узгодженість стану та уникнення повторних записів під час паралельного виконання.

Асинхронне виконання та механізм зворотного виклику

MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики контрактів є асинхронними ) ( нерекурсивного виконання, а при виклику контракту A -> B -> C кожен виклик є асинхронним без блокування очікування; Стек дзвінків розгортається в асинхронний графік дзвінків )Call Graph(; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.

У підсумку, MegaETH руйнує традиційну модель однопоточної машини станів EVM, реалізуючи упаковку мікровіртуальної машини на базі облікових записів, здійснюючи планування транзакцій через граф залежностей станів, і замінюючи синхронний стек викликів асинхронним механізмом повідомлень. Це є паралельною обчислювальною платформою, що повністю перепроектована в вимірах "структура облікового запису → архітектура планування → процес виконання", що пропонує нові парадигми для побудови системи високої продуктивності наступного покоління на ланцюзі.

MegaETH вибрав шлях реконструкції: повністю абстрагувати рахунки та контракти в незалежну VM, звільняючи максимальний паралельний потенціал через асинхронне виконання. Теоретично, паралельний ліміт MegaETH вищий, але й контролювати складність важче, більше схоже на суперрозподілену операційну систему на основі концепції Ethereum.

![Web3 паралельні обчислення: найкраще рішення для рідного розширення?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

Дизайнерські концепції 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:

1. Повний життєвий цикл асинхронної обробки конвеєра)Full Lifecycle Asynchronous Pipelining(: Pharos декомпозує різні етапи транзакції), такі як консенсус, виконання, зберігання(, і використовує асинхронний спосіб обробки, що дозволяє кожному етапу виконуватись незалежно і паралельно, що підвищує загальну ефективність обробки.
2. Двійне паралельне виконання віртуальних машин )Dual VM Parallel Execution(: Pharos підтримує дві віртуальні машинні середовища: EVM та WASM, що дозволяє розробникам обирати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й покращує обробку транзакцій завдяки паралельному виконанню.
3. Спеціальна обробка мережі )SPNs(: SPNs є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, спеціально призначених для обробки специфічних типів завдань або застосувань. Через SPNs Pharos може реалізувати динамічне розподілення ресурсів і паралельну обробку завдань, що ще більше підвищує масштабованість та продуктивність системи.
4. Модульна консенсусна і механізм повторного стейкінгу ) Modular Consensus & Restaking (: Pharos впроваджує гнучкий механізм консенсусу, що підтримує різні моделі консенсусу ), такі як PBFT, PoS, PoA (, і реалізує безпечне спільне використання та інтеграцію ресурсів між основною мережею та SPNs через протокол повторного стейкінгу ) Restaking (.

Крім того, Pharos за допомогою мультиверсійного дерева Меркла, диференційного кодування )Delta Encoding(, адресації версій )Versioned Addressing( та технології ADS Pushdown )ADS Pushdown(, реконструює модель виконання з нижнього рівня сховища, запроваджуючи рідний блокчейн з високопродуктивним сховищем Pharos Store, що забезпечує високу пропускну здатність, низьку затримку та сильну перевіряємість обробки в мережі.

![