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

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

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

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

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

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

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

Пайплайнинг — это основная идея параллельного выполнения монады, которая заключается в разбиении процесса выполнения блокчейна на несколько независимых этапов и параллельной обработке этих этапов, формируя многоуровневую архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, что позволяет осуществлять параллельную обработку между блоками, в конечном итоге достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (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 выбрал путь реконструкции: полностью абстрагируя учетные записи и контракты в независимую VM, освобождая максимальный потенциал параллельного выполнения через асинхронное планирование. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше похожа на суперраспределенную операционную систему в рамках концепции Ethereum.

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