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

I. Введение

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

• Выполнение улучшенного масштабирования: повышение исполнительной способности на месте, например, параллельная обработка, GPU, многопоточность.
• Изоляция состояния и расширение: горизонтальное разделение состояния / Shard, например, шардирование, UTXO, много подсетей
• Внешнее масштабирование типа Off-chain: выполнение происходит вне цепочки, например, Rollup, Копрограммист, DA
• Декуплированное расширение структуры: модульная архитектура, совместная работа, например, модульная цепь, общий сортировщик, Rollup Mesh
• Асинхронное конкурентное масштабирование: модель акторов, изоляция процессов, управление сообщениями, например, агенты, многопоточное асинхронное соединение

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

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

• Уровень параллельности аккаунта (Account-level): представляет проект Solana
• Объектный уровень параллелизма (Object-level): представляет проект Sui
• Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
• Уровень вызова / Микро-ВМ (Call-level / MicroVM): представляет проект MegaETH
• Параллелизм на уровне инструкций (Instruction-level): представляет проект GatlingX

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

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

2. 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 — это основная идея параллельного выполнения Monad, которая заключается в разбиении процесса выполнения в блокчейне на несколько независимых этапов и параллельной обработке этих этапов, что формирует трехмерную архитектуру конвейера. Каждый этап работает в независимых потоках или ядрах, обеспечивая конкурентную обработку между блоками и, в конечном итоге, достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).

Асинхронное выполнение: Консенсус - асинхронная декомпозиция выполнения

В традиционных цепях блоков консенсус и выполнение транзакций обычно происходят синхронно, и эта последовательная модель серьезно ограничивает возможности масштабирования производительности. Monad реализует асинхронное выполнение через "асинхронный консенсус", "асинхронное выполнение" и "асинхронное хранение". Это значительно снижает время блока и задержку подтверждения, делая систему более гибкой, процессы более детализированными и повышая уровень использования ресурсов.

Ядро дизайна:

• Процесс консенсуса (уровень консенсуса) отвечает только за упорядочение транзакций, не выполняя логику контрактов.
• Процесс выполнения (исполнительный уровень) запускается асинхронно после завершения консенсуса.
• После завершения консенсуса сразу переходите к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.

Оптимистичное параллельное выполнение：乐观并行执行

Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию "оптимистичного параллельного выполнения", что значительно увеличивает скорость обработки транзакций.

Исполнительный механизм:

• Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что большинство транзакций не имеют конфликтов состояния.
• Одновременно запускается "Детектор конфликтов (Conflict Detector)", чтобы отслеживать, обращаются ли транзакции к одному и тому же состоянию (например, конфликты чтения/записи).
• Если обнаружен конфликт, конфликтные транзакции будут сериализованы и повторно выполнены, чтобы обеспечить корректность состояния.

Monad выбрал совместимый путь: минимальное вмешательство в правила EVM, реализуя параллелизм за счет отложенной записи состояния и динамического обнаружения конфликтов в процессе выполнения. Это больше похоже на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем в мире EVM.

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

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

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

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

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

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

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

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

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

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

Дизайнерские концепции 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 (Dual VM Parallel Execution): Pharos поддерживает две среды виртуальных машин, EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя ВМ не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
3. Специальные сетевые обработки (SPNs): SPNs являются ключевым компонентом архитектуры Pharos, похожим на модульные подсети, специально предназначенные для обработки определенных типов задач или приложений. С помощью SPNs Pharos может осуществлять динамическое распределение ресурсов и параллельную обработку задач, что дополнительно увеличивает масштабируемость и производительность системы.
4. Модульный консенсус и механизмы повторного стекинга (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и через повторный