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

1. Введение: Вечная тема масштабирования блокчейна

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

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

Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шarding, 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

Внешняя асинхронная параллельная модель, представляемая системой интеллектуальных агентов (модель агент/актёр), относится к другой парадигме параллельных вычислений. В качестве межсетевой/асинхронной системы сообщений (не блокчейн-синхронная модель), каждый агент функционирует как независимый "интеллектуальный процесс", использующий асинхронные сообщения и события, не требуя синхронного планирования. К представленным проектам относятся 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), реализуя оптимизацию от конца до конца.

Пайплайн: механизм параллельного выполнения многоступенчатого конвейера

Пайплайнинг является основной идеей параллельного выполнения Монад, его ключевая идея заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя многослойную архитектуру конвейера. Каждый этап работает в независимых потоках или ядрах, что позволяет осуществлять конкурентную обработку между блоками, в конечном итоге достигая повышения пропускной способности и снижения задержек. Эти этапы включают: предложение транзакций (Propose), достижение консенсуса (Consensus), выполнение транзакций (Execution) и подтверждение блоков (Commit).

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

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

Ключевой дизайн:

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

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

Традиционный 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), а не синхронными вызовами, что позволяет множеству виртуальных машин выполняться независимо и храниться отдельно, обеспечивая естественную параллельность.

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

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

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

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

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

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

Кроме того, Pharos использует многоверсионные деревья Меркла, дельта-кодирование (Delta Encoding), версии