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

Одне. Огляд фону

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

• Виконання розширеної масштабованості: підвищення виконавчих можливостей на місці, наприклад, паралельне виконання, GPU, багатоядерність
• Ізольоване розширення стану: горизонтальне поділ стану/Shard, наприклад, шардінг, UTXO, багато підмереж
• Зовнішнє розширення типу аутсорсинг: виконання виводиться за межі ланцюга, наприклад, Rollup, Coprocessor, DA
• Декуплююча структура масштабування: модульна архітектура, спільна робота, наприклад, модульні ланцюги, спільні сортувальники, Rollup Mesh
• Асинхронне паралельне масштабування: модель актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопоточна асинхронна ланцюг

Рішення щодо розширення блокчейну включають: паралельні обчислення в межах ланцюга, Rollup, шардінг, DA модулі, модульна структура, система акторів, zk-докази компресії, безстанова архітектура тощо, охоплюючи виконання, стан, дані, структуру на кількох рівнях, є "багаторівневою координацією та комбінацією модулів" повною системою розширення. У цій статті особлива увага приділяється методам розширення, де основну роль відіграють паралельні обчислення.

Внутрішня паралельна обробка )intra-chain parallelism(, зосереджена на паралельному виконанні транзакцій/інструкцій всередині блокчейну. Згідно з механізмами паралелізму, способи масштабування можна поділити на п'ять основних категорій, кожна з яких представляє різні цілі продуктивності, моделі розробки та архітектурну філософію, з поступовим зменшенням розміру паралельних одиниць, підвищенням інтенсивності паралелізму, ускладненням планування, а також зростанням складності програмування та труднощів реалізації.

• Обліковий рівень паралельності )Обліковий рівень (: представляє проект Solana
• Об'єктний рівень ) Object-level (: представляє проект Sui
• Торгова паралель )Transaction-level (: представляє проект Monad, Aptos
• Виклик рівня/мікро VM паралельно )Call-level / MicroVM(: представляє проект MegaETH
• інструкційний рівень ) Instruction-level (: представляє проект GatlingX

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

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

![Web3 паралельних обчислень: найкраще рішення для нативного масштабування?])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(, реалізуючи оптимізацію від кінця до кінця.

Пайплайнінг: механізм паралельного виконання багатофазного конвеєра

Пайплайнинг є основною концепцією паралельного виконання монади, його основна ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів і паралельній обробці цих етапів, що формує тривимірну архітектуру конвеєра, де кожен етап працює на незалежних потоках або ядрах, що реалізує паралельну обробку через блоки, в результаті чого досягається підвищення пропускної здатності та зниження затримок. Ці етапи включають: пропозиція угоди )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(", що "потокізує" середовище виконання, забезпечуючи мінімальний ізоляційний елемент для паралельного планування. Ці VM спілкуються між собою через асинхронне повідомлення )Asynchronous Messaging(, а не синхронні виклики, що дозволяє багатьом VM незалежно виконуватись і зберігатись, природно паралельно.

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

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

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

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

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

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

![Веб3 паралельні обчислення: найкраще рішення для рідного масштабування?])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(, і через протокол повторного стейкінгу )Restaking( досягає безпечного обміну та інтеграції ресурсів між основною мережею та SPNs.