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

I. Вечная тема масштабирования блокчейна

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

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

Решения по расширению блокчейна включают: параллельные вычисления внутри цепи, Rollup, шarding, DA-модули, модульную структуру, систему актеров, сжатие 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), реализуя оптимизацию от конца до конца.

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

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 + Directed Acyclic Graph of State Dependencies (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 значительно отличается от шардирования (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. Специальные сети обработки (SPN): SPN являются ключевыми компонентами архитектуры Pharos, подобными модульным подсетям, специально предназначенными для обработки определенных типов задач или приложений. Благодаря SPN, Pharos может осуществлять динамическое распределение ресурсов и параллельную обработку задач, что дополнительно повышает масштабируемость и производительность системы.
4. Модульный консенсус и повторное ставление (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и обеспечивает безопасное совместное использование и интеграцию ресурсов между основной сетью и SPNs через протокол повторного ставления (Restaking).

Кроме того, Pharos использует многоверсионные деревья Меркла, дельта-кодирование (Delta Encoding), версию