Панорама параллельных вычислений в Web3: прорывы и инновации в решениях по расширению EVM-системы

Пейзаж параллельных вычислений 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
  • Уровень вызова / Микро VM параллельно (Call-level / MicroVM): представляет проект MegaETH
  • Уровень инструкций (Instruction-level): представляет проект GatlingX

Внецепочечная асинхронная конкурентная модель, представляемая системой интеллектуальных агентов (Agent / Actor Model), принадлежит к другой парадигме параллельных вычислений и служит межцепочечным / асинхронным информационным системам (не блоков синхронизации). Каждый агент представляет собой независимый «процесс интеллектуального агента», работающий в параллельном режиме, асинхронные сообщения, управляемые событиями, без необходимости синхронного расписания. К представленным проектам относятся AO, ICP, Cartesi и др.

А знакомые нам Rollup или схемы масштабирования с использованием шардирования относятся к механизмам системной параллельности и не являются параллельными вычислениями внутри цепочки. Они достигают масштабирования за счет "параллельного запуска нескольких цепочек / исполняющих областей", а не за счет повышения параллелизма внутри одного блока / виртуальной машины. Такие схемы масштабирования не являются основной темой этой статьи, но мы все же будем использовать их для сравнительного анализа архитектурных концепций.

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

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 реализует асинхронное выполнение для консенсусного слоя, слоя выполнения и хранения. Это значительно снижает время блока и задержку подтверждения, делая систему более устойчивой, процессы обработки более детализированными и использование ресурсов более эффективным.

Основной дизайн:

  • Процесс консенсуса (уровень консенсуса) отвечает только за упорядочение транзакций, не выполняя логику контрактов.
  • Процесс исполнения (исполнительный уровень) асинхронно запускается после завершения консенсуса.
  • После завершения консенсуса немедленно переходите к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.

Оптимистичное параллельное выполнение:乐观并行执行

Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию "оптимистичного параллельного выполнения", значительно увеличивая скорость обработки транзакций.

Исполнительный механизм:

  • Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что между большинством транзакций нет конфликтов состояния.
  • Запустите "Детектор конфликтов (Conflict Detector))" для мониторинга того, обращаются ли транзакции к одному и тому же состоянию (например, конфликты чтения/записи).
  • Если обнаружен конфликт, конфликтные транзакции будут сериализованы и выполнены повторно, чтобы обеспечить корректность состояния.

Monad выбрал совместимый путь: минимально изменяя правила EVM, реализуя параллелизм через отложенную запись состояния и динамическое обнаружение конфликтов в процессе выполнения, более похожий на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.

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

Анализ параллельного вычислительного механизма MegaETH

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

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

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

Зависимый граф состояния: механизм планирования, основанный на графах зависимостей

MegaETH создала систему планирования DAG, основанную на доступе к состоянию аккаунтов, которая в реальном времени поддерживает глобальный граф зависимостей (Dependency Graph). Каждая транзакция моделирует, какие аккаунты изменяются и какие аккаунты читаются, в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, в то время как транзакции с зависимостями будут последовательно или отложенно упорядочены в соответствии с топологическим порядком. Граф зависимостей обеспечивает согласованность состояния и отсутствие дублирующих записей во время процесса параллельного выполнения.

Асинхронное выполнение и механизм обратных вызовов

MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.

В общем, MegaETH разрушает традиционную модель однопоточной машины состояния EVM, реализуя микро-виртуальные машины в рамках учетной записи, используя граф зависимости состояния для распределения транзакций и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, переосмысляющая "структуру учетной записи → архитектуру распределения → процесс выполнения" во всех измерениях, предоставляя новый парадигмальный подход для создания систем следующего поколения с высокой производительностью.

MegaETH выбрала путь реконструкции: полностью абстрагировала учетные записи и контракты в независимую виртуальную машину, используя асинхронное выполнение для раскрытия предельного параллельного потенциала. Теоретически, параллельный предел MegaETH выше, но также труднее контролировать сложность, больше напоминает суперраспределенную операционную систему на основе концепции Ethereum.

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

Дизайнерские концепции Monad и MegaETH существенно отличаются от шардирования (Sharding): шардирование делит блокчейн на несколько независимых подцепочек (шарды), каждая из которых отвечает за часть транзакций и состояния, преодолевая ограничения единой цепи на уровне сети; в то время как Monad и MegaETH сохраняют целостность единой цепи, лишь горизонтально масштабируя на уровне исполнения, оптимизируя предельное параллельное выполнение внутри единой цепи для повышения производительности. Оба представляют собой два направления в пути масштабирования блокчейна: вертикальное усиление и горизонтальное расширение.

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

Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, ставя своей основной целью повышение TPS в цепочке, достигая параллельной обработки на уровне транзакций или учетных записей с помощью отсроченного выполнения (Deferred Execution) и архитектуры микро-виртуальной машины (Micro-VM). Pharos Network, будучи модульной, полностью стековой параллельной сетью блокчейнов L1, имеет свой основной механизм параллельных вычислений, называемый "Rollup Mesh". Эта архитектура поддерживает совместную работу основной сети и специальных сетей обработки (SPNs), поддерживает много виртуальных машин (EVM и Wasm) и интегрирует такие передовые технологии, как нулевое доказательство (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. Модульный консенсус и тяжесть
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 7
  • Поделиться
комментарий
0/400
GasSavingMastervip
· 8ч назад
Все обсуждают масштабирование, но не можем ли сначала снизить Газ?
Посмотреть ОригиналОтветить0
ForkPrincevip
· 10ч назад
Треугольник невозможен? L2yyds!
Посмотреть ОригиналОтветить0
MetaverseLandladyvip
· 10ч назад
Этот Rollup становится все более напряженным.
Посмотреть ОригиналОтветить0
GateUser-44a00d6cvip
· 10ч назад
Так знакомо, так классно.
Посмотреть ОригиналОтветить0
GhostAddressMinervip
· 10ч назад
Ах, неприступный Секретный ключ был взломан квантовыми линиями, что за идеализм с расширением? Я раскусил ваши уловки.
Посмотреть ОригиналОтветить0
GamefiEscapeArtistvip
· 10ч назад
Целый год на L2, а все еще рассказывают истории... Не нужно постоянно говорить об увеличении емкости.
Посмотреть ОригиналОтветить0
LightningLadyvip
· 11ч назад
Эта схема заставляет меня чувствовать головную боль, вне блокчейна и в блокчейне все слишком сложно.
Посмотреть ОригиналОтветить0
  • Закрепить