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

I. Технический фон и мотивация развития параллельных вычислений

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

• Выполнение улучшенного масштабирования: повышение производительности на месте, например, параллельная обработка, 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

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

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

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

Основной дизайн:

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

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

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

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

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

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

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

В отличие от L1定位 Monad, MegaETH定位 как модульный высокопроизводительный параллельный исполнительный уровень, совместимый с EVM, который может использоваться как независимая L1 публичная цепочка, так и в качестве усиленного уровня исполнения (Execution Layer) на Ethereum или модульного компонента. Основная цель его проектирования заключается в том, чтобы изолировать и декомпозировать логику аккаунта, исполнительную среду и состояние в минимальные единицы, которые могут независимо планироваться, чтобы достичь высокой параллельной обработки внутри цепи и низкой задержки ответа. Ключевое новшество, предложенное 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, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.

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

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

Дизайнерские концепции 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, PoS, PoA