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

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

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

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

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

Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности с целью повышения TPS внутри цепи. Они реализуют параллельную обработку на уровне транзакций или аккаунтов через отложенное выполнение (Deferred Execution) и архитектуру микровиртуальной машины (Micro-VM). Pharos Network, будучи модульной, полнофункциональной параллельной L1 блокчейн-сетью, использует свою основную параллельную вычислительную механику, называемую «Rollup Mesh». Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) благодаря скоординированной работе основной сети и специализированных сетей обработки (SPNs) и интегрирует передовые технологии, такие как нулевые знания (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), и реализует взаимодействие между основной сетью и SPNs через протокол повторной ставки (Restaking).