Web3 Parallel Computing Track Panorama: лучшее решение для нативного масштабирования?

«

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

• Масштабирование с улучшением выполнения: Улучшает возможности выполнения in situ, такие как параллелизм, GPU и многоядерное
• масштабирование с изолированным состоянием: Горизонтально разделенное состояние/шард, например, шарды, UTXO и мультиподсети
• Аутсорсинговое масштабирование вне сети: Перенос выполнения вне цепочки, например, свертки, Масштабирование сопроцессора и структуры DA
• с разделением: модульная архитектура и совместная работа, такие как цепочка модулей, общий секвенсор, Rollup Mesh
• Асинхронное параллельное масштабирование: модель актора, изоляция процесса, управляемая сообщениями, например, агент, многопоточная асинхронная цепочка

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

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

  • Account-level: Представляет проект
  • Object-level: Представляет проект Sui
  • Transaction-level: Представляет проект Monad, Aptos
  • Call-level / MicroVM : Инструкция MegaETH:
  • GatlingX

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

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

  

  2. Цепочка параллельного улучшения EVM: преодоление границы производительности в совместимости

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

  Monad's Parallel Computing

  AnalysisMonad — это высокопроизводительный блокчейн уровня 1, переработанный для виртуальной машины Ethereum (EVM) и основанный на базовой концепции параллельной обработки с асинхронным выполнением на уровне консенсуса и оптимистичным параллелизмом на уровне исполнения параллельное выполнение) 。 Кроме того, на уровне консенсуса и хранения Monad представила высокопроизводительный протокол BFT (MonadBFT) и выделенную систему баз данных (MonadDB) соответственно для достижения сквозной оптимизации.

  Конвейеризация: Механизм параллельного выполнения многоступенчатого конвейера

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

  Асинхронное выполнение: консенсус — выполнение асинхронно разъединеноВ

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

  Структура ядра:

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

  Оптимистичное параллельное исполнение: Оптимистичное параллельное исполнениеТрадиционный

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

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

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

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

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

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

  Архитектура микро-VM: учетные записи — это потоки

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

  Группа обеспечения доступности баз данных о зависимостях состояния: механизм

  планирования, управляемый графами MegaETH создала систему планирования DAG на основе отношений доступа к состоянию учетной записи, и система поддерживает глобальный граф зависимостей в режиме реального времени, а какие учетные записи изменяются и какие учетные записи считываются для каждой транзакции, моделируются в зависимости друг от друга. Бесконфликтные транзакции могут выполняться непосредственно параллельно, а зависимые транзакции будут планироваться и сортироваться последовательно или откладываться в топологическом порядке. Графы зависимостей обеспечивают согласованность состояний и отсутствие дубликатов записи во время параллельного выполнения.

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

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

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

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

  

  Monad и MegaETH Оба имеют разные концепции дизайна от шардинга: шардинг горизонтально делит блокчейн на несколько независимых субчейнов (шардов), каждый из которых отвечает за часть транзакций и состояние, нарушая ограничение на одну цепочку и масштабирование на сетевом уровне; С другой стороны, и Monad, и MegaETH сохраняют целостность одной цепи, масштабируясь горизонтально только на уровне исполнения и выполняя прорывы оптимизации параллельно на пределе одной цепи. Эти два направления представляют два направления: вертикальное усиление и горизонтальное расширение на пути расширения блокчейна.

  Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на пути оптимизации пропускной способности с основной целью улучшения TPS в цепочке и достигают параллельной обработки на уровне транзакций или учетной записи за счет отложенного выполнения и архитектур микро-виртуальных машин. Pharos Network — это модульная параллельная блокчейн-сеть L1 с полным стеком, а ее основная система параллельных вычислений называется «Rollup Mesh». Эта архитектура поддерживает среды с несколькими виртуальными машинами (EVM и Wasm) за счет синергии основной сети и специальных сетей обработки (SPN), а также интегрирует передовые технологии, такие как доказательства с нулевым разглашением (ZK) и доверенные среды выполнения (TEE).

  Анализ параллельных вычислений с использованием сводной сетки:

  1. асинхронная конвейеризация полного жизненного цикла: Pharos разделяет различные этапы транзакции (такие как консенсус, выполнение и хранение) и использует асинхронную обработку, так что каждый этап может выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
  2. Параллельное выполнение двух виртуальных машин: Pharos поддерживает виртуальные машины EVM и WASM, что позволяет разработчикам выбирать правильную среду выполнения для своих нужд. Такая архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и ускоряет обработку транзакций за счет параллельного выполнения.
  3. Специальные вычислительные сети (SPN): SPN являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, предназначенным для обработки определенных типов задач или приложений. С помощью SPN Pharos обеспечивает динамическое распределение ресурсов и параллельную обработку задач, что еще больше повышает масштабируемость и производительность системы.
  4. Модульный консенсус и рестейкинг: Pharos представляет гибкий механизм консенсуса, который поддерживает несколько моделей консенсуса (таких как PBFT, PoS, PoA) и обеспечивает безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторного стейкинга.

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

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

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

  • Reddio — это высокопроизводительная платформа, которая сочетает в себе архитектуру параллельного выполнения zkRollup и GPU, а ее ядро заключается в реконструкции процесса выполнения EVM и реализации нативного распараллеливания слоя выполнения с помощью многопоточного планирования, асинхронного хранения состояний и ускорения выполнения пакетов транзакций с помощью GPU. Параллельная гранулярность на уровне транзакций + операций (опкод многопоточного выполнения). Он предназначен для внедрения многопоточного пакетного выполнения, асинхронной загрузки состояний и логики транзакций параллельной обработки GPU (CUDA-совместимая параллельная EVM). Как и Monad / MegaETH, Reddio также фокусируется на параллельной обработке на уровне выполнения, с той разницей, что механизм выполнения реконструируется с помощью параллельной архитектуры GPU, предназначенной для сценариев с высокой пропускной способностью и интенсивными вычислениями, таких как вывод искусственного интеллекта. Компания GatlingX,
  • которая называет себя «GPU-EVM», предлагает более радикальную архитектуру, которая пытается перенести модель «последовательного выполнения на уровне инструкций» традиционных виртуальных машин EVM в среду параллельного выполнения, нативную для GPU. Основной механизм заключается в динамической компиляции байт-кода EVM в параллельные задачи CUDA и выполнении потока инструкций через многоядерный графический процессор, чтобы преодолеть последовательное узкое место EVM на самом низком уровне. Параллельная гранулярность, относящаяся к параллелизму на уровне инструкций (ILP). По сравнению с гранулярностью параллельного подхода «на уровне транзакций/учетной записи» в Monad / MegaETH, механизм параллелизма GatlingX относится к пути оптимизации на уровне инструкций, который ближе к базовому рефакторингу ядра виртуальной машины. В настоящее время он находится на стадии разработки концепции, опубликованы технический документ и архитектурный эскиз, а SDK или основной сети еще нет.

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

  3. Нативная цепочка параллельной архитектуры: Модель исполнения EVM Ethereum, онтология исполнения реконструированной виртуальной машины

  ,

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

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

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

  3.1 Принцип параллельного двигателя на уровне моря в Solana и SVM

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

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

  1. Явные списки доступа к учетной записи: Каждая транзакция должна объявить задействованную учетную запись (чтение/запись) при отправке, и система определит, есть ли конфликт состояний между транзакциями.

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

  • Если между наборами счетов, к которым обращаются две транзакции, нет пересечения→ они могут выполняться параллельно;
  • Возникает конфликт→ выполнение последовательно в зависимом порядке;
  • Планировщик распределяет транзакции по различным потокам на основе графа зависимостей.

  3. Контекст вызова программы: Каждый вызов контракта выполняется в изолированном контексте без общего стека, чтобы избежать перекрестных помех вызовам.

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

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

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

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

  3.2 Архитектура MoveVM: Resource and Object Driven

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

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

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

  • Объектная модель является основой параллельной архитектуры Sui. Sui абстрагирует все состояние в цепочке в отдельные объекты, каждый из которых имеет уникальный идентификатор, четкого владельца (учетную запись или контракт) и определение типа. Эти объекты не имеют общего состояния друг с другом и по своей сути изолированы. Контракт должен явно объявлять коллекцию задействованных объектов при его вызове, что позволяет избежать проблемы связывания состояний в традиционном ончейн-«глобальном дереве состояний». Такая конструкция разделяет состояние в цепочке на несколько независимых блоков, что делает параллельное выполнение структурно осуществимой предпосылкой планирования.
  • Статический анализ владения — это механизм анализа во время компиляции, реализованный с помощью системы линейных типов языка Move. Это позволяет системе планировать параллельное выполнение транзакций, определяя, какие транзакции не имеют конфликтов состояний через владение объектом, прежде чем они будут выполнены. По сравнению с обнаружением конфликтов и откатом традиционных сред выполнения, механизм статического анализа Sui значительно снижает сложность планирования при одновременном повышении эффективности выполнения, что является ключом к достижению высокой пропускной способности и возможностей детерминированной параллельной обработки.

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

  Механизм выполнения Block-STM от AptosAptos

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

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

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

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

  

  Solana - это инженерная школа планирования, больше похожая на "ядро операционной системы", подходящее для четких границ состояния, контролируемой высокочастотной торговли, это стиль инженера по аппаратному обеспечению, для запуска цепочки как аппаратное обеспечение (Hardware-grade parallel execution); Aptos — это отказоустойчивая система, больше похожая на «движок параллелизма баз данных», подходящая для контрактных систем с сильной связью состояний и сложными цепочками вызовов. Aptos и Sui похожи на инженеров по языкам программирования, а безопасность ресурсов программного уровня представляет собой путь технической реализации параллельных вычислений Web3 в соответствии с различными философиями.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 представляет собой высокопроизводительную транзакционную публичную цепочку, построенную на основе Cosmos SDK, и ее возможности параллелизма в основном отражаются в двух аспектах: многопоточном механизме сопоставления (Parallel Matching Engine) и оптимизации параллельного выполнения уровня виртуальной машины, который предназначен для обслуживания сценариев транзакций в цепочке с высокой частотой и низкой задержкой, таких как DEX книги заказов, инфраструктура ончейн-биржи и т.д.

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

  1. Механизм параллельного сопоставления: SEI V2 вводит многопоточный путь исполнения в логику сопоставления ордеров, разделяя отложенную книгу ордеров и логику сопоставления на уровне потоков, чтобы задачи сопоставления между несколькими торговыми парами могли обрабатываться параллельно и избегать узкого места в однопоточном режиме.
  2. Оптимизация параллелизма на уровне виртуальной машины: Sei V2 создает среду выполнения CosmWasm с возможностями параллельного выполнения, которая позволяет некоторым вызовам контрактов выполняться параллельно без конфликтов состояний и взаимодействует с механизмом классификации типов транзакций для достижения более высокого контроля пропускной способности.
  3. Параллельное планирование консенсуса и уровня выполнения: Так называемый механизм консенсуса «Twin-Turbo» введен для усиления пропускной способности и разъединения между уровнем консенсуса и уровнем выполнения, а также для повышения общей эффективности обработки блоков.

  3.4 UTXO Model Reformer Fuel Fuel

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

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

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

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

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

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

  Основные особенности архитектуры:

  • Архитектура процесса: Каждый агент называется процессом, обладающим независимым состоянием, независимым планировщиком и логикой выполнения;
  • Нет структуры блокчейна: AO — это не цепочка, а децентрализованный слой хранения + мультиагентный движок выполнения на основе сообщений на основе Arweave;
  • Асинхронная система планирования сообщений: процессы взаимодействуют друг с другом с помощью сообщений, используют асинхронную операционную модель без блокировок и, естественно, поддерживают параллельное расширение.
  • Постоянное хранение состояния: Все состояния агентов, записи сообщений и инструкции постоянно записываются в Arweave, что обеспечивает полную проверяемость и децентрализованную прозрачность.
  • Agent-native: подходит для развертывания сложных многошаговых задач (таких как агенты AI, контроллеры протокола DePIN, автоматические оркестраторы задач и т. д.) и может создать «сопроцессор искусственного интеллекта в цепочке».

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

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

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

  Основные особенности архитектуры:

  • Архитектура контейнера (контейнеры в качестве агентов): Каждый контейнер — это агент, работающий на виртуальной машине Wasm с независимым состоянием, кодом и возможностями асинхронного планирования;
  • Распределенная система консенсуса (подсеть): Вся сеть состоит из нескольких подсетей, каждая из которых поддерживает набор канистр и достигает консенсуса с помощью механизма подписи BLS.
  • Модель асинхронного вызова: Canister взаимодействует с Canister через асинхронные сообщения, поддерживает неблокирующее выполнение и имеет естественный параллелизм.
  • Ончейн-хостинг: поддерживает смарт-контракты для прямого размещения фронтенд-страниц, нативное сопоставление DNS и является первой блокчейн-платформой, которая поддерживает браузеры для прямого доступа к dApps;
  • Система обладает полным набором функций: у нее есть системные API, такие как горячее обновление в цепочке, аутентификация личности, распределенная случайность и таймер, который подходит для сложного развертывания ончейн-сервисов.

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

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

  

  5. Резюме и перспективыОсновываясь

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

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

  • Monad: реализует оптимистичную модель параллельного выполнения, совместимую с EVM, с помощью отложенной записи и обнаружения конфликтов во время выполнения, строит графы зависимостей и планирует выполнение после достижения консенсуса.
  • MegaETH: Абстрагирует каждую учетную запись/контракт в независимую микро-виртуальную машину и реализует сильно развязанное параллельное планирование на уровне учетной записи на основе асинхронного обмена сообщениями и графов, зависящих от состояния.
  • Pharos: Создание архитектуры свертной сетки для достижения параллельной обработки процессов на системном уровне с помощью асинхронных конвейеров и модулей SPN.
  • Reddio: использует архитектуру zkRollup + GPU для ускорения процесса проверки zkEVM вне сети за счет пакетной генерации SNARK и повышения пропускной способности проверки.

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

  • Solana (SVM): модель параллельного выполнения на уровне учетной записи, основанная на утверждениях о доступе к учетной записи и планировании статического графа конфликтов;
  • Sui / Aptos (система MoveVM): Основанный на объектной модели ресурсов и системе типов, он поддерживает статический анализ во время компиляции и реализует параллелизм на объектном уровне.
  • Sei V2 (маршрут Cosmos SDK): представляет многопоточный механизм сопоставления и оптимизацию параллелизма виртуальных машин в архитектуре Cosmos, которая подходит для транзакционных высокочастотных приложений.
  • Топливо (архитектура UTXO + Sway): параллелизм на уровне транзакций за счет статического анализа входного набора UTXO, сочетающий модульный уровень исполнения с настраиваемым языком смарт-контрактов Sway;

  Кроме того, будучи более обобщенной параллельной системой, модель акторов создает парадигму выполнения в цепочке «независимая от нескольких агентов операция + совместная работа на основе сообщений» с помощью механизма асинхронного планирования процессов на основе Wasm или пользовательских виртуальных машин. Репрезентативные проекты включают:

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

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

  

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

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

  ,

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

  Напротив, хотя экосистема Ethereum Rollup (L2) вступила в стадию «10 000 цепочек одновременно» или даже «избыточных мощностей», текущая основная параллельная цепочка улучшения EVM все еще в целом находится на стадии тестовой сети и еще не была проверена фактической средой основной сети, а ее масштабируемость и стабильность системы все еще нуждаются в дальнейших испытаниях. Еще неизвестно, смогут ли эти проекты значительно повысить производительность EVM и совершить экологический скачок без ущерба для совместимости, или же они могут еще больше дифференцировать ликвидность и ресурсы разработки Ethereum.