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

"Неможливий трикутник" ( 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 паралельно (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(, реалізуючи оптимізацію від кінця до кінця.

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

Залежність стану 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 зберігають цілісність одноланки, лише горизонтально розширюючи виконання, досягаючи оптимізації паралельного виконання всередині одноланки для підвищення продуктивності. Обидва представляють два напрямки у шляху розширення блокчейну: вертикальне зміцнення та горизонтальне розширення.

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

Проекти паралельних обчислень, такі як Monad та MegaETH, зосереджені на оптимізації пропускної здатності, з основною метою підвищення TPS в межах ланцюга, реалізуючи паралельну обробку на рівні транзакцій або облікових записів через відкладене виконання )Deferred Execution( та мікровіртуальну машину )Micro-VM(. Pharos Network, як модульна, повнофункціональна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, що називається "Rollup Mesh". Ця архітектура підтримує багатовіртуальне середовище )EVM та Wasm( через співпрацю основної мережі та спеціальних обробних мереж )SPNs(, а також інтегрує передові технології, такі як нульові знання )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 вводить гнучкий консенсус