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

I. Обзор технологий параллельных вычислений

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

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

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

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

• Уровень учетной записи (Account-level): представляет проект Solana
• Объектно-ориентированное параллельное выполнение (Object-level): представляет проект Sui
• Уровень транзакции (Transaction-level): представляет проект Monad, Aptos
• Уровень вызова / Параллельные MicroVM (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 + DAG зависимостей состояния (ориентированный ациклический граф зависимостей состояния) и модульный механизм синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковое выполнение внутри цепи".

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

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

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

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

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

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

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

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

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