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

Один. Фон и вызовы параллельных вычислений в блокчейне

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

• Выполнение расширенной масштабируемости: повышение исполнительной способности на месте, например, параллельно, с использованием GPU, многопроцессорности.
• Изолированное расширение состояния: горизонтальное разделение состояния / Шард, например, шардирование, 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

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

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

Пайплайнинг является основной концепцией параллельного выполнения монады, его основная идея заключается в том, чтобы разбить процесс выполнения в блокчейне на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя трехмерную архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, обеспечивая конкурентную обработку между блоками, что в конечном итоге приводит к увеличению пропускной способности и снижению задержки. Эти этапы включают: предложение транзакции (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 + 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. Модульный консенсус и повторная ставкa (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (например, PBFT