Панорама параллельных вычислений: анализ 5 основных технических путей для突破 производительности EVM

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

I. Суть масштабирования блокчейна и параллельные вычисления

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

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

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

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

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

II. Параллельная усиленная цепь 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.

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

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

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

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

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

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

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

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

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

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

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

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

Дизайнерские концепции 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), и реализует безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторной ставки (Restaking).

Кроме того, Pharos реконструирует модель выполнения на уровне хранилища с помощью технологий многоуровневого дерева Меркла, дельта-кодирования, адресации версий и подталкивания ADS, выпуская высокопроизводительный хранилище блокчейна Pharos Store, обеспечивая высокую пропускную способность, низкую задержку и высокую проверяемость обработки на цепочке.

В целом, архитектура Rollup Mesh от Pharos через мод

Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 6
  • Репост
  • Поделиться
комментарий
0/400
rekt_but_resilientvip
· 2ч назад
Снова занимаемся этой ерундой, просто занимайся технологиями.
Посмотреть ОригиналОтветить0
NewDAOdreamervip
· 8ч назад
Треугольнику не хватает одной вершины, чеснок.
Посмотреть ОригиналОтветить0
UnluckyMinervip
· 08-10 17:15
Корова гремит, уходит в рай
Посмотреть ОригиналОтветить0
LiquidityWizardvip
· 08-10 17:15
Расширение - это путь
Посмотреть ОригиналОтветить0
CoconutWaterBoyvip
· 08-10 17:04
Расширение может гарантировать безопасность? Боюсь...
Посмотреть ОригиналОтветить0
CountdownToBrokevip
· 08-10 16:51
Ещё раз печатаю, расширение, расширение, не получается.
Посмотреть ОригиналОтветить0
  • Закрепить