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

I. Место и ценность технологий параллельных вычислений в расширении блокчейна

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

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

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

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

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

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

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

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

Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на пути оптимизации пропускной способности, с основной целью повышения TPS на цепочке, осуществляя параллельную обработку на уровне транзакций или учетных записей с помощью отложенного выполнения (Deferred Execution) и архитектуры микровиртуальной машины (Micro-VM). Pharos Network, являясь модульной и полнофункциональной параллельной L1 блокчейн-сетью, имеет основную параллельную вычислительную систему, известную как "Rollup Mesh". Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) и интегрирует такие передовые технологии, как доказательства с нулевым разглашением (ZK) и доверенная вычислительная среда (TEE), благодаря совместной работе основной сети и специализированных сетей обработки (SPNs).

Анализ механизма параллельных вычислений Rollup Mesh:

1. Полный жизненный цикл асинхронной конвейерной обработки (Full Lifecycle Asynchronous Pipelining): Pharos декомпозитирует различные этапы транзакции (такие как консенсус, выполнение, хранение) и применяет асинхронный способ обработки, что позволяет каждому этапу работать независимо и параллельно, тем самым увеличивая общую эффективность обработки.
2. Параллельное выполнение с двумя виртуальными машинами (Dual VM Parallel Execution): Pharos поддерживает две среды виртуальных машин EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя ВМ не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
3. Специальные сети обработки (SPN): SPN являются ключевыми компонентами архитектуры Pharos, подобно модульным подсетям, специально предназначенным для выполнения определенных типов задач или приложений. С помощью SPN Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно повышает масштабируемость и производительность системы.
4. Модулярный консенсус и механизм повторного стекинга (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и реализует безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторного стекинга (Restaking).

Кроме того, Pharos с помощью технологий многоуровневого дерева Меркла, дельта-кодирования, адресации версий и технологии ADS Pushdown реконструировал модель исполнения на уровне хранилища, выпустив нативный высокопроизводительный хранилище блокчейна Phar.