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

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

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

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

II. EVM-система параллельного улучшения цепочки: прорыв пределов производительности в совместимости

Архитектура последовательной обработки Ethereum развивалась до сих пор, пройдя через несколько этапов масштабирования, таких как шардирование, Rollup и модульная архитектура, но узкое место в пропускной способности исполнительного уровня все еще не было решено кардинально. В то же время, EVM и Solidity по-прежнему являются наиболее развитыми платформами для смарт-контрактов с точки зрения базы разработчиков и экосистемного потенциала. Таким образом, параллельные цепочки EVM, которые учитывают как совместимость экосистемы, так и повышение производительности выполнения, становятся важным направлением для очередного этапа масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, каждый из которых строит архитектуру параллельной обработки EVM для сценариев с высокой параллельностью и высокой пропускной способностью, начиная с отложенного выполнения и декомпозиции состояния.

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

Monad — это высокопроизводительная Layer1 блокчейн, заново разработанная для Ethereum Virtual Machine (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

В отличие от定位 Monad, MegaETH定位为 модульный высокопроизводительный параллельный исполняющий слой, совместимый с EVM, который может функционировать как независимая L1 публичная цепочка или как слой улучшенного исполнения (Execution Layer) на Ethereum, либо как модульный компонент. Его основная цель проектирования заключается в разбиении логики аккаунтов, исполняющей среды и состояния на отдельные минимальные единицы, которые могут быть независимо запланированы, чтобы обеспечить высокую параллельную обработку и низкую задержку отклика внутри цепи. Ключевое новшество, предложенное MegaETH, заключается в: архитектуре Micro-VM + DAG зависимости состояния (направленный ациклический граф зависимости состояния) и модульном механизме синхронизации, которые вместе создают параллельную исполняющую систему, ориентированную на «потоковую обработку внутри цепи».

Архитектура Micro-VM (микровиртуальная машина): аккаунт — это поток

MegaETH вводит модель выполнения «микровиртуальных машин для каждого аккаунта (Micro-VM)», которая «параллелизует» среду выполнения, предоставляя минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения (Asynchronous Messaging), а не синхронные вызовы, что позволяет множеству ВМ независимо выполнять задачи и хранить данные, обеспечивая естественную параллельность.

State Dependency 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), и реализует связь между основной сетью и SPN через протокол повторного стекинга.