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

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

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

  • Выполнение улучшенной масштабируемости: повышение исполнительной способности на месте, например, параллельная обработка, GPU, многопоточность.
  • Изолированное расширение состояния: горизонтальное разделение состояния / Shard, например, шarding, UTXO, много подсетей
  • Внешняя масштабируемость с помощью аутсорсинга: выполнение вне цепочки, например, Rollup, Копроцессор, 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 параллельные вычисления: лучший вариант для нативного масштабирования?

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

Ядро проектирования:

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

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

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

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

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

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

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

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

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

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

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

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

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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 4
  • Репост
  • Поделиться
комментарий
0/400
LightningClickervip
· 08-10 15:07
Все еще играете в четыре схемы? Я просто спрошу, сколько tps?
Посмотреть ОригиналОтветить0
FUD_Whisperervip
· 08-10 15:03
Расширять что-то? В основном снова обманули неудачников.
Посмотреть ОригиналОтветить0
EntryPositionAnalystvip
· 08-10 14:57
Шардинг тоже не решает эту проблему
Посмотреть ОригиналОтветить0
GraphGuruvip
· 08-10 14:50
Просто улучшайся на месте, зачем спешить с Шардингом и разделением сети.
Посмотреть ОригиналОтветить0
  • Закрепить