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

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

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

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

• Уровень аккаунта: представляет проект Solana
• Объектно-уровневое параллелизм: представляет проект Sui
• Уровень транзакции: представляет проекты Monad, Aptos
• Уровень вызова / MicroVM: Представляет проект MegaETH
• Инструкционно-уровневая параллельность: представляет проект GatlingX

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

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

2. EVM-основанная Параллельная Усовершенствованная Цепочка: Преодоление Границ Производительности через Совместимость

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В дополнение к этому, Pharos переработал модель выполнения на основе движка хранения, используя многоверсионные Меркле-деревья, дельта-кодирование, версионированную адресацию и технологии ADS Pushdown, запустив родной высокопроизводительный движок хранения блокчейна Pharos Store, что обеспечивает высокую пропускную способность, низкую задержку и сильные возможности верифицируемой обработки на цепочке.

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

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

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

Artela предлагает дифференцированную концепцию параллельного проектирования. Внедряя архитектуру EVM++ с виртуальной машиной WebAssembly (WASM), это позволяет разработчикам динамически добавлять и выполнять расширения в цепочке, сохраняя совместимость с EVM, используя модель программирования Aspect. Она принимает гранулярность вызовов контрактов (Функция / Расширение) в качестве минимальной параллельной единицы, поддерживая внедрение модулей расширения (аналогично "плагинам-промежуточному ПО") во время выполнения контракта EVM, достигая логического декуплинга, асинхронных вызовов и параллельного выполнения на уровне модуля. Это больше фокусируется на составляемости и модульной архитектуре слоя исполнения. Эта концепция предлагает новые идеи для будущих сложных многомодульных приложений.

3. Нативная параллельная архитектурная цепь: Реконструкция исполнительного элемента ВМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Механизм выполнения Block-STM Aptos
Aptos — это высокопроизводительный блокчейн первого уровня, основанный на языке Move, чья способность параллельного выполнения в основном исходит из разработанной самостоятельно платформы Block-STM (блоковая программная транзакционная память). В отличие от Sui, который склонен применять стратегию "статического параллелизма на этапе компиляции", Block-STM относится к динамическому механизму планирования "оптимистической конкуренции во время выполнения + откат конфликтов", который подходит для обработки наборов транзакций с комплексными зависимостями.

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

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

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

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

3.3 Тип параллельного масштабирования Cosmos SDK

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

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

• Параллельный механизм сопоставления: Sei V2 вводит многопоточную исполняемую цепочку в логике сопоставления заказов, отделяя книгу заказов от логики сопоставления на уровне потоков, что позволяет обрабатывать задачи сопоставления между несколькими рынками (торговыми парами) параллельно, тем самым избегая узких мест в одном потоке.
• Оптимизация параллелизма на уровне виртуальной машины: Sei V2 создала среду выполнения CosmWasm с возможностями параллельного выполнения, позволяя определенным вызовам контрактов выполняться параллельно при условии, что их состояния не конфликтуют, и достигая более высокого контроля пропускной способности в сочетании с механизмом классификации типов транзакций.
• Параллельный консенсус в сочетании с планированием слоя выполнения: представляем так называемый механизм консенсуса "Twin-Turbo" для усиления развязки пропускной способности между слоем консенсуса и слоем выполнения, что повышает общую эффективность обработки блоков.

3.4 Перезапуск модели UTXO

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

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

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

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

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

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

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

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

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

4.2 ICP (Internet Computer) – полноценная платформа хостинга Web3

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

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

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

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

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

V. Резюме и перспективы

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

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

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

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

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

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

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

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

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

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

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

В отличие от этого, хотя экосистема Ethereum Rollup (L2) вступила в стадию "многочисленные цепи спешат к запуску" или даже "переполненность", в настоящее время мейнстримные параллельные улучшенные цепи, совместимые с EVM, все еще в основном находятся на стадии тестовой сети и еще не прошли фактическую проверку в среде основной сети. Их возможности масштабирования и стабильность системы все еще требуют дальнейшего изучения. Что касается того, смогут ли эти проекты значительно улучшить производительность EVM и способствовать экологической эволюции без жертвы совместимостью, или же они, наоборот, усугубят дальнейшую дифференциацию ликвидности и ресурсов разработки на Ethereum, пока остается под вопросом.

Заявление:

1. Эта статья воспроизведена из [ТекФлоу] Авторское право принадлежит оригинальному автору [0xjacobzhao и ChatGPT 4o] Если у вас есть возражения против перепечатки, пожалуйста, свяжитесь Команда Gate LearnКоманда обработает это как можно быстрее в соответствии с соответствующими процедурами.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Другие языковые версии статьи переведены командой Gate Learn, если не указано иное.ГейтНи при каких обстоятельствах переведенные статьи не могут быть скопированы, распространены или плагиатированы.