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

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

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

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

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

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

  • Параллелизм на уровне аккаунта (Account-level): представляет проект Solana
  • Объектный уровень параллелизма (Object-level): представляет проект Sui
  • Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
  • Уровень вызова / Параллельный микро-ВМ (Call-level / MicroVM): представляет проект MegaETH
  • Уровень инструкций (Instruction-level): представляет проект GatlingX

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Проекты параллельных вычислений, такие как 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. Модульная консенсусная система и механизм повторной ставки (Modular Consensus & Restaking): Pharos вводит гибкую консенсусную систему, поддерживающую различные модели консенсуса (такие как PBFT, PoS, PoA), и реализует связь между основной сетью и SPNs через протокол повторной ставки (Restaking).
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 3
  • Репост
  • Поделиться
комментарий
0/400
pumpamentalistvip
· 17ч назад
Не играйте с концепциями, хорошо?
Посмотреть ОригиналОтветить0
NFTBlackHolevip
· 17ч назад
Блокчейн真香探路
Посмотреть ОригиналОтветить0
GasFeeCriervip
· 18ч назад
Расширение связано с рисками
Посмотреть ОригиналОтветить0
  • Закрепить