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

I. Применение параллельных вычислений в блокчейн-технологиях

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

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

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

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

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

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

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

II. 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 + State Dependency DAG (направленный ациклический граф зависимостей состояния) и модульном механизме синхронизации, которые совместно создают параллельную систему выполнения, ориентированную на "потоковую обработку в цепочке".

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

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

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

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

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

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

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

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

Дизайн концепции Monad и MegaETH существенно отличается от шардинга (Sharding): шардинг горизонтально разделяет блокчейн на несколько независимых подсетей (шарды), каждая подсеть отвечает за часть транзакций и состояния, преодолевая ограничения единой цепи на уровне сети; в то время как 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), и через протокол повторного стекинга (