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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Дизайнерские концепции 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 вводит гибкие