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

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

I. Обзор трека параллельных вычислений

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

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

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

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

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

Внецепочечная асинхронная параллельная модель, представленная системой агентов Actor ( 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.

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

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

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

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

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

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

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

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

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

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

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

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

Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разделяет блокчейн на несколько независимых подсетей (Shards), каждая из которых отвечает за часть транзакций и состояния, преодолевая ограничения единой цепи для горизонтального масштабирования на сетевом уровне; в то время как 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, PoS, PoA ), и осуществляет безопасное совместное использование и интеграцию ресурсов между основной сетью и SPNs через протокол повторного стекинга ( Restaking ).

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

В целом, рулонная сетка Pharos

Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • 6
  • Поделиться
комментарий
0/400
FloorPriceNightmarevip
· 16ч назад
Купите видеокарту, иначе рано или поздно вас разыгрывают людей как лохов.
Посмотреть ОригиналОтветить0
RooftopReservervip
· 18ч назад
Расширение снова приходит с новыми приемами. Утром, когда двери лифта открылись, увидел баг.
Посмотреть ОригиналОтветить0
Fren_Not_Foodvip
· 07-30 17:37
Какова польза параллельных вычислений? Разве не все решается с помощью 万tx?
Посмотреть ОригиналОтветить0
just_another_walletvip
· 07-30 17:29
Кто еще играет в медлительный L1? L2 – лучший в мире.
Посмотреть ОригиналОтветить0
LidoStakeAddictvip
· 07-30 17:29
Пожалуйста, основная проблема все еще в том, что эффективность Solidity слишком низка.
Посмотреть ОригиналОтветить0
WalletDetectivevip
· 07-30 17:08
Каждую минуту могут уничтожить rollup
Посмотреть ОригиналОтветить0
  • Закрепить