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

Автор: 0xjacobzhao и ChatGPT 4o

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

• Масштабирование через улучшение выполнения: повышение производительности непосредственно в сети, например, параллелизм, GPU, многоядерные системы

• Масштабирование через изоляцию состояния: горизонтальное разделение состояний / шарды, например, шардирование, UTXO, несколько подсетей

• Масштабирование через вынос в оффчейн: перенос выполнения за пределы цепочки, например, Roolup, Coprocessor, DA

• Масштабирование через модульную декомпозицию: модульная архитектура и совместное исполнение, например, модульные цепи, общий секвенсор, Rollup Mesh

• Асинхронное конкурентное масштабирование: модель акторов, изоляция процессов, управление сообщениями, например, агенты, многопоточные асинхронные цепи

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

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

• Параллелизм на уровне счетов (Account-level): проект-представитель Solana

• Параллелизм на уровне объектов (Object-level): проект-представитель Sui

• Параллелизм на уровне транзакций (Transaction-level): проекты-представители Monad, Aptos

• Параллелизм на уровне вызовов / микро-ВМ (Call-level / MicroVM): проект-представитель MegaETH

• Параллелизм на уровне инструкций (Instruction-level): проект-представитель GatlingX

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

Хорошо знакомые нам решения по масштабированию через Roolup или шардирование относятся к механизмам системного уровня параллелизма и не входят в范畴 внутрицепочечного параллелизма. Они достигают масштабирования за счет «параллельного запуска множества цепей / исполнительных доменов», а не повышения уровня параллелизма внутри одного блока / виртуальной машины. Эти решения не являются основным предметом обсуждения в данной статье, но мы будем использовать их для сравнения архитектурных концепций.

Две. Параллельно-усиленные цепи семейства EVM: преодоление границ производительности через совместимость

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

Разбор механизма параллельных вычислений в Monad

Monad — это высокопроизводительная Layer1-сеть, переосмысленная для Ethereum Virtual Machine (EVM). Основываясь на базовой парадигме параллелизма конвейерной обработки (Pipelining), она обеспечивает асинхронное выполнение на уровне консенсуса (Asynchronous Execution) и оптимистичный параллелизм на уровне выполнения (Optimistic Parallel Execution). Кроме того, на уровнях консенсуса и хранения Monad внедряет высокопроизводительный протокол BFT (MonadBFT) и специализированную СУБД (MonadDB) для сквозной оптимизации.

Pipelining: Многоэтапный механизм параллельного выполнения конвейера

Pipelining — базовая концепция параллельного выполнения в Monad. Её суть заключается в разделении процесса выполнения блокчейна на несколько независимых этапов, которые обрабатываются параллельно, образуя объемную архитектуру конвейера. Каждый этап работает в отдельном потоке или ядре, обеспечивая конкурентную обработку между блоками, что в конечном итоге повышает пропускную способность и снижает задержки. Эти этапы включают: предложение транзакций (Propose), достижение консенсуса (Consensus), выполнение транзакций (Execution) и фиксация блока (Commit).

Asynchronous Execution: Асинхронное разделение консенсуса и выполнения

В традиционных сетях консенсус и выполнение транзакций обычно представляют собой синхронный процесс, который серьезно ограничивает масштабируемость производительности. Monad реализует «асинхронное выполнение», разделяя уровни консенсуса, выполнения и хранения по времени. Это значительно сокращает время блока (block time) и задержку подтверждения, делая систему более устойчивой, процесс выполнения более детализированным, а использование ресурсов — более эффективным.

Ключевой дизайн:

• Процесс консенсуса (уровень консенсуса) отвечает только за сортировку транзакций, не выполняя логику смарт-контрактов.

• Процесс выполнения (уровень исполнения) запускается асинхронно после достижения консенсуса.

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

Optimistic Parallel Execution: Оптимистичное параллельное выполнение

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

Механизм исполнения:

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

• Одновременно работает «детектор конфликтов (Conflict Detector)», отслеживающий, обращаются ли транзакции к одним и тем же состояниям (например, чтение/запись).

• При обнаружении конфликта конфликтующие транзакции сериализуются и выполняются повторно, гарантируя корректность состояния.

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

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

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

Архитектура Micro-VM (микро-ВМ): счет как поток

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

State Dependency DAG: Планирование на основе графа зависимостей

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

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

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

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

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

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

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

В целом, архитектура Rollup Mesh в Pharos, благодаря модульному дизайну и асинхронным механизмам обработки, реализует возможности высокопроизводительных параллельных вычислений. Pharos выступает координатором планирования кросс-Roolup параллелизма, не будучи оптимизатором исполнения «внутрицепочечного параллелизма», а вместо этого берет на себя гетерогенные пользовательские задачи исполнения через SPNs.

Помимо параллельных архитектур исполнения Monad, MegaETH и Pharos, мы наблюдаем на рынке ряд проектов, исследующих применение GPU-ускорения в параллельных вычислениях EVM, служащих важным дополнением и передовым экспериментом для экосистемы параллельного EVM. Среди них выделяются два представительных направления:

• Reddio — высокопроизводительная платформа, сочетающая zkRoolup с архитектурой параллельного выполнения на базе GPU. Её ядро заключается в перестройке потока выполнения EVM через многопоточное планирование, асинхронное хранение состояний и ускорение пакетов транзакций с помощью GPU, достигая нативного параллелизма на уровне исполнения. Гранулярность параллелизма находится на уровне транзакций + операций (многопоточное выполнение opcode). В архитектуре используются многопоточная пакетная обработка, асинхронная загрузка состояний и параллельная обработка логики транзакций на GPU (CUDA-Compatible Parallel EVM). Подобно Monad / MegaETH, Reddio фокусируется на параллельной обработке на уровне исполнения; отличие лишь в том, что он перестраивает исполняющий движок через GPU-параллельную архитектуру, специально разработанную для сценариев с высокой пропускной способностью и вычислительной интенсивностью (например, AI-инференс). SDK уже доступен и предоставляет интегрируемые исполняемые модули.

• GatlingX называет себя «GPU-EVM» и предлагает еще более агрессивную архитектуру, стремясь перенести традиционную модель «последовательного выполнения инструкций» виртуальной машины EVM в нативную параллельную среду выполнения на GPU. Его основной механизм динамически компилирует байт-код EVM в параллельные задачи CUDA, выполняя потоки инструкций на многоядерном GPU, тем самым ломая последовательные bottleneck'и EVM на самом глубоком уровне. Гранулярность параллелизма — на уровне инструкций (Instruction-Level Parallelism, ILP). В сравнении с «транзакционным/счетным» параллелизмом Monad/MegaETH, механизм GatlingX относится к оптимизации на уровне инструкций, ближе к глубокой перестройке самого движка виртуальной машины. На данный момент проект находится на стадии концепции, опубликованы whitepaper и архитектурные наброски, SDK или mainnet еще отсутствуют.

Artela предлагает дифференцированную парадигму параллельных вычислений. Внедряя архитектуру EVM++ и виртуальную машину WebAssembly (WASM), она позволяет разработчикам динамически добавлять и выполнять расширения прямо в сети, сохраняя совместимость с EVM, посредством модели программирования Aspect. Минимальным элементом параллелизма здесь выступает уровень вызова контракта (Function / Extension). Поддерживается инъекция модулей Extension во время выполнения контракта EVM (аналогично «плагиновой промежуточной прослойке»), обеспечивая развязку логики, асинхронные вызовы и модульно-уровневое параллельное выполнение. Акцент делается на композиции и модульной архитектуре исполнительного слоя. Данный подход открывает новые перспективы для сложных многокомпонентных приложений будущего.

Три. Цепи с нативной параллельной архитектурой: перестройка основы выполнения ВМ

EVM-модель исполнения Ethereum изначально была спроектирована как однопотоковая архитектура с «полным порядком транзакций + последовательным выполнением», что предназначено для обеспечения определенности и согласованности изменений состояния для всех узлов сети. Однако эта архитектура имеет врожденные bottleneck'и производительности, ограничивающие пропускную способность и масштабируемость. В противовес этому, нативные цепи параллельных вычислений, такие как Solana (SVM), MoveVM (Sui, Aptos) и Sei v2 на базе Cosmos SDK, создавались с нуля с учетом параллельного исполнения и обладают следующими преимуществами:

• Естественное разделение моделей состояния: Solana использует механизм декларации доступа к счетам, MoveVM внедряет модель владения объектами, а Sei v2 классифицирует транзакции по типам для статического определения конфликтов, поддерживая конкурентное планирование на уровне транзакций;

• Виртуальные машины оптимизированы под конкурентность: движок Sealevel Solana изначально поддерживает многопоточное исполнение; MoveVM способен проводить статический анализ конкурентных графов; Sei v2 интегрирует многопоточный движок сопоставления ордеров и параллельные модули ВМ.

Конечно, подобные нативные параллельные цепи также сталкиваются с вызовами экосистемной совместимости. Нее EVM-архитектуры обычно требуют новых языков разработки (например, Move, Rust) и инструментальных цепочек, что несет определенные затраты на миграцию для разработчиков; кроме того, им необходимо осваивать новые понятия вроде моделей доступа к состоянию, ограничений конкурентности, жизненного цикла объектов, что повышает порог понимания и требования к моделям разработки.

3.1 Принципы параллельного движка Sealevel семейства Solana и SVM

Исполнительная модель Sealevel Solana представляет собой механизм параллельного планирования на уровне счетов и является ядром Solana для реализации внутрицепочечного параллельного выполнения транзакций. Через механизмы «декларация счетов + статическое планирование + многопоточное исполнение» она достигает высокой конкурентности на уровне смарт-контрактов. Sealevel стала первой исполнительной моделью в области блокчейна, успешно реализовавшей внутрицепочечное конкурентное планирование в production-среде. Ее идейная база повлияла на множество последующих проектов параллельных вычислений и служит эталонной парадигмой для высокопроизводительного дизайна параллельных Layer1.

Основные механизмы:

1. Явная декларация доступа к счетам (Account Access Lists): Каждая транзакция при отправке должна явно заявить затрагиваемые ею счета (чтение/запись). Система определяет наличие конфликтов состояния между транзакциями на основе этого.

2. Обнаружение конфликтов и многопоточное планирование:

• Если множества затронутых счетов двух транзакций не пересекаются → они могут выполняться параллельно;

• При наличии конфликта → выполняются последовательно в порядке зависимостей;

• Планировщик распределяет транзакции по различным потокам на основе графа зависимостей.

3. Независимый контекст исполнения (Program Invocation Context): Каждый вызов контракта выполняется в изолированном контексте, без общего стека, предотвращая межвызовные помехи.

Sealevel — это движок конкурентного планирования исполнения Solana, а SVM — это среда исполнения смарт-контрактов, построенная поверх Sealevel (использует ВМ на базе BPF). Вместе они образуют техническую основу высокопроизводительной параллельной системы исполнения Solana.

Eclipse — проект, деплоящий Solana VM на модульные цепи (например, Ethereum L2 или Celestia), используя движок параллельного исполнения Solana в качестве слоя выполнения Roolup. Eclipse стал одним из первых проектов, предложивших вывести слой исполнения Solana (Sealevel + SVM) из основной сети Solana в модульную архитектуру, экспортировав сверхмощную модель параллельного исполнения Solana как Execution Layer-as-a-Service. Поэтому Eclipse также относится к категории параллельных вычислений.

Подход Neon отличается: он внедряет EVM для работы в среде SVM / Sealevel. Строится совместимый с EVM рантайм-слой, где разработчики пишут контракты на Solidity, но их планирование и исполнение осуществляются через SVM + Sealevel. Neon больше склоняется к категории модульного блокчейна (Modular Blockchain) и не делает акцента на инновациях в параллельных вычислениях.

Подводя итог, Solana и SVM полагаются на движок исполнения Sealevel. Философия планирования, подобная операционной системе, напоминает планировщик ядра ОС: исполнение быстрое, но гибкость относительно ниже. Это нативная высокопроизводительная параллельная цепь.

3.2 Архитектура MoveVM: управляемая ресурсами и объектами

MoveVM — это виртуальная машина для смарт-контрактов, созданная для безопасности on-chain ресурсов и параллельного исполнения. Ее основной язык Move изначально разрабатывался Meta (ранее Facebook) для проекта Libra. Он подчеркивает идею «ресурс как объект», где все on-chain состояния существуют как объекты с четким правом собственности и жизненным циклом. Это позволяет MoveVM статически анализировать наличие конфликтов состояния между транзакциями на этапе компиляции и реализовывать статическое параллельное планирование на уровне объектов. Широко применяется в нативных параллельных сетях типа Sui и Aptos.

Модель владения объектами в Sui

Параллельный потенциал Sui проистекает из его уникального подхода к моделированию состояний и механизма статического анализа на уровне языка. В отличие от традиционных блокчейнов, использующих глобальное дерево состояний, Sui строит модель состояний на основе «объектов» (Object-centric model). В сочетании с линейной системой типов MoveVM это делает параллельное планирование детерминированным процессом, завершаемым на этапе компиляции.

• Модель объектов (Object Model) является основой параллельной архитектуры Sui. Она абстрагирует все on-chain состояния в независимые объекты (Object), каждый из которых обладает уникальным ID, четким владельцем (счет или контракт) и определением типа. Эти объекты не делят состояния друг с другом, обладая естественной изоляцией. Контракты при вызове обязаны явно декларировать множество затрагиваемых объектов, избегая state coupling, свойственного традиционной «глобальной модели дерева состояний». Такой подход разделяет on-chain состояния на независимые единицы, делая конкурентное исполнение структурно осуществимым условием для планирования.

• Статический анализ владения (Static Ownership Analysis) реализуется как механизм анализа на этапе компиляции при поддержке линейной системы типов языка Move. Он позволяет системе задолго до исполнения транзакции выводить из прав владения объектами, какие транзакции не породят конфликтов состояния, и назначать их для параллельного выполнения. В отличие от runtime-обнаружения конфликтов и откатов, механизм статического анализа Sui, повышая эффективность исполнения, существенно снижает сложность планирования, являясь ключом к обеспечению высокой пропускной способности и детерминированной конкурентности.

Sui разделяет пространство состояний по объектам и, комбинируя это со статическим анализом владения на этапе компиляции, реализует параллельное исполнение на уровне объектов с низкой стоимостью и без необходимости откатов. По сравнению с последовательным исполнением традиционных цепей или runtime-проверками, Sui добился значительного роста в эффективности исполнения, системной детерминированности и утилизации ресурсов.

Механизм исполнения Block-STM в Aptos

Aptos — это высокопроизводительная Layer1-сеть на языке Move. Её потенциал параллельного исполнения в значительной степени опирается на собственную рамочную программу Block-STM (Block-level Software Transactional Memory). В отличие от подхода Sui, ориентированного на «статический параллелизм на этапе компиляции», Block-STM представляет собой динамическую схему планирования типа «runtime-оптимистичная конкурентность + rollback при конфликте», подходящую для обработки наборов транзакций со сложными зависимостями.

Block-STM разделяет процесс исполнения транзакций в одном блоке на три этапа:

• Оптимистичное конкурентное исполнение (Speculative Execution): Перед исполнением все транзакции по умолчанию считаются бесконфликтными. Система параллельно планирует транзакции по нескольким потокам для попытки исполнения, фиксируя затронутые состояния счетов (read-set / write-set).

• Обнаружение конфликтов и валидация (Validation Phase): Система проверяет результаты исполнения. Если две транзакции имеют конфликты чтения/записи (например, Tx1 читает состояние, записанное Tx2), одна из них откатывается.

• Откат и повторный запуск конфликтующих транзакций (Retry Phase): Конфликтующие транзакции перезапускаются до разрешения зависимостей, в результате чего все транзакции формируют эффективную и детерминированную последовательность фиксации состояний.

Block-STM представляет собой динамическую модель исполнения «оптимистичный параллелизм + откат и повторный запуск», идеально подходящую для сценариев пакетной обработки плотных по состоянию и логически сложных on-chain транзакций. Является ядром параллельных вычислений в Aptos для построения высокоуниверсальной и высокопроизводительной общественной цепи.

Solana представляет школу инженерного планирования, ближе к «ядру операционной системы», идеален для четко очерченных границ состояния и контролируемых высокочастотных транзакций. Это стиль аппаратных инженеров, требующий работы цепи как железа (Hardware-grade parallel execution). Aptos представляет школу отказоустойчивости систем, ближе к «движку конкурентности баз данных», подходит для систем контрактов с сильной связанностью состояний и сложными цепочками вызовов. Sui представляет школу компиляторной безопасности, ближе к «платформе интеллектуального программирования, управляемой ресурсами», идеален для on-chain приложений с разделенными активами и четкой композицией. Aptos и Sui работают как программисты, требуя безопасной работы цепи как ПО (Software-grade resource security). Все три направления демонстрируют пути технической реализации параллельных вычислений в Web3, основанные на различных философских подходах.

3.3 Параллельное расширение на базе Cosmos SDK

Sei V2 — это высокопроизводительная публичная торговая цепь, построенная на Cosmos SDK. Её конкурентный потенциал проявляется в двух аспектах: многопоточном движке сопоставления ордеров (Parallel Matching Engine) и оптимизации параллельного исполнения на уровне ВМ. Цель — обслуживание высокочастотных и низкозадержанных сценариев on-chain торговли, таких как децентрализованные биржи DEX с книгой ордеров и соответствующая инфраструктура.

Основные параллельные механизмы:

1. Параллельный движок сопоставления ордеров: Sei V2 внедряет многопоточные пути исполнения в логику сопоставления ордеров, разделяя книгу ордеров и логику сопоставления на уровне потоков. Это позволяет обрабатывать задания сопоставления между различными рынками (торговыми парами) параллельно, устраняя bottleneck однопоточности.

2. Конкурентная оптимизация на уровне ВМ: Sei V2 строит среду исполнения CosmWasm с возможностью конкурентного выполнения, позволяя некоторым вызовам контрактов запускаться параллельно при отсутствии конфликтов состояния, в сочетании с механизмом классификации типов транзакций для более жесткого контроля пропускной способности.

3. Синхронизация параллельного консенсуса с планированием исполнения: внедряется так называемая консенсусная механика «Twin-Turbo», усиливающая развязку пропускной способности между уровнем консенсуса и уровнем исполнения, повышая общую эффективность обработки блоков.

3.4 Реформатор модели UTXO — Fuel

Fuel — это высокопроизводительный исполнительный слой, спроектированный на основе модульной архитектуры Ethereum. Его основной параллельный механизм проистекает из улучшенной модели UTXO (Unspent Transaction Output). В отличие от account-модели Ethereum, Fuel использует структуру UTXO для представления активов и состояний. Эта модель обладает естественной изоляцией состояний, облегчая определение того, какие транзакции можно безопасно исполнять параллельно. Кроме того, Fuel внедряет собственную разработку языка смарт-контрактов Sway (похожего на Rust) и инструменты статического анализа, определяющие входные конфликты до начала исполнения транзакций, реализуя тем самым эффективное и безопасное параллельное планирование на уровне транзакций. Это альтернатива EVM как исполняющему слою, балансирующая производительность и модульность.

Четыре. Модель акторов: новая парадигма конкурентного исполнения агентов

Модель акторов (Actor Model) — это парадигма параллельного исполнения, основанная на процессах агентов (Agent или Process). В отличие от синхронных вычислений над глобальным состоянием в традиционных сетях (сценарии «внутрицепочечных параллельных вычислений» типа Solana/Sui/Monad), она подчеркивает, что каждый агент обладает независимым состоянием и поведением, взаимодействуя и планируя работу через асинхронные сообщения. В такой архитектуре система в сети может состоять из множества независимо взаимодействующих процессов, обладающих исключительной масштабируемостью и асинхронной отказоустойчивостью. Проекты-представители: AO (Arweave AO), ICP (Internet Computer) и Cartesi. Они продвигают эволюцию блокчейна от исполнительных двигателей к «on-chain операционным системам», предоставляя нативную инфраструктуру для AI-агентов, многозадачного взаимодействия и сложной оркестровки логики.

Хотя дизайн модели акторов имеет некоторые поверхностные сходства с шардированием (например, параллелизм, изоляция состояний, асинхронная обработка), по своей сути они представляют совершенно разные технологические пути и системные философии. Модель акторов делает акцент на «асинхронных многопроцессных вычислениях»: каждый агент (Actor) работает независимо, управляет своим состоянием и взаимодействует через управление сообщениями. Шардирование же представляет собой механизм «горизонтального разделения состояний и консенсуса», разбивая весь блокчейн на несколько независимых подсистем (Shard) для обработки транзакций. Модель акторов работает как «распределенная операционная система агентов» в мире Web3, тогда как шардирование — это структурное решение для масштабирования внутренней пропускной способности обработки транзакций. Оба обеспечивают параллелизм, но отличаются исходными точками, целями и архитектурой исполнения.

4.1 AO (Arweave): суперкомпьютер параллельных вычислений поверх слоя хранения

AO — это децентрализованная вычислительная платформа, работающая на постоянном слое хранения Arweave. Ее главная цель — создание on-chain операционной системы, поддерживающей масштабный асинхронный запуск агентов.

Ключевые архитектурные особенности:

• Архитектура Process: каждый агент называется Process, обладает независимым состоянием, планировщиком и логикой исполнения;

• Отсутствие структуры цепи: AO не является цепью, а представляет собой децентрализованный слой хранения Arweave + многоагентный движок исполнения, управляемый сообщениями;

• Система асинхронного планирования сообщений: Process общаются посредством сообщений (Message), используют неблокируемую асинхронную модель выполнения, естественным образом поддерживая конкурентное масштабирование;

• Постоянное хранение состояний: все состояния агентов, записи сообщений и инструкции постоянно записываются в Arweave, обеспечивая полную аудируемость и децентрализованную прозрачность;

• Agent-native: идеально подходит для развертывания сложных многошаговых задач (например, AI-агенты, контроллеры DePIN-протоколов, автоматические оркестраторы задач), позволяя строить «on-chain AI-сопроцессор».

AO следует максимально чистой линии «агент-первичность + драйвер хранения + архитектура без цепи», делая ставку на гибкость и развязку модулей. Это «on-chain микроядерный фреймворк, размещенный поверх слоя хранения», с намеренно суженными границами системы, делающими акцент на легких вычислениях + композиционно управляемых структурах.

4.2 ICP (Internet Computer): полнофункциональная платформа хостинга Web3

ICP — это нативная полнофункциональная on-chain платформа приложений Web3, выпущенная DFINITY. Ее цель — расширить вычислительную мощность on-chain до уровня пользовательского опыта Web2, поддерживая полный сервис хостинга, привязку доменов и serverless-архитектуру.

Ключевые архитектурные особенности:

• Архитектура Canister (контейнер как агент): каждый Canister — это агент, работающий на ВМ Wasm, обладающий независимым состоянием, кодом и возможностями асинхронного планирования;

• Распределенная консенсусная система субнетей (Subnet): вся сеть состоит из множества Subnet, каждая из которых поддерживает группу Canister и достигает консенсуса через механизм подписей BLS;

• Модель асинхронных вызовов: Canister общаются между собой через асинхронные сообщения, поддерживая неблокируемое исполнение с естественным параллелизмом;

• On-chain веб-хостинг: поддерживает прямой хостинг фронтенд-страниц смарт-контрактами, нативное отображение DNS. Это первая блокчейн-платформа, поддерживающая прямой доступ к dApp через браузер;

• Полнофункциональная система: включает on-chain hot-upgrade, аутентификацию идентичности, распределенную энтропию, таймеры и другие системные API, подходящие для развертывания сложных on-chain сервисов.

ICP выбирает парадигму операционной системы с сильным контролем платформы, единой инкапсуляцией и тяжелой платформой. Она обладает «блокчейн-операционной системой» с интеграцией консенсуса, исполнения, хранения и доступа, делая акцент на полной функциональности сервисного хостинга, расширяя границы системы до полнофункциональной платформы хостинга Web3.

Кроме того, параллельные вычислительные проекты других парадигм модели акторов можно найти в таблице ниже:

Пять. Заключение и прогнозы

В зависимости от различий в архитектуре виртуальных машин и языковых систем, решения по параллельным вычислениям в блокчейне примерно делятся на два типа: параллельно-усиленные цепи семейства EVM и цепи с нативной параллельной архитектурой (нее EVM).

Первый тип сохраняет совместимость экосистемы EVM / Solidity, достигая более высокой пропускной способности и возможностей параллельного выполнения за счет глубокой оптимизации исполнительного слоя. Идеально подходит для сценариев, где нужно наследовать активы и инструменты разработки Ethereum, получая при этом прорыв в производительности. Проект-представители:

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

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

• Pharos: строит архитектуру Rollup Mesh, синхронизируя асинхронный пайплайн и модули SPN для достижения системного параллельного кросс-процессного выполнения.

• Reddio: использует zkRoolup + архитектуру GPU, фокусируясь на ускорении off-chain валидации zkEVM путем пакетной генерации SNARK для повышения throughput валидации.

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

• Solana (семейство SVM): на основе декларации доступа к счетам и статического планирования по графу конфликтов, представляет модель исполнения параллелизма на уровне счетов;

• Sui / Aptos (семейство MoveVM): базируется на модели ресурсных объектов и системе типов, поддерживает статический анализ на этапе компиляции, реализуя параллелизм на уровне объектов;

• Sei V2 (путь Cosmos SDK): внедряет многопоточный движок сопоставления ордеров и конкурентную оптимизацию ВМ в архитектуре Cosmos, подходящий для высокочастотных торговых приложений;

• Fuel (архитектура UTXO + Sway): достигает транзакционного параллелизма через статический анализ набора входных данных UTXO, в сочетании с модульным исполняющим слоем и кастомным языком смарт-контрактов Sway;

Кроме того, Модель акторов, как более широкая система параллелизма, через асинхронное планирование процессов на базе Wasm или кастомных ВМ формирует on-chain парадигму исполнения «независимый запуск множества агентов + взаимодействие, управляемое сообщениями». Проект-представители:

• AO (Arweave AO): на базе агентов-рантаймов с драйвером постоянного хранения строит асинхронную микроядерную систему on-chain;

• ICP (Internet Computer): использует контейнерные агенты (Canister) в качестве минимальных единиц, реализует асинхронное высокомасштабируемое выполнение через координацию субнетей;

• Cartesi: внедряет операционную систему Linux в качестве off-chain вычислительной среды, предлагая путь on-chain верификации результатов доверенных вычислений, подходящий для сложных или ресурсоемких сценариев применения.

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

Если взглянуть на масштабирование в более широком смысле, то шардирование (Sharding) и Roolup (L2) делают акцент на горизонтальном расширении системы через разделение состояний или off-chain исполнение. В то же время цепи параллельных вычислений (например, Monad, Sui, Solana) и системы, ориентированные на модель акторов (например, AO, ICP), напрямую перестраивают модель исполнения, реализуя нативный параллелизм внутри цепи или на системном уровне. Первые повышают внутреннюю пропускную способность цепи через многопоточные ВМ, модели объектов, анализ конфликтов транзакций и т. д.; вторые используют процессы/агенты в качестве базовых элементов, применяя управление сообщениями и асинхронное исполнение для одновременного запуска множества агентов. По сравнению с ними шардирование и Roolup больше похожи на «разделение нагрузки по разным цепям» или «вынос в off-chain», тогда как параллельные цепи и модель акторов — это «освобождение потенциала производительности самой системы исполнения», отражая более радикальное направление эволюции архитектуры.

Сравнение путей расширения: параллельные вычисления vs архитектура шардирования vs масштабирование Roolup vs Actor-Oriented

Стоит особо отметить, что большинство цепей с нативной параллельной архитектурой уже вышли на стадию mainnet. Несмотря на то, что общая экосистема разработчиков пока не может сравниться с экосистемой Solidity в рамках EVM, такие проекты, как Solana и Sui, благодаря их высокопроизводительным архитектурным решениям исполнения и постепенному процветанию экосистемных приложений, стали основными публичными цепями, привлекающими повышенное внимание рынка.

Напротив, хотя экосистема Ethereum Roolup (L2) уже перешла на стадию «сотен запущенных цепей» или даже «избытка мощности», текущие основные параллельно-усиленные цепи семейства EVM все еще широко停留在 стадии тестнетов и не прошли фактической проверки в условиях mainnet. Их потенциал масштабирования и стабильность системы нуждаются в дальнейшей проверке. Останутся ли эти проекты в состоянии значительно повысить производительность EVM без ущерба для совместимости и стимулировать скачок экосистемы, или же это лишь усугубит фрагментацию ликвидности и разработческих ресурсов Ethereum, покажет только время.