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

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

"Невозможный треугольник" блокчейна "безопасность", "децентрализация", "масштабируемость" ( выявляет основные компромиссы в проектировании блокчейн-систем, а именно, что блокчейн-проектам сложно одновременно добиться "максимальной безопасности, доступности для всех и высокой скорости обработки". Что касается "масштабируемости", этой вечной темы, на сегодняшний день основные решения для расширения блокчейна на рынке различаются по парадигмам, включая:

• Выполнение улучшенного расширения: повышение возможностей выполнения на месте, например, параллельно, с использованием GPU, многопоточностью
• Изолированное расширение состояния: горизонтальное разделение состояния/Shard, например, шардирование, UTXO, множественные подсети
• Внешняя модель расширения: выполнение вне цепи, например Rollup, сопроцессор, 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
• Уровень инструкций ) Instruction-level (: представляет проект GatlingX

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

Тем не менее, известные нам решения по расширению, такие как Rollup или шардирование, относятся к механизмам параллелизма на уровне системы и не являются параллельными вычислениями внутри цепи. Они достигают масштабируемости за счет "параллельного выполнения нескольких цепей/исполнительных областей", а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Эти решения по расширению не являются основной темой данной статьи, но мы все же будем использовать их для сопоставления архитектурных концепций.

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

2. Усовершенствованная параллельная цепь EVM: прорыв в производительности в условиях совместимости

Архитектура последовательной обработки Ethereum на сегодняшний день прошла через множество попыток масштабирования, включая шардирование, Rollup и модульную архитектуру, но узкие места пропускной способности на уровне исполнения все еще не были кардинально преодолены. Тем не менее, EVM и Solidity по-прежнему являются наиболее развитыми платформами смарт-контрактов с мощной базой разработчиков и экосистемой. Поэтому параллельные улучшенные цепочки EVM, которые балансируют совместимость экосистемы и повышение производительности исполнения, становятся важным направлением следующего этапа масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, строя архитектуру параллельной обработки EVM, ориентированную на сценарии высокой конкуренции и высокой пропускной способности, начиная с задержки исполнения и декомпозиции состояния.

) Анализ механизма параллельных вычислений Monad

Monad - это высокопроизводительная блокчейн-система Layer1, переработанная для Ethereum Virtual Machine ###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.

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

) Анализ механизма параллельных вычислений MegaETH

В отличие от L1, позиционированного как Monad, MegaETH позиционируется как модульный высокопроизводительный уровень параллельного исполнения, совместимый с EVM, который может использоваться как независимая L1 публичная цепочка, так и как уровень усиленного исполнения на Ethereum ###Execution Layer( или модульный компонент. Его основной дизайнерской целью является декомпозиция логики аккаунта, среды исполнения и состояния в независимо планируемые минимальные единицы, чтобы обеспечить высокую параллельную обработку и низкую задержку отклика. Ключевое нововведение, предложенное MegaETH, заключается в: архитектуре Micro-VM + Directed Acyclic Graph (DAG) )граф зависимости состояния( и модульном механизме синхронизации, которые вместе создают параллельную систему исполнения, нацеленную на "потоковую обработку внутри цепи".

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

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

Зависимость состояния DAG: механизм планирования на основе графа зависимостей

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

Асинхронное выполнение и механизм обратного вызова

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

В общем, MegaETH разрушает традиционную модель однопоточной машины состояния EVM, реализуя упаковку микровиртуальных машин на уровне учетной записи, осуществляя планирование транзакций через граф зависимости состояния и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, полностью переработанная по всем направлениям "структура учетной записи → архитектура планирования → процесс выполнения", предлагая новый парадигмальный подход для построения систем высокого производительности следующего поколения на цепи.

MegaETH выбрал путь реконструкции: полностью абстрагировать аккаунты и контракты в независимую виртуальную машину, используя асинхронное выполнение и планирование для раскрытия предельного параллельного потенциала. Теоретически, параллельный предел 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". Эта архитектура поддерживает многовиртуальные среды )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 вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса ), такие как PBFT, PoS, PoA (, и реализует безопасный обмен и интеграцию ресурсов между основной сетью и SPNs через протокол повторной ставки ) Restaking (.

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

![