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

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

• Выполнение усовершенствованного масштабирования: улучшение вычислительной способности на месте, например, параллельная обработка, GPU, многоядерные
• Изолированное расширение состояния: горизонтальное разделение состояния/Shard, например, шarding, 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) для каждого аккаунта", которая "потокизирует" исполняющую среду, предоставляя минимальную единицу изоляции для параллельного планирования. Эти VM взаимодействуют через асинхронное сообщение (Asynchronous Messaging), а не через синхронные вызовы, что позволяет множеству VM исполняться независимо и храниться независимо, обеспечивая естественную параллельность.

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

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), и реализует основную сеть через протокол повторного залога (Restaking)