Пейзаж параллельных вычислений Web3: лучший вариант для нативного масштабирования?
«Невозможный треугольник» блокчейна (Blockchain Trilemma) — «безопасность», «децентрализация», «масштабируемость» — раскрывает основные компромиссы в проектировании блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигнуть «максимальной безопасности, доступности для всех, высокой скорости обработки». В отношении вечной темы «масштабируемости» современные решения для масштабирования блокчейна на рынке классифицируются по парадигмам, включая:
Выполнение улучшенного масштабирования: повышение исполнительной способности на месте, например, параллельная обработка, GPU, многопоточность
Тип расширения с изоляцией состояния: горизонтальное разделение состояния / Shard, например, шардирование, UTXO, много подсетей
Внешние решения для масштабирования: выполнение вне цепи, например, Rollup, Coprocessor, DA
Структурное декомпозируемое расширение: модульная архитектура, совместная работа, например, модульная цепь, общий сортировщик, Rollup Mesh
Асинхронное конкурентное масштабирование: Модель актора, изоляция процессов, управление сообщениями, например, агенты, многопоточное асинхронное соединение
Системы масштабирования блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, модуль DA, модульную структуру, систему Actor, сжатие zk-доказательства, архитектуру Stateless и другие, охватывающие несколько уровней выполнения, состояния, данных и структуры, представляя собой полную систему масштабирования «многоуровневого взаимодействия и модульного объединения». В данной статье основное внимание уделяется способу масштабирования, основанному на параллельных вычислениях.
Внутреннее параллельное вычисление (intra-chain parallelism), сосредотачиваясь на параллельном выполнении внутренних транзакций / инструкций блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять категорий, каждая из которых представляет собой разные цели производительности, модели разработки и архитектурные философии. Параллельная степень детализации становится все более тонкой, параллельная интенсивность возрастает, сложность планирования также увеличивается, а сложность программирования и трудности реализации также растут.
Уровень аккаунта параллельно (Account-level): представляет проект Solana
Объектно-ориентированное параллельное выполнение (Object-level): представляет проект Sui
Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
Уровень вызова / Микро VM параллельно (Call-level / MicroVM): представляет проект MegaETH
Уровень инструкций (Instruction-level): представляет проект GatlingX
Внецепочечная асинхронная модель параллельного вычисления, представляемая системой интеллектуальных агентов (модель Agent / Actor), относится к другому парадигме параллельных вычислений. В качестве межцепочечных / асинхронных систем сообщений (не модели синхронизации блоков) каждый агент является независимым «интеллектуальным процессом», работающим в асинхронном режиме с сообщениями и событиями, без необходимости синхронного планирования. К известным проектам относятся 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) является основным понятием параллельного выполнения монады. Его основная идея заключается в разбиении процесса выполнения блокчейна на несколько независимых этапов и параллельной обработке этих этапов, формируя трехмерную архитектуру конвейера. Каждый этап выполняется в независимом потоке или ядре, что позволяет осуществлять параллельную обработку между блоками, в конечном итоге достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (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 выбрал путь реконструкции: полностью абстрагировать аккаунты и контракты в независимую виртуальную машину, используя асинхронное выполнение для раскрытия предельного параллельного потенциала. Теоретически, параллельный лимит MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в духе Эфириума.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых подцепей (шарды), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепи для расширения на сетевом уровне; в то время как Monad и MegaETH сохраняют целостность единой цепи, лишь горизонтально расширяя уровень исполнения, достигая оптимизации производительности за счет предельного параллельного выполнения внутри единой цепи. Оба представляют собой два направления в пути расширения блокчейна: вертикальное усиление и горизонтальное расширение.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с основной целью повышения TPS в цепочке. Это достигается за счет отложенного выполнения (Deferred Execution) и архитектуры микровиртуальной машины (Micro-VM) для параллельной обработки на уровне транзакций или аккаунтов. Pharos Network, как модульная, полностековая параллельная L1 блокчейн-сеть, имеет механизм параллельных вычислений, известный как «Rollup Mesh». Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) через совместную работу основной сети и сети специальной обработки (SPNs) и интегрирует такие передовые технологии, как доказательства с нулевым разглашением (ZK) и доверенные исполняемые среды (TEE).
Анализ механизма параллельных вычислений Rollup Mesh:
Полный жизненный цикл асинхронной конвейерной обработки (Full Lifecycle Asynchronous Pipelining): Pharos разъединяет различные этапы транзакции (такие как консенсус, выполнение, хранение) и использует асинхронный способ обработки, что позволяет каждому этапу выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
Параллельное выполнение с двумя виртуальными машинами (Dual VM Parallel Execution): Pharos поддерживает две среды виртуальных машин - EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает способность обработки транзакций благодаря параллельному выполнению.
Специальные обрабатывающие сети (SPNs): SPNs являются ключевым компонентом архитектуры Pharos, аналогично модульным подсетям, специально предназначенным для обработки определенных типов задач или приложений. С помощью SPNs Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно улучшает масштабируемость и производительность системы.
Модульный консенсус и механизм повторного залога (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и через протокол повторного залога (
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Панорама параллельных вычислений в Web3: 5 основных параллельных механизмов от уровня счета до уровня инструкций
Пейзаж параллельных вычислений Web3: лучший вариант для нативного масштабирования?
«Невозможный треугольник» блокчейна (Blockchain Trilemma) — «безопасность», «децентрализация», «масштабируемость» — раскрывает основные компромиссы в проектировании блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигнуть «максимальной безопасности, доступности для всех, высокой скорости обработки». В отношении вечной темы «масштабируемости» современные решения для масштабирования блокчейна на рынке классифицируются по парадигмам, включая:
Системы масштабирования блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, модуль DA, модульную структуру, систему Actor, сжатие zk-доказательства, архитектуру Stateless и другие, охватывающие несколько уровней выполнения, состояния, данных и структуры, представляя собой полную систему масштабирования «многоуровневого взаимодействия и модульного объединения». В данной статье основное внимание уделяется способу масштабирования, основанному на параллельных вычислениях.
Внутреннее параллельное вычисление (intra-chain parallelism), сосредотачиваясь на параллельном выполнении внутренних транзакций / инструкций блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять категорий, каждая из которых представляет собой разные цели производительности, модели разработки и архитектурные философии. Параллельная степень детализации становится все более тонкой, параллельная интенсивность возрастает, сложность планирования также увеличивается, а сложность программирования и трудности реализации также растут.
Внецепочечная асинхронная модель параллельного вычисления, представляемая системой интеллектуальных агентов (модель Agent / Actor), относится к другому парадигме параллельных вычислений. В качестве межцепочечных / асинхронных систем сообщений (не модели синхронизации блоков) каждый агент является независимым «интеллектуальным процессом», работающим в асинхронном режиме с сообщениями и событиями, без необходимости синхронного планирования. К известным проектам относятся 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) является основным понятием параллельного выполнения монады. Его основная идея заключается в разбиении процесса выполнения блокчейна на несколько независимых этапов и параллельной обработке этих этапов, формируя трехмерную архитектуру конвейера. Каждый этап выполняется в независимом потоке или ядре, что позволяет осуществлять параллельную обработку между блоками, в конечном итоге достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: консенсус - выполнение асинхронной декомпозиции
В традиционных цепях блоков согласование и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронность уровня согласования, асинхронность уровня выполнения и асинхронность хранения через «асинхронное выполнение». Это значительно снижает время блока и задержку подтверждения, делает систему более устойчивой, процессы обработки более детализированными и повышает эффективность использования ресурсов.
Основной дизайн:
Оптимистичное Параллельное Выполнение：乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad использует стратегию «оптимистичного параллельного выполнения», что значительно увеличивает скорость обработки транзакций.
Механизм выполнения:
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 выбрал путь реконструкции: полностью абстрагировать аккаунты и контракты в независимую виртуальную машину, используя асинхронное выполнение для раскрытия предельного параллельного потенциала. Теоретически, параллельный лимит MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в духе Эфириума.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых подцепей (шарды), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепи для расширения на сетевом уровне; в то время как Monad и MegaETH сохраняют целостность единой цепи, лишь горизонтально расширяя уровень исполнения, достигая оптимизации производительности за счет предельного параллельного выполнения внутри единой цепи. Оба представляют собой два направления в пути расширения блокчейна: вертикальное усиление и горизонтальное расширение.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с основной целью повышения TPS в цепочке. Это достигается за счет отложенного выполнения (Deferred Execution) и архитектуры микровиртуальной машины (Micro-VM) для параллельной обработки на уровне транзакций или аккаунтов. Pharos Network, как модульная, полностековая параллельная L1 блокчейн-сеть, имеет механизм параллельных вычислений, известный как «Rollup Mesh». Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) через совместную работу основной сети и сети специальной обработки (SPNs) и интегрирует такие передовые технологии, как доказательства с нулевым разглашением (ZK) и доверенные исполняемые среды (TEE).
Анализ механизма параллельных вычислений Rollup Mesh: