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

Треугольник «невозможного» в блокчейне, состоящий из «безопасности», «децентрализации» и «масштабируемости», раскрывает сущностные компромиссы в дизайне блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигнуть «максимальной безопасности, всеобъемлющего участия и высокой скорости обработки». Что касается вечной темы «масштабируемости», то на текущем рынке основные решения по масштабированию блокчейна различаются по парадигмам, включая:

• Выполнение усовершенствованного масштабирования: повышение исполнительной способности на месте, например, параллельная обработка, 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 или схемы масштабирования через шардирование относятся к системным механизмам параллелизма и не являются параллельными вычислениями внутри цепочки. Они достигают масштабирования путем «параллельного выполнения нескольких цепочек / исполняемых областей», а не за счет повышения параллелизма внутри одного блока / виртуальной машины. Такие схемы масштабирования не являются основной темой данного текста, но мы все же будем использовать их для сравнения различий в архитектурных концепциях.

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

Зависимость состояния 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. Модульный консенсус и механизм повторного залога (Mo