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

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

Один. Параллельные вычисления: новое направление для масштабирования блокчейна

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

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

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

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

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

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

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

Анализ механизма параллельных вычислений 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

В отличие от позиционирования 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 выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в рамках концепции Ethereum.

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

Дизайнерские концепции 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
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 6
  • Поделиться
комментарий
0/400
RektRecoveryvip
· 07-26 18:14
классическая ловушка трилеммы... мы увидим еще одну каскаду эксплойтов, когда они поспешат к масштабированию. история рифмуется *вздох*
Посмотреть ОригиналОтветить0
AirdropHarvestervip
· 07-24 14:24
Снова играете в расширение? Неудачники рано или поздно будут разыграны как лохи.
Посмотреть ОригиналОтветить0
TokenDustCollectorvip
· 07-24 14:23
Кто снова занимается этой концептуальной спекуляцией? Нет слов.
Посмотреть ОригиналОтветить0
AirdropFatiguevip
· 07-24 14:12
Вы снова хотите нас обмануть, говоря о расширении, да?
Посмотреть ОригиналОтветить0
WenMoonvip
· 07-24 14:11
Так что все говорили полдня, а результат tps все равно не поднялся?
Посмотреть ОригиналОтветить0
PermabullPetevip
· 07-24 13:58
Довольно обманчиво, раз rollup уже вышел, зачем ещё заниматься параллельной обработкой?
Посмотреть ОригиналОтветить0
  • Закрепить